< draft-kawamura-ipv6-text-representation-00.txt		draft-kawamura-ipv6-text-representation-01.txt >
	Internet Engineering Task Force S. Kawamura		Internet Engineering Task Force S. Kawamura
	Internet-Draft NEC BIGLOBE, Ltd.		Internet-Draft NEC BIGLOBE, Ltd.
	Intended status: Informational M. Kawashima		Intended status: Informational M. Kawashima
	Expires: September 27, 2009 NEC AccessTechnica, Ltd.		Expires: October 23, 2009 NEC AccessTechnica, Ltd.
	March 26, 2009		April 21, 2009
	A Recommendation for IPv6 Address Text Representation		A Recommendation for IPv6 Address Text Representation
	draft-kawamura-ipv6-text-representation-00		draft-kawamura-ipv6-text-representation-01
	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 33 ¶
	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 September 27, 2009.		This Internet-Draft will expire on October 23, 2009.
	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 in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Abstract		Abstract
	As IPv6 network grows, there will be more engineers and also non-		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.		engineers who will have the need to use an IPv6 address in text.
	While the IPv6 address architecture [RFC4291] section 2.2 depicts a		While the IPv6 address architecture [RFC4291] section 2.2 depicts a
	flexible model for text representation of an IPv6 address, this		flexible model for text representation of an IPv6 address, this
	flexibility has been causing problems for operators ,system		flexibility has been causing problems for operators ,system
	engineers, and customers. The following draft will describe the		engineers, and customers. The following draft will describe the
	problems that a flexible text representation has been causing. This		problems that a flexible text representation has been causing. This
	document also recommends a text representation method that best		document also recommends a canonical representation format that best
	avoids confusion.		avoids confusion.
	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 . . . . . . . . . . . . . . . . . . . . . . 4		2.1. leading zeros . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. zero compression . . . . . . . . . . . . . . . . . . . . . 5		2.2. zero compression . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 6		2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 6
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 35 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . 9		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 . . . . . . . . . . . . . . . . . . 10		4.1. Handling Leading Zeros . . . . . . . . . . . . . . . . . . 10
	4.2. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10		4.2. "::" usage . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. "::" usage . . . . . . . . . . . . . . . . . . . . . . . . 10		4.2.1. shorten as much as possible . . . . . . . . . . . . . 10
	4.3.1. shorten as much as possible . . . . . . . . . . . . . 10		4.2.2. one 16bit 0 field . . . . . . . . . . . . . . . . . . 10
	4.3.2. one 16bit 0 field . . . . . . . . . . . . . . . . . . 10		4.2.3. when "::" can be used twice . . . . . . . . . . . . . 10
	4.3.3. when "::" can be used twice . . . . . . . . . . . . . 10		4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. IPv6 Addresses with Embedded IPv4 Addresses . . . . . 12
			Appendix B. For developers . . . . . . . . . . . . . . . . . . . 12
			Appendix C. Prefix Issues . . . . . . . . . . . . . . . . . . . . 12
			Appendix D. Phonetic Alphabet and Figure Code . . . . . . . . . . 12
			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.
	2001:db8:0:0:1:0:0:1/128		2001:db8:0:0:1:0:0:1
	2001:0db8:0:0:1:0:0:1/128		2001:0db8:0:0:1:0:0:1
	2001:db8::1:0:0:1/128		2001:db8::1:0:0:1
	2001:db8::0:1:0:0:1/128		2001:db8::0:1:0:0:1
	2001:0db8::1:0:0:1/128		2001:0db8::1:0:0:1
	2001:db8:0:0:1::1/128		2001:db8:0:0:1::1
	2001:db8:0000:0:1::1/128		2001:db8:0000:0:1::1
	2001:DB8:0:0:1::1/128		2001:DB8:0:0:1::1
	All the above point to the same IPv6 address. This flexiblity has		All the above point to the same IPv6 address. This flexiblity has
	caused many problems for operators, systems engineers, and customers.		caused many problems for operators, systems engineers, and customers.
	The problems will be noted in section 3.		The problems will be noted in section 3. Also, a canonical
			representation format to avoid problems will be introduced in section
			4.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Text representation flexibility of RFC4291		2. Text representation flexibility of RFC4291
	Examples of flexibility in Section 2.2 of RFC4291 are described		Examples of flexibility in Section 2.2 of RFC4291 are described
	below.		below.
	2.1. leading zeros		2.1. leading zeros
	'It is not necessary to write the leading zeros in an individual		'It is not necessary to write the leading zeros in an individual
	field.'		field.'
	In other words, it is also not necessary to omit leading zeros. This		In other words, it is also not necessary to omit leading zeros. This
	means that, it is possible to select such as the following example.		means that, it is possible to select from such as the following
	Last 16bit is different, but all these addresses are the same.		example. The final 16bit field is different, but all these addresses
			are the same.
	2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001/128		2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
	2001:db8:aaaa:bbbb:cccc:dddd:eeee:001/128		2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
	2001:db8:aaaa:bbbb:cccc:dddd:eeee:01/128		2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
	2001:db8:aaaa:bbbb:cccc:dddd:eeee:1/128		2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
	2.2. zero compression		2.2. zero compression
	'A special syntax is available to compress the zeros. The use of		'A special syntax is available to compress the zeros. The use of
	"::" indicates one or more groups of 16 bits of zeros.'		"::" indicates one or more groups of 16 bits of zeros.'
	It is possible to select whether or not to omit just one 16bits of		It is possible to select whether or not to omit just one 16bits of
	zeros.		zeros.
	2001:db8:aaaa:bbbb:cccc:dddd::1/128		2001:db8:aaaa:bbbb:cccc:dddd::1
	2001:db8:aaaa:bbbb:cccc:dddd:0:1/128		2001:db8:aaaa:bbbb:cccc:dddd:0:1
	In case where there are more than one zero fields, there is a choice		In case where there are more than one zero fields, there is a choice
	of how much fields to shorten, such as described in the following		of how many fields can be shortened. Examples follow.
	example. It is not necessary to omit the fields completely.
	2001:db8:0:0:0::1/128		2001:db8:0:0:0::1
	2001:db8:0:0::1/128		2001:db8:0:0::1
	2001:db8:0::1/128		2001:db8:0::1
	2001:db8::1/128		2001:db8::1
	... and more		... and more
	In addition, RFC4291 in section 2.2 notes,		In addition, RFC4291 in section 2.2 notes,
	'The "::" can also be used to compress leading or trailing zeros		'The "::" can also be used to compress leading or trailing zeros
	in an address.'		in an address.'
	Therefore, it is possible to select such as the following example.		It is possible to choose whether to compress a leading zero or a
			trailing zero in a single address. Examples are shown below.
	2001:db8::aaaa:0:0:1/128		2001:db8::aaaa:0:0:1
	2001:db8:0:0:aaaa::1/128		2001:db8:0:0:aaaa::1
	2.3. Uppercase or Lowercase		2.3. Uppercase or Lowercase
	RFC4291 does not mention about Uppercase and Lowercase. Because it's		RFC4291 does not mention about preference of uppercase or lowercase.
	probably not special. However, it is possible to select such as the		Various flavors are shown below.
	following example. Last 16bit is different, but these are the same.
	2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa/128		2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
	2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA/128		2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
	2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa/128		2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
	... more combinations		... more combinations
	3. Problems Encountered with the Flexible Model		3. Problems Encountered with the Flexible Model
	3.1. Searching		3.1. Searching
	3.1.1. General Summary		3.1.1. General Summary
	A search of an IPv6 address if conducted through a UNIX system is		A search of an IPv6 address if conducted through a UNIX system is
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 15 ¶
	3.1.3. Searching with Whois		3.1.3. Searching with Whois
	The whois utility is used by a wide range of people today. When a		The whois utility is used by a wide range of people today. When a
	record is set to the whois database, one will likely check the output		record is set to the whois database, one will likely check the output
	to see if the entry is correct. If a entity was recorded as 2001:		to see if the entry is correct. If a entity was recorded as 2001:
	db8::/48, but the whois ouput showed 2001:0db8:0000::/48, most non-		db8::/48, but the whois ouput showed 2001:0db8:0000::/48, most non-
	engineers would think that their input was wrong, and will likely		engineers would think that their input was wrong, and will likely
	retry several times or make a frustrated call to the database		retry several times or make a frustrated call to the database
	hostmaster. If there was a need to register the same address on		hostmaster. If there was a need to register the same address on
	different systems, and each system showed a different text		different systems, and each system showed a different text
	representation, this would confuse people even more.		representation, this would confuse people even more. Although this
			document focuses on addresses rather than prefixes, this is worth
			mentioning since problems encountered are mostly equal.
	3.1.4. Searching for an Address in a Network Diagram		3.1.4. Searching for an Address in a Network Diagram
	Network diagrams and blue-prints contain IP addresses of systems. In		Network diagrams and blue-prints contain IP addresses of systems. In
	times of trouble shooting, there may be a need to search through a		times of trouble shooting, there may be a need to search through a
	diagram to find the point of failure (for example, if a traceroute		diagram to find the point of failure (for example, if a traceroute
	stopped at 2001:db8::1, one would search the diagram for that		stopped at 2001:db8::1, one would search the diagram for that
	address). This is a technique quite often in use in enterprise		address). This is a technique quite often in use in enterprise
	networks and managed services. Again, the different flavors of text		networks and managed services. Again, the different flavors of text
	representation will result in a time-consuming search, leading to		representation will result in a time-consuming search, leading to
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 36 ¶
	Node configurations will be matched against a information system that		Node configurations will be matched against a information system that
	manages IP addresses. If output notation is different, there will		manages IP addresses. If output notation is different, there will
	need to be a script that is implemented to cover for this. An SNMP		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		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. Unexpected Modifying		3.2.5. 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 router may take an input of		convenience. For example, a system may take an input of
	2001:0db8:0::1 and make the ouput 2001:db8::1 (which is seen in som		2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some
	RIR databases). If the zeros were inputed for a reason, the outcome		RIR databases). If the zeros were inputed 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/128, 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/128. A distinguished engineer will know		result as 2001:DB8::1:0:0:1. A distinguished engineer will know that
	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. Again, the extra load in checking
	that the IP address is the same as was intended, will result in fees		that the IP address is the same as was intended, will result in fees
	that will be charged to the customers.		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.
	skipping to change at page 9, line 48 ¶		skipping to change at page 9, line 49 ¶
	work load which will again, result in fees that will be charged to		work load which will again, result in fees that will be charged to
	the customers, and also longer down time of systems.		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 case D and 0 can be quite often misread. Capital B and 8 can
			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
			addresses is presented in this section. The recommendation in this
			document is one that, complies fully with RFC 4291, is implemented by
			various operating systems, and is human friendly.
	4.1. Handling Leading Zeros		4.1. Handling Leading Zeros
	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 mis-reading.		just 0. Place holder zeros are often cause of mis-reading.
	4.2. Lower Case		4.2. "::" usage
	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.
	4.3. "::" usage
	4.3.1. shorten as much as possible		4.2.1. shorten as much as possible
	The use of "::" should be used to its maximum capability (i.e. 2001:		The use of "::" should be used to its maximum capability (i.e. 2001:
	db8::0:1/128 is not very clean).		db8::0:1 is not very clean).
	4.3.2. one 16bit 0 field		4.2.2. one 16bit 0 field
	"::" should not be used to shorten just one 16bit 0 field for it		"::" should not be used to shorten just one 16bit 0 field for it
	would tend to mislead that there are more than one 16 bit field that		would tend to mislead that there are more than one 16 bit field that
	is shortened.		is shortened.
	4.3.3. when "::" can be used twice		4.2.3. when "::" can be used twice
	When cases where it is possible to use "::" in two or more different		When cases where it is possible to use "::" in two or more different
	sections of an address, implementation to shorten the side with more		sections of an address, implementation to shorten the side with more
	16bit 0 fields are more common (i.e. latter is shortened in 2001:0:0:		16bit 0 fields are more common (i.e. latter is shortened in 2001:0:0:
	1:0:0:0:1/128). When the length of 16bit 0 fields are equal (i.e.		1:0:0:0:1). When the length of 16bit 0 fields are equal (i.e. 2001:
	2001:db8:0:0:1:0:0:1/128), the former is usually shortened. One idea		db8:0:0:1:0:0:1), the former is usually shortened. One idea to avoid
	to avoid any confusion, is for the operator to not use 16bit field 0		any confusion, is for the operator to not use 16bit field 0 in the
	in the first 64 bits. By nature IPv6 addresses are usually assigned		first 64 bits. By nature IPv6 addresses are usually assigned or
	or allocated to end-users as longer than 32 bits (typicaly 48bit or		allocated to end-users as longer than 32 bits (typicaly 48bit or
	longer).		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. Conclusion		5. Conclusion
	For developers, it is recommended that they use inet_ntop() or		The recommended format of text representing an IPv6 address is
	WSAAddressToString(). These have a consistent rule with this draft.		summarized as follows.
	If you have difficulties using these functions, it is desirable to
	adapt the recommended rule. For all those who have the need of text
	representing an IPv6 address, the following is a summary of the
	recommended rules.
	(1) omit leading zeros		(1) omit leading zeros
	(2) use lower case		(2) "::" used to their maximum extent whenever possible
	(3) "::" used to their maximum extent whenever possible		(3) "::" used where shortens address the most
	(4) "::" used where shortens address the most		(4) "::" used in the former part in case of a tie breaker
	(5) "::" used in the former part in case of a tie breaker		(5) do not shorten one 16bit 0 field
	(6) do not shorten one 16bit 0 field		(6) use lower case
			Hints for developers are written in the Appendix section.
	6. Security Considerations		6. Security Considerations
	None.		None.
	7. IANA Considerations		7. IANA Considerations
	None.		None.
	8. Acknowledgements		8. Acknowledgements
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	9.2. Informative References		9.2. Informative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.		[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
	Stevens, "Basic Socket Interface Extensions for IPv6",		Stevens, "Basic Socket Interface Extensions for IPv6",
	RFC 3493, February 2003.		RFC 3493, February 2003.
			[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
			Castro, "Application Aspects of IPv6 Transition",
			RFC 4038, March 2005.
			[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
			April 2008.
			Appendix A. IPv6 Addresses with Embedded IPv4 Addresses
			IPv4-Compatible IPv6 address and IPv4-Mapped IPv6 address are defined
			that carry an IPv4 address in the low-order 32 bits of the address.
			These addresses have special representation that combine hexadecimal
			and decimal notations. IPv4-Compatible IPv6 address is deprecated.
			Although the use of IPv4-Mapped IPv6 address is not recommended due
			to security and portability problems, the text representation method
			noted in this document should be applied for the hexadecimal part.
			Appendix B. For developers
			We recommend that developers use display routines that conform to
			these rules. For example, the usage of getnameinfo() with flags
			argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output.
			The function inet_ntop() of FreeBSD7.0 is a good C code reference,
			but should not be called directly. See RFC4038 for details.
			Appendix C. Prefix Issues
			Problems with prefixes are just the same as problems encountered with
			addresses. Text representation method of IPv6 prefixes should be no
			different from that of IPv6 addresses.
			Appendix D. Phonetic Alphabet and Figure Code
			The use of Phonetics Alphabet is essential for complete accuracy in
			voice communications. For example, ITU Phonetic alphabet and Figure
			Code is as follows (extracted hexadecimal from it):
			+-----------+------------+----------------------+
			| Character | Word | Pronunciation |
			+-----------+------------+----------------------+
			| 0 | Nadazero | NAH-DAH-ZAY-ROH |
			| 1 | Unaone | OO-NAH-WUN |
			| 2 | Bissotwo | BEES-SOH-TOO |
			| 3 | Terrathree | TAY-RAH-TREE |
			| 4 | Kartefour | KAR-TAY-FOWER |
			| 5 | Pantafive | PAN-TAH-FIVE |
			| 6 | Soxisix | SOK-SEE-SIX |
			| 7 | Setteseven | SAY-TAY-SEVEN |
			| 8 | Oktoeight | OK-TOH-AIT |
			| 9 | Novenine | NO-VAY-NINER |
			| A | Alfa | AL FAH |
			| B | Bravo | BRAH VOH |
			| C | Charlie | CHAR LEE or SHAR LEE |
			| D | Delta | DELL TAH |
			| E | Echo | ECK OH |
			| F | Foxtrot | FOKS TROT |
			+-----------+------------+----------------------+
	Authors' Addresses		Authors' Addresses
	Seiichi Kawamura		Seiichi Kawamura
	NEC BIGLOBE, Ltd.		NEC BIGLOBE, Ltd.
	14-22, Shibaura 4-chome		14-22, Shibaura 4-chome
	Minatoku, Tokyo 108-8558		Minatoku, Tokyo 108-8558
	JAPAN		JAPAN
	Phone: +81 3 3798 6085		Phone: +81 3 3798 6085
	Email: kawamucho@mesh.ad.jp		Email: kawamucho@mesh.ad.jp
End of changes. 53 change blocks.
	77 lines changed or deleted		147 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/