draft-ietf-6man-text-addr-representation-05.txt   draft-ietf-6man-text-addr-representation-06.txt 
IPv6 Maintenance Working Group S. Kawamura IPv6 Maintenance Working Group S. Kawamura
Internet-Draft NEC BIGLOBE, Ltd. Internet-Draft NEC BIGLOBE, Ltd.
Updates: 4291 (if approved) M. Kawashima Updates: 4291 (if approved) M. Kawashima
Intended status: Standards Track NEC AccessTechnica, Ltd. Intended status: Standards Track NEC AccessTechnica, Ltd.
Expires: August 21, 2010 February 17, 2010 Expires: August 23, 2010 February 19, 2010
A Recommendation for IPv6 Address Text Representation A Recommendation for IPv6 Address Text Representation
draft-ietf-6man-text-addr-representation-05 draft-ietf-6man-text-addr-representation-06
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 RFC 4291 section 2.2 depicts a While the IPv6 address architecture RFC 4291 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 users. This document will describe the problems that engineers, and users. This document will describe the problems that
a flexible text representation has been causing. This document also a flexible text representation has been causing. This document also
skipping to change at page 1, line 48 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 August 21, 2010. This Internet-Draft will expire on August 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 11, line 8 skipping to change at page 11, line 8
Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
IPv4-translatable addresses [I-D.ietf-behave-address-format] have IPv4-translatable addresses [I-D.ietf-behave-address-format] have
IPv4 addresses embedded in the low-order 32 bits of the address. IPv4 addresses embedded in the low-order 32 bits of the address.
These addresses have special representation that may mix hexadecimal These addresses have special representation that may mix hexadecimal
and dot decimal notations. The decimal notation may be used only for and dot decimal notations. The decimal notation may be used only for
the last 32 bits of the address. For these addresses, mixed notation the last 32 bits of the address. For these addresses, mixed notation
is RECOMMENDED if the following condition is met: The address can be is RECOMMENDED if the following condition is met: The address can be
distinguished as having IPv4 addresses embedded in the lower 32 bits distinguished as having IPv4 addresses embedded in the lower 32 bits
solely from the address field through the use of a well known prefix. solely from the address field through the use of a well known prefix.
Such prefixes are defined in [RFC4291] and [RFC5214] at the time of Such prefixes are defined in [RFC4291] and [RFC2765] at the time of
writing. If it is known by some external method that a given prefix writing. If it is known by some external method that a given prefix
includes an IPv4 address, it MAY be represented as mixed notation. is used to embed IPv4, it MAY be represented as mixed notation.
Tools that provide options to specify prefixes that is (or is not) to Tools that provide options to specify prefixes that are (or are not)
be represented as mixed notation may be useful. to be represented as mixed notation may be useful.
There is a trade-off here where a recommendation to achieve exact There is a trade-off here where a recommendation to achieve exact
match in a search (no dot decimals whatsoever) and recommendation to match in a search (no dot decimals whatsoever) and recommendation to
help the readability of an addresses (dot decimal whenever possible) help the readability of an addresses (dot decimal whenever possible)
does not result in the same solution. The above recommendation is does not result in the same solution. The above recommendation is
aimed at fixing the representation as much as possible while leaving aimed at fixing the representation as much as possible while leaving
the opportunity for future well known prefixes to be represented in a the opportunity for future well known prefixes to be represented in a
human friendly manner as tools adjust to newly assigned prefixes. human friendly manner as tools adjust to newly assigned prefixes.
The text representation method noted in Section 4 should be applied The text representation method noted in Section 4 should be applied
skipping to change at page 12, line 42 skipping to change at page 12, line 42
and Kurt Lindqvist for their support in bringing this document to the and Kurt Lindqvist for their support in bringing this document to the
light of IETF working groups. light of IETF working groups.
11. References 11. References
11.1. Normative References 11.1. Normative 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.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
11.2. Informative References 11.2. Informative References
[I-D.ietf-behave-address-format] [I-D.ietf-behave-address-format]
Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-04 (work in progress), draft-ietf-behave-address-format-04 (work in progress),
January 2010. January 2010.
 End of changes. 6 change blocks. 
7 lines changed or deleted 10 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/