--- 1/draft-ietf-6man-text-addr-representation-00.txt 2009-10-21 11:12:07.000000000 +0200 +++ 2/draft-ietf-6man-text-addr-representation-01.txt 2009-10-21 11:12:07.000000000 +0200 @@ -1,19 +1,19 @@ IPv6 Maintenance Working Group S. Kawamura Internet-Draft NEC BIGLOBE, Ltd. Intended status: Informational M. Kawashima -Expires: February 24, 2010 NEC AccessTechnica, Ltd. - August 23, 2009 +Expires: April 21, 2010 NEC AccessTechnica, Ltd. + October 18, 2009 A Recommendation for IPv6 Address Text Representation - draft-ietf-6man-text-addr-representation-00 + draft-ietf-6man-text-addr-representation-01 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,21 +22,21 @@ 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 February 24, 2010. + This Internet-Draft will expire on April 21, 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 @@ -70,45 +70,47 @@ 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.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 - 3.2.5. Unexpected Modifying . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 9 - 4. A Recommendation for IPv6 Text Representation . . . . . . . . 9 + 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 10 + 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5. Text Representation of Special Addresses . . . . . . . . . . . 10 + 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11 + + 5. Text Representation of Special Addresses . . . . . . . . . . . 11 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 - 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 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. 2001:db8:0:0:1:0:0:1 @@ -310,21 +312,30 @@ do not take into account address representation rules. 3.2.4. Auditing: Case 2 Node configurations will be matched against an information system that manages IP addresses. If output notation is different, there 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. Unexpected Modifying +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 + 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 @@ -463,21 +473,23 @@ o 2001:db8::1 port 80 o 2001:db8::1p80 o 2001:db8::1#80 The situation is not much different in IPv4, but the most ambiguous case with IPv6 is the second bullet. This is due to the "::"usage in IPv6 addresses. This style is not recommended for its ambiguity. - The most common case is the [] style as expressed in [RFC3986]. + The [] style as expressed in [RFC3986] is recommended. Other styles + are acceptable when cross-platform portability does not become an + issue. 7. Conclusion The recommended format of text representing an IPv6 address is summarized as follows. (1) omit leading zeros in a 16 bit field (2) when using "::", shorten consecutive zero fields to their maximum extent (leave no zero fields behind). @@ -499,25 +512,25 @@ 9. IANA Considerations None. 10. Acknowledgements The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, Toshimitsu Matsuura for their generous and helpful comments in kick starting this document. We also would like to thank Brian Carpenter, Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, - Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko for their - input. Also a very special thanks to Ron Bonica, Fred Baker, Brian - Haberman, Robert Hinden, Jari Arkko, and Kurt Lindqvist for their - support in bringing this document to the light of IETF working - groups. + Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki + Vatiainen for their input. Also a very special thanks to Ron Bonica, + Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt + Lindqvist for their support in bringing this document to the light of + IETF working groups. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.