--- 1/draft-ietf-6man-text-addr-representation-01.txt 2009-11-10 06:12:10.000000000 +0100 +++ 2/draft-ietf-6man-text-addr-representation-02.txt 2009-11-10 06:12:10.000000000 +0100 @@ -1,19 +1,34 @@ IPv6 Maintenance Working Group S. Kawamura Internet-Draft NEC BIGLOBE, Ltd. -Intended status: Informational M. Kawashima -Expires: April 21, 2010 NEC AccessTechnica, Ltd. - October 18, 2009 +Intended status: Standards Track M. Kawashima +Expires: May 14, 2010 NEC AccessTechnica, Ltd. + November 10, 2009 A Recommendation for IPv6 Address Text Representation - draft-ietf-6man-text-addr-representation-01 + draft-ietf-6man-text-addr-representation-02 + +Abstract + + As IPv6 network grows, there will be more engineers and also non- + engineers who will have the need to use an IPv6 address in text. + While the IPv6 address architecture RFC 4291 section 2.2 depicts a + flexible model for text representation of an IPv6 address, this + flexibility has been causing problems for operators, system + engineers, and users. This document will describe the problems that + a flexible text representation has been causing. This document also + recommends a canonical representation format that best avoids + confusion. It is expected that the canonical format is followed by + humans and systems when representing IPv6 addresses as text, but all + implementations must accept and be able to handle any legitimate + RFC4291 format. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -22,94 +37,81 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 21, 2010. + This Internet-Draft will expire on May 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - As IPv6 network grows, there will be more engineers and also non- - engineers who will have the need to use an IPv6 address in text. - - While the IPv6 address architecture RFC 4291 section 2.2 depicts a - flexible model for text representation of an IPv6 address, this - flexibility has been causing problems for operators, system - engineers, and users. This document will describe the problems that - a flexible text representation has been causing. This document also - recommends a canonical representation format that best avoids - confusion. It is expected that the canonical format is followed by - humans and systems when representing IPv6 addresses as text, but all - implementations must accept and be able to handle any legitimate - RFC4291 format. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6 3.1.4. Searching for an Address in a Network Diagram . . . . 7 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8 + 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 7 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 - 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 10 + 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9 4. A Recommendation for IPv6 Text Representation . . . . . . . . 10 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10 4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10 - 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11 - + 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Text Representation of Special Addresses . . . . . . . . . . . 11 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 - 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 Appendix B. Prefix Issues . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction A single IPv6 address can be text represented in many ways. Examples are shown below. @@ -273,34 +275,30 @@ With all the possible text representation ways, each application must include a module, object, link, etc. to a function that will parse IPv6 addresses in a manner that no matter how it is represented, they will mean the same address. This is not too much a problem if the output is to be just 'read' or 'managed' by a network engineer. However, many system engineers who integrate complex computer systems to corporate customers will have difficulties finding that their favorite tool will not have this function, or will encounter difficulties such as having to rewrite their macro's or scripts for - their customers. It must be noted that each additional line of a - program will result in increased development fees that will be - charged to the customers. + their customers. 3.2.2. Logging If an application were to output a log summary that represented the address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), the output would be highly unreadable compared to the IPv4 output. The address would have to be parsed and reformed to make it useful - for human reading. This will result in additional code on the - applications which will result in extra fees charged to the - customers. Sometimes, logging for critical systems is done by - mirroring the same traffic to two different systems. Care must be + for human reading. Sometimes, logging for critical systems is done + by mirroring the same traffic to two different systems. Care must be taken that no matter what the log output is, the logs should be parsed so they will mean the same. 3.2.3. Auditing: Case 1 When a router or any other network appliance machine configuration is audited, there are many methods to compare the configuration information of a node. Sometimes, auditing will be done by just comparing the changes made each day. In this case, if configuration was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: @@ -318,43 +316,41 @@ will need to be a script that is implemented to cover for this. An SNMP GET of an interface address and text representation in a humanly written text file is highly unlikely to match on first try. 3.2.5. Verification Some protocols require certain data fields to be verified. One example of this is X.509 certificates. If an IPv6 address was embedded in one of the fields in a certificate, and the verification was done by just a simple textual comparison, the certificate may be - maistakenly shown as being invalid due to a difference in text + mistakenly shown as being invalid due to a difference in text representation methods. 3.2.6. Unexpected Modifying Sometimes, a system will take an address and modify it as a convenience. For example, a system may take an input of 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some RIR databases). If the zeros were input for a reason, the outcome may be somewhat unexpected. 3.3. Operating 3.3.1. General Summary When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: 0:0:1, the system may take the address and show the configuration result as 2001:DB8::1:0:0:1. A distinguished engineer will know that the right address is set, but an operator, or a customer that is communicating with the operator to solve a problem, is usually not as - distinguished as we would like. Again, the extra load in checking - that the IP address is the same as was intended, will result in fees - that will be charged to the customers. + distinguished as we would like. 3.3.2. Customer Calls When a customer calls to inquire about a suspected outage, IPv6 address representation should be handled with care. Not all customers are engineers nor have the same skill in IPv6 technology. The NOC will have to take extra steps to humanly parse the address to avoid having to explain to the customers that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1. This is one thing that will never happen in IPv4 because IPv4 address cannot be abbreviated. @@ -375,42 +371,42 @@ 3.4. Other Minor Problems 3.4.1. Changing Platforms When an engineer decides to change the platform of a running service, the same code may not work as expected due to the difference in IPv6 address text representation. Usually, a change in a platform (e.g. Unix to Windows, Cisco to Juniper) will result in a major change of code, but flexibility in address representation will increase the - work load which will again, result in fees that will be charged to - the customers, and also longer down time of systems. + work load. 3.4.2. Preference in Documentation A document that is edited by more than one author, may become harder to read. 3.4.3. Legibility Capital case D and 0 can be quite often misread. Capital B and 8 can also be misread. 4. A Recommendation for IPv6 Text Representation A recommendation for a canonical text representation format of IPv6 addresses is presented in this section. The recommendation in this document is one that, complies fully with [RFC4291], is implemented by various operating systems, and is human friendly. The - recommendation in this document SHOULD be followed by humans and - systems when generating an address to represent as text, but all - implementations MUST accept any legitimate [RFC4291] format. + recommendation in this document SHOULD be followed by systems when + generating an address to represent as text, but all implementations + MUST accept any legitimate [RFC4291] format. It is advised that + humans also follow these recommendations when spelling an address. 4.1. Handling Leading Zeros in a 16 Bit Field Leading zeros should be chopped for human legibility and easier searching. Also, a single 16 bit 0000 field should be represented as just 0. Place holder zeros are often cause of misreading. 4.2. "::" Usage 4.2.1. Shorten As Much As Possible @@ -426,22 +422,22 @@ 4.2.3. Choice in Placement of "::" When there is an alternative choice in the placement of a "::", the longest run of consecutive 16 bit 0 fields should be shortened (i.e. latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1), the former is shortened. This is consistent with many current implementations. One idea to avoid any confusion, is for the operator to not use 16 bit field 0 in the first 64 bits. By nature - IPv6 addresses are usually assigned or allocated to end-users as - longer than 32 bits (typically 48 bits or longer). + IPv6 addresses are usually assigned or allocated to end-users from a + prefix of 32 bits or longer (typically 48 bits or longer). 4.3. Lower Case Recent implementations tend to represent IPv6 address as lower case. It is better to use lower case to avoid problems such as described in section 3.3.3 and 3.4.3. 5. Text Representation of Special Addresses Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and