A Recommendation for IPv6 Address Text Representation
draft-kawamura-ipv6-text-representation-03
Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Seiichi Kawamura , Masanobu Kawashima | ||
Last updated | 2009-08-27 (Latest revision 2009-06-12) | ||
Replaced by | draft-ietf-6man-text-addr-representation | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Replaced by draft-ietf-6man-text-addr-representation | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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 customers. 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 generating an address to represent as text, but all implementations must accept any legitimate RFC4291 format.
Authors
Seiichi Kawamura
Masanobu Kawashima
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)