doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5952.txt b/doc/rfc/rfc5952.txt
new file mode 100644
index 0000000..56a0e0c
--- /dev/null
+++ b/doc/rfc/rfc5952.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       S. Kawamura
+Request for Comments: 5952                             NEC BIGLOBE, Ltd.
+Updates: 4291                                               M. Kawashima
+Category: Standards Track                       NEC AccessTechnica, Ltd.
+ISSN: 2070-1721                                              August 2010
+
+
+         A Recommendation for IPv6 Address Text Representation
+
+Abstract
+
+   As IPv6 deployment increases, there will be a dramatic increase in
+   the need to use IPv6 addresses in text.  While the IPv6 address
+   architecture in Section 2.2 of RFC 4291 describes a flexible model
+   for text representation of an IPv6 address, this flexibility has been
+   causing problems for operators, system engineers, and users.  This
+   document defines a canonical textual representation format.  It does
+   not define a format for internal storage, such as within an
+   application or database.  It is expected that the canonical format
+   will be followed by humans and systems when representing IPv6
+   addresses as text, but all implementations must accept and be able to
+   handle any legitimate RFC 4291 format.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5952.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 1]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+   (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 Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 2]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
+   2.  Text Representation Flexibility of RFC 4291  . . . . . . . . .  4
+     2.1.  Leading Zeros in a 16-Bit Field  . . . . . . . . . . . . .  4
+     2.2.  Zero Compression . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Uppercase or Lowercase . . . . . . . . . . . . . . . . . .  6
+   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.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 . . . . . . . . . . . . . . . . . . . . . .  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.  Lowercase  . . . . . . . . . . . . . . . . . . . . . . . . 10
+   5.  Text Representation of Special Addresses . . . . . . . . . . . 11
+   6.  Notes on Combining IPv6 Addresses with Port Numbers  . . . . . 11
+   7.  Prefix Representation  . . . . . . . . . . . . . . . . . . . . 12
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  For Developers  . . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 3]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+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
+
+      2001:0db8:0:0:1:0:0:1
+
+      2001:db8::1:0:0:1
+
+      2001:db8::0:1:0:0:1
+
+      2001:0db8::1:0:0:1
+
+      2001:db8:0:0:1::1
+
+      2001:db8:0000:0:1::1
+
+      2001:DB8:0:0:1::1
+
+   All of the above examples represent the same IPv6 address.  This
+   flexibility has caused many problems for operators, systems
+   engineers, and customers.  The problems are noted in Section 3.  A
+   canonical representation format to avoid problems is introduced in
+   Section 4.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Text Representation Flexibility of RFC 4291
+
+   Examples of flexibility in Section 2.2 of [RFC4291] are described
+   below.
+
+2.1.  Leading Zeros in a 16-Bit Field
+
+      'It is not necessary to write the leading zeros in an individual
+      field.'
+
+   Conversely, it is also not necessary to omit leading zeros.  This
+   means that it is possible to select from representations such as
+   those in the following example.  The final 16-bit field is different,
+   but all of these addresses represent the same address.
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 4]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
+
+2.2.  Zero Compression
+
+      'A special syntax is available to compress the zeros.  The use of
+      "::" indicates one or more groups of 16 bits of zeros.'
+
+   It is possible to select whether or not to omit just one 16-bit 0
+   field.
+
+      2001:db8:aaaa:bbbb:cccc:dddd::1
+
+      2001:db8:aaaa:bbbb:cccc:dddd:0:1
+
+   In cases where there is more than one field of only zeros, there is a
+   choice of how many fields can be shortened.
+
+      2001:db8:0:0:0::1
+
+      2001:db8:0:0::1
+
+      2001:db8:0::1
+
+      2001:db8::1
+
+   In addition, Section 2.2 of [RFC4291] notes,
+
+      'The "::" can only appear once in an address.'
+
+   This gives a choice on where in a single address to compress the
+   zero.
+
+      2001:db8::aaaa:0:0:1
+
+      2001:db8:0:0:aaaa::1
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 5]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+2.3.  Uppercase or Lowercase
+
+   [RFC4291] does not mention any preference of uppercase or lowercase.
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
+
+      2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
+
+3.  Problems Encountered with the Flexible Model
+
+3.1.  Searching
+
+3.1.1.  General Summary
+
+   A search of an IPv6 address if conducted through a UNIX system is
+   usually case sensitive and extended options that allow for regular
+   expression use will come in handy.  However, there are many
+   applications in the Internet today that do not provide this
+   capability.  When searching for an IPv6 address in such systems, the
+   system engineer will have to try each and every possibility to search
+   for an address.  This has critical impacts, especially when trying to
+   deploy IPv6 over an enterprise network.
+
+3.1.2.  Searching Spreadsheets and Text Files
+
+   Spreadsheet applications and text editors on GUI systems rarely have
+   the ability to search for text using regular expression.  Moreover,
+   there are many non-engineers (who are not aware of case sensitivity
+   and regular expression use) that use these applications to manage IP
+   addresses.  This has worked quite well with IPv4 since text
+   representation in IPv4 has very little flexibility.  There is no
+   incentive to encourage these non-engineers to change their tool or
+   learn regular expression when they decide to go dual-stack.  If the
+   entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
+   conducted as 2001:db8:0:0:1::1, this will show a result of no match.
+   One example where this will cause a problem is, when the search is
+   being conducted to assign a new address from a pool, and a check is
+   being done to see if it is not in use.  This may cause problems for
+   the end-hosts or end-users.  This type of address management is very
+   often seen in enterprise networks and ISPs.
+
+3.1.3.  Searching with Whois
+
+   The "whois" utility is used by a wide range of people today.  When a
+   record is set to a database, one will likely check the output to see
+   if the entry is correct.  If an entity was recorded as 2001:db8::/48,
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 6]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+   but the whois output showed 2001:0db8:0000::/48, most non-engineers
+   would think that their input was wrong and will likely retry several
+   times or make a frustrated call to the database hostmaster.  If there
+   was a need to register the same prefix on different systems, and each
+   system showed a different text representation, this would confuse
+   people even more.  Although this document focuses on addresses rather
+   than prefixes, it is worth mentioning the prefix problems because the
+   problems encountered with addresses and prefixes are mostly equal.
+
+3.1.4.  Searching for an Address in a Network Diagram
+
+   Network diagrams and blueprints often show what IP addresses are
+   assigned to a system devices.  In 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 stopped at 2001:db8::1, one would
+   search the diagram for that address).  This is a technique quite
+   often in use in enterprise networks and managed services.  Again, the
+   different flavors of text representation will result in a time-
+   consuming search leading to longer mean times to restoration (MTTR)
+   in times of trouble.
+
+3.2.  Parsing and Modifying
+
+3.2.1.  General Summary
+
+   With all the possible methods of text representation, each
+   application must include a module, object, link, etc. to a function
+   that will parse IPv6 addresses in a manner such that no matter how it
+   is represented, they will mean the same address.  Many system
+   engineers who integrate complex computer systems for 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 macros or scripts for 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.  Sometimes logging for critical systems is done by
+   mirroring the same traffic to two different systems.  Care must be
+   taken so that no matter what the log output is, the logs should be
+   parsed so they are equivalent.
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 7]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+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:
+   0000:0000:0000:0001 just because the new engineer on the block felt
+   it was better, a simple diff will show that a different address was
+   configured.  If this was done on a wide scale network, people will be
+   focusing on 'why the extra zeros were put in' instead of doing any
+   real auditing.  Lots of tools are just plain diffs that 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.  The
+   result of an SNMP GET operation, converted to text and compared to a
+   textual address written by a human is highly unlikely to match on the
+   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 field in a
+   certificate was incorrectly verified by converting it to text and
+   making a simple textual comparison to some other address, the
+   certificate may be 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.  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.  Someone familiar with IPv6 address
+   representation will know that the right address is set, but not
+   everyone may understand this.
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 8]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+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 do they have a similar skill level in
+   IPv6 technology.  The network operations center 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 addresses cannot be abbreviated.
+
+3.3.3.  Abuse
+
+   Network abuse reports generally include the abusing IP address.  This
+   'reporting' could take any shape or form of the flexible model.  A
+   team that handles network abuse must be able to tell the difference
+   between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
+   placement of the "::" will result in a critical situation.  A system
+   that handles these incidents should be able to handle any type of
+   input and parse it in a correct manner.  Also, incidents are reported
+   over the phone.  It is unnecessary to report if the letter is
+   uppercase or lowercase.  However, when a letter is spelled uppercase,
+   people tend to specify that it is uppercase, which is unnecessary
+   information.
+
+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 anyway, but flexibility in address representation will increase
+   the 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.
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                    [Page 9]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+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 section SHOULD be followed by systems when generating an
+   address to be represented as text, but all implementations MUST
+   accept and be able to handle 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 MUST be suppressed.  For example, 2001:0db8::0001 is
+   not acceptable and must be represented as 2001:db8::1.  A single 16-
+   bit 0000 field MUST be represented as 0.
+
+4.2.  "::" Usage
+
+4.2.1.  Shorten as Much as Possible
+
+   The use of the symbol "::" MUST be used to its maximum capability.
+   For example, 2001:db8:0:0:0:0:2:1 must be shortened to 2001:db8::2:1.
+   Likewise, 2001:db8::0:1 is not acceptable, because the symbol "::"
+   could have been used to produce a shorter representation 2001:db8::1.
+
+4.2.2.  Handling One 16-Bit 0 Field
+
+   The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field.
+   For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but
+   2001:db8::1:1:1:1:1 is not correct.
+
+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 MUST be shortened (i.e.,
+   the sequence with three consecutive zero fields 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 first sequence of zero
+   bits MUST be shortened.  For example, 2001:db8::1:0:0:1 is correct
+   representation.
+
+4.3.  Lowercase
+
+   The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
+   MUST be represented in lowercase.
+
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 10]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+5.  Text Representation of Special Addresses
+
+   Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
+   IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses
+   embedded in the low-order 32 bits of the address.  These addresses
+   have a special representation that may mix hexadecimal and dot
+   decimal notations.  The decimal notation may be used only for the
+   last 32 bits of the address.  For these addresses, mixed notation is
+   RECOMMENDED if the following condition is met: the address can be
+   distinguished as having IPv4 addresses embedded in the lower 32 bits
+   solely from the address field through the use of a well-known prefix.
+   Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
+   this writing.  If it is known by some external method that a given
+   prefix is used to embed IPv4, it MAY be represented as mixed
+   notation.  Tools that provide options to specify prefixes that are
+   (or are not) to be represented as mixed notation may be useful.
+
+   There is a trade-off here where a recommendation to achieve an exact
+   match in a search (no dot decimals whatsoever) and a recommendation
+   to help the readability of an address (dot decimal whenever possible)
+   does not result in the same solution.  The above recommendation is
+   aimed at fixing the representation as much as possible while leaving
+   the opportunity for future well-known prefixes to be represented in a
+   human-friendly manner as tools adjust to newly assigned prefixes.
+
+   The text representation method noted in Section 4 should be applied
+   for the leading hexadecimal part (i.e., ::ffff:192.0.2.1 instead of
+   0:0:0:0:0:ffff:192.0.2.1).
+
+6.  Notes on Combining IPv6 Addresses with Port Numbers
+
+   There are many different ways to combine IPv6 addresses and port
+   numbers that are represented in text.  Examples are shown below.
+
+   o  [2001:db8::1]:80
+
+   o  2001:db8::1:80
+
+   o  2001:db8::1.80
+
+   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
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 11]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+   IPv6 addresses.  This style is NOT RECOMMENDED because of its
+   ambiguity.  The [] style as expressed in [RFC3986] SHOULD be
+   employed, and is the default unless otherwise specified.  Other
+   styles are acceptable when there is exactly one style for the given
+   context and cross-platform portability does not become an issue.  For
+   URIs containing IPv6 address literals, [RFC3986] MUST be followed, as
+   well as the rules defined in this document.
+
+7.  Prefix Representation
+
+   Problems with prefixes are the same as problems encountered with
+   addresses.  The text representation method of IPv6 prefixes should be
+   no different from that of IPv6 addresses.
+
+8.  Security Considerations
+
+   This document notes some examples where IPv6 addresses are compared
+   in text format.  The example on Section 3.2.5 is one that may cause a
+   security risk if used for access control.  The common practice of
+   comparing X.509 data is done in binary format.
+
+9.  Acknowledgements
+
+   The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
+   and 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,
+   Heikki Vatiainen, Dan Wing, and Doug Barton 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 light in IETF working groups.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2765]      Nordmark, E., "Stateless IP/ICMP Translation Algorithm
+                  (SIIT)", RFC 2765, February 2000.
+
+   [RFC3986]      Berners-Lee, T., Fielding, R., and L. Masinter,
+                  "Uniform Resource Identifier (URI): Generic Syntax",
+                  STD 66, RFC 3986, January 2005.
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 12]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+   [RFC4291]      Hinden, R. and S. Deering, "IP Version 6 Addressing
+                  Architecture", RFC 4291, February 2006.
+
+10.2.  Informative References
+
+   [ADDR-FORMAT]  Bao, C., "IPv6 Addressing of IPv4/IPv6 Translators",
+                  Work in Progress, July 2010.
+
+   [RFC4038]      Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+                  Castro, "Application Aspects of IPv6 Transition",
+                  RFC 4038, March 2005.
+
+   [RFC5214]      Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+                  Automatic Tunnel Addressing Protocol (ISATAP)",
+                  RFC 5214, March 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 13]
+
+RFC 5952                IPv6 Text Representation             August 2010
+
+
+Appendix A.  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,
+   except for the special addresses notes in Section 5.  The function
+   inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
+   be called directly.  See [RFC4038] for details.
+
+Authors' Addresses
+
+   Seiichi Kawamura
+   NEC BIGLOBE, Ltd.
+   14-22, Shibaura 4-chome
+   Minatoku, Tokyo  108-8558
+   JAPAN
+
+   Phone: +81 3 3798 6085
+   EMail: kawamucho@mesh.ad.jp
+
+
+   Masanobu Kawashima
+   NEC AccessTechnica, Ltd.
+   800, Shimomata
+   Kakegawa-shi, Shizuoka  436-8501
+   JAPAN
+
+   Phone: +81 537 23 9655
+   EMail: kawashimam@necat.nec.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kawamura & Kawashima         Standards Track                   [Page 14]
+