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