Subject: I-D Action:draft-ietf-6man-text-addr-representation-02.txt

From: [email-masked]
Date: Mon, 9 Nov 2009 20:30:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : A Recommendation for IPv6 Address Text Representation
	Author(s)       : S. Kawamura, M. Kawashima
	Filename        : draft-ietf-6man-text-addr-representation-02.txt
	Pages           : 14
	Date            : 2009-11-09

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

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 14, 2010.Copyright Notice

Copyright (c) 2009 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 BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-text-addr-representation-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Роман Донченко <[email-masked]>
Date: Sun, 15 Nov 2009 02:06:44 +0300

Hello,

(don't mind if any copies of this message arrive; I'm trying to wrestle  
Gmane into sending to this list)

<[email-masked]> писал в своём письме Tue, 10 Nov 2009 07:30:01  

> 	Filename        : draft-ietf-6man-text-addr-representation-02.txt

Reading this the second time, I'm not sure I'm satisfied with how Section  
5 turned out to be. In particular, this:

> However, there may be
> situations where hexadecimal representation is chosen to meet certain
> needs.  Addressing those needs is out of the scope of this document.

It's rather vague, and I think the recently added Section 3.2.5 offers an  
example that's close having such needs. If for some reason a textual  
comparison of addresses is done in the course of a protocol (don't know  
how likely it is, but can certainly happen), a strictly canonical format  
is required, and Section 5 currently gives some leeway in this matter  
(since different systems may have different knowledge about existing  
address types). Perhaps, especially since this is a standards track  
document now, such a strict format should be specified, to save protocol  
developers the trouble of doing it themselves.

I think that for such a "really canonical" representation, we can just  
forbid using the mixed notation. The reasons for this are that it's the  
simplest definition, the easiest to implement and doesn't single out any  
particular transition technologies. An alternative would be to mandate  
mixed notation for IPv4-mapped and IPv4-compatible addresses and  
hexadecimal representation for everything else, for compatibility with  
current implementations of inet_ntop. However, I don't think that such  
compatibility matters much, because there are no consistency requirements  
for inet_ntop and to ensure canonicity developers will be required to  
implement their own functions, anyway.

Another difference, however nominal, is that for such a strict  
representation, the recommendations in Section 7 will become requirements.

More comments:

> In
> cases where there is a choice of whether to express the address as
> fully hexadecimal or hexadecimal and decimal mixed,

I think this can be safely removed. I maintain that the decription in RFC  
4291 allows to use the mixed notation for any addresses, making this  
fragment a tautology.
Plus, the next fragment makes it redundant in any case:

> if the
> address type can be distinguished as having IPv4 addresses embedded
> in the lower 32 bits solely from the 128bits of the address field
> itself

While I'm at it, typo patrol: there's a space missing between "128" and  
"bits", and it should probably say just "address", not "address field".

Finally, I suggest to place an example of mixed notation in Section 1, so  
that it fully covers the address syntax.

Regards,
Roman.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 15 Nov 2009 08:18:11 +0100

> implement their own functions, anyway.

For what its worth, draft-ietf-netmod-yang-types-04.txt only uses the
hexadecimal format for the ipv6-address data type. This simplifies
things since all IPv6 addresses have the same format - and it does not
matter how an address was generated when it comes to questions such as
ordering of addresses. I would prefer if the wording in this document
allows for the single representation approach taken in the above
mentioned document.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>