A Recommendation for IPv6 Address Text Representation
draft-ietf-6man-text-addr-representation-07

Waiting for other ADs to determine if they are happy with the new revision. I have reviewed the new version and the discussion, and the outcome seems sensible.

[Ballot discuss]
DISCUSS

I would be happy to change my DISCUSS to a YES if the following changes are made:

DOCUMENT STATUS

As far as I can see, this memo doesn't change anything that goes on the wire. It is more about textual representations in logs, etc. So, shouldn't it be a BCP as opposed to a PS document?


OLD TEXT
Leading zeros should be chopped for human legibility and easier
searching.  Also, a single 16 bit 0000 field should be represented as
just 0.

NEW TEXT
Leading zeros MUST be supressed. A single 16 bit 0000 field MUST be represented as 0.


OLD TEXT
The use of "::" should be used to its maximum capability (i.e. 2001:
db8::0:1 is not considered as clean representation).

NEW TEXT
The symbol "::" MUST be used to its maximum capability. For example, the representation 2001:db8::0:1 is not acceptable, because the symbol "::" could have been used to produce the shorter representation 2001:db8::1.


OLD TEXT
"::" should not be used to shorten just one 16 bit 0 field for it
would tend to mislead that there are more than one 16 bit field that
is shortened.

NEW TEXT
The symbol "::" MUST not be used to shorten a single 16 bit 0 field. For example, the representation 2001:db8:1:1:1:1:0:1 is correct. The representation 2001:db8:1:1:1:1:::1is not.

OLD TEXT
When there is an alternative choice in the placement of a "::", the
longest run of consecutive 16 bit 0 fields should be shortened (i.e.
latter 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 former is shortened.  This is consistent with many current
implementations.  One idea to avoid any confusion, is for the
operator to not use 16 bit field 0 in the first 64 bits.  By nature
IPv6 addresses are usually assigned or allocated to end-users from a
prefix of 32 bits or longer (typically 48 bits or longer).

NEW TEXT
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.
latter 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 former MUST BE shortened.

OLD TEXT
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.

NEW TEXT
When an IPv6 representation includes the characters "a", "b", "c", "d", "e" or "f", the MUST be represented in lower case.


Also, the bullet list in Section  8 should include RFC 2119 language.

[Ballot comment]
I am supporting Lars and Ralphs discusses.

I think specifying a true canonical form at PS level is a good thing. However, the users of this form need to select it themselves.

[Ballot comment]
1. If the recommendations in the document apply to prefixes and not only to addresses as section 7 seems to indicate this needs to be said in the introduction, maybe even in the title.

2. in section 4.2.1 - 'is not considered as clean representation' does not sound good as a normative sentence - probably better say 'is not recommended' (or 'is NOT RECOMMENDED').

3. Security considerations - one can make the argument that following the recommendations in this document leads to an increase in the security of the network, by increasing the efficiency of the abuse handling activities as described in 3.3.3, and by eliminating some of the ambiguities in expressing addresses in various formats, which could potentially be exploited for attacks.

[Ballot discuss]
Part of the issues were brought-up by OPS-DIR reviewer David Kessens.

1. The intended PS status does not fit the content of the document. The document fails to define one canonical representation in MUST terms, and the recommendations in the text are more suitable to an Informational RFC.

2. If the document stays or is modified to stay as standards-track the requirements in sections 4,5,6 should follow the 2119 capitalization rules.

3. Section 4.2.3 is not clear. It mentions 'former is shortened'. When talking bits and bytes, it seems better to say something like the 'first sequence of zero bits'. I have a suspicion what the 'former'
means here but it is not very well spelled out.

Also:

'One idea to avoid any confusion, is for the operator to not use
16 bit field 0 in the first 64 bits.'

seems a bit strange suggestion to the problem, as there is also a certain operational convenience in using the easy addresses in the operators network for example. I suggest leaving this sentence out.

4. in Section 5 - Text Representation of Special Addresses:

Allowing a different canonical notation for addresses with embedded
IPv4 addresses seems to undermine the goal of a canonical notation:
eg. this way there are really two notations and the advantage of a canonical notation dispappears. I understant the problem that it is hard to make a choice in that particular case but I believe that making a choice is better than not making one and aloowing for exceptions.

[Ballot discuss]
This document is likely not very useful as a Proposed Standard in its current form.  It needs to be either prescriptive, providing explicit rules through which arbitrary addresses can be reliably translated into a canonical representation, or advisory (and published as Informational), as it is currently, which, e.g., application developers can use as a guideline.

[Ballot comment]
Support Lars' discuss

In section 4.2.3, these two sentences are particularly hard to parse:
  "One idea to avoid any confusion, is for the
  operator to not use 16 bit field 0 in the first 64 bits.  By nature
  IPv6 addresses are usually assigned or allocated to end-users from a
  prefix of 32 bits or longer (typically 48 bits or longer)."

Please consider making it clear that the first sentence is an observation about existing practices, not a recommendation or requirement. I'm not sure what the second sentence is trying to accomplish.

[Ballot discuss]
I agree a canonical forma is needed for all the reasons provided. But this does not provide one. Is there any good reasons not to have this RFC define a canonical form and other RFC and applications can decide if they want to use it or not.

Section 5: I don't see how an application will know to use hex or decimal for lower 32 bits. IANA could add new special prefixes at any point in time.

Saying existing system should switch to this is just not really practical. I would prefer to see has as a specification that future protocols or updates to protocols could adopt as MUST or SHOULD implement. More specifically, I do not thing that a PS document like this could imply that some other protocol, say SIP, was somehow not compliant with the SIP standard if it was not doing it this way.

[Ballot comment]
Language & grammar are rough.

Section 3 is trivial and much too long. Suggest to summarize into 1-2 paragraphs and move the long version to an appendix.

[Ballot discuss]
The problem that this document tries to address is in short: "RFC4291 allows one IPv6 address to be represented by several text strings. This makes it hard to know which text string to use when dealing with O&M stuff, which is confusing and error-prone." No disagreement so far.

Based on this, the document says it will specify a "canonical representation" of IPv6 addresses in text strings what will address these issues (while still being conformant to, i.e., a subset of, what was allowed by RFC4291.) Consequently, I was expecting some rules that map an IPv6 address into a single, unique textual representation (and back).

But the canonical representation in Section 4 doesn't do that. It eliminates some of the flexibility that RFC4291 allows, but still leaves more than enough of it (note the absence of MUST) so that none of the confusion Section 3 describes will really be eliminated.

Maybe I misunderstood, but if I didn't, what purpose does this document serve?

[Ballot comment]
Section 1

I found the Introduction rather terse. I suggest reproducing some of
the text from the Abstract.

The section would benefit from a reference (presumably to RFC 4291) to
show on what you base your address representations

OLD
All the above point to the same IPv6 address
NEW
All the above represent the same IPv6 address

---

Section 4

The rules in section 4 could be clarified somewhat with examples of
good representation and their meaning as full addresses.

---

Nit

Section 2.2

In case where there are more than one zero fields

s/are/is/

[Ballot discuss]
Useful work. Thanks.
Just a couple of points I would like to Discuss before recommending publication of this document.

It is not clear to me whether this document updates RFC 4291. I would
welcome a quick discussion of this issue.

I am not completely clear on the use of RFC 2119 language in the
document. Section 4 uses SHOULD and MUST in the preamble, and in my view these words apply to the whole section and so no further 2119 language is
needed within the section. However, sections 5 and 6 are outside the
scope of the preamble of section 4 - should they use 2119 language?

I have reviewed this draft.

Overall, this is a long overdue change and I want to move forward with this document. There were a couple of issues I wanted to talk to the working group before sending the draft to last call, however.

First just an observation. I felt that the motivation part of the draft was unnecessarily long and at times not fully waterproof. I think the draft would have been stronger by making a short statement about the types of problems caused by flexible format rules. I have included some specific detailed issues below. I'd like you to correct those, but I'm not asking for a bigger rewrite. The important part of this draft is the recommendation.

Second, I am not entirely comfortable with Section 5 and 6 recommendations, as they do not actually specify a format that can be deterministically followed by all parties. I have included some suggestions below on how this could be fixed. My understanding is that there was some discussion in the working group along these lines earlier. I don't want to oppose the working group's opinion if you really think that the current text is the best we can do. However, I wanted to have a discussion before we proceed.

Third, I would suggest that the draft should be extended to explicitly cover prefix formats as well.

Detailed comments:

> An SNMP GET of an interface address and text representation in a humanly written text file is highly unlikely to match on first try.

The result of an SNMP GET operation, converted to text and a textual address written by a human is highly unlikely to match on first try.l

(SNMP returns binary)

> Some protocols require certain data fields to be verified.  One
> example of this is X.509 certificates.  If an IPv6 address was
> embedded in one of the fields in a certificate, and the verification
> was done by just a simple textual comparison, the certificate may be
> mistakenly shown as being invalid due to a difference in text
> representation methods.

But the IP address fields in certificates are in binary, not text. In order for this to happen the implementation would have to convert binary to text and compare it to some other data that is either already in text or was converted to text with a different algorithm. Suggested rewrite:

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.

> For example, a system may take an input of
> 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some
> RIR databases).

Remove the sentence in parentheses (its not quite clear where "which" refers to).

>  A distinguished engineer will know that
>  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
>  distinguished as we would like.

Maybe better as "Someone familiar with IPv6 address representation knows that the right address is set, but not everyone may understand this."

> NOC

network operations center

> Usually, a change in a platform (e.g.
>    Unix to Windows, Cisco to Juniper) will result in a major change of
>    code, but flexibility in address representation will increase the
>    work load.

Maybe better as: ... major change of code anyway, but ...

>    With all the possible text representation ways, each application must
>    include a module, object, link, etc. to a function that will parse
>    IPv6 addresses in a manner that no matter how it is represented, they
>    will mean the same address.  This is not too much a problem if the
>    output is to be just 'read' or 'managed' by a network engineer.
>    However, many system engineers who integrate complex computer systems
>    to 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 macro's or scripts for
>    their customers.
...
>  The
>    recommendation in this document SHOULD be followed by systems when
>    generating an address to represent as text, but all implementations
>    MUST accept any legitimate [RFC4291] format.  It is advised that
>    humans also follow these recommendations when spelling an address.

I'll note that as long as we must accept any legitimate 4291 format, all implementations still need that function that the first text excerpt talks about.

> Place holder zeros are often cause of misreading.

This text in Section 4 is redundant, well described earlier. Just delete this.

> together, there seems to be many different ways to do so.  Examples

s/seems to be/are/


>    However, there may be situations where full hexadecimal
>    representation is chosen to meet certain needs.  Addressing those
>    needs is out of the scope of this document.  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).
Is the last sentence connected to the rest of this paragraph? I think not. If so, move that sentence out of this paragraph, and place a new paragraph before it.

Sections 5 and 6 are not as strict with respect to recommending a single choice as would perhaps be desirable. Is there a reason why the second alternative in Section 5 can't be removed and the RFC 3986 format be chosen as mandatory in Section 6? For Section 5 I thought that was actually what we had discussed on the list. In other words, change:

OLD:
For these addresses, mixed notation is recommended if either of the below conditions are met.

(1) The address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field. (e.g. Well Known Prefixes)

(2) An external mechanism such as prefix learning or pre-configuration helps in recognizing the address as having IPv4 addresses embedded in the lower 32 bits.
NEW:
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 [RFC 4291]. Note that this prevents the use of the mixed notation on some addresses that employ a dynamically chosen prefix. However, it was felt that the benefits of deterministic text representation outweigh the benefits of human readability in this case.

And

OLD:
The [] style as expressed in [RFC3986] is recommended.  Other styles are acceptable when cross-platform portability does not become an issue.
NEW:
The [] style as expressed in [RFC3986] should be employed, and is the default format unless otherwise specified. Other styles are acceptable when there is exactly one style for the given context. For instance, a given protocol specification might indicate that the '#' format is used.

Is there reason why we can't simply recommend the specified algorithm to be followed for prefixes as well?

Advancement Questionnaire for

> > (1.a) Who is the Document Shepherd for this document? Has the
> >      Document Shepherd personally reviewed this version of the
> >      document and, in particular, does he or she believe this
> >      version is ready for forwarding to the IESG for publication?

Bob Hinden.  I think the document is ready for publication.

> >
> > (1.b) Has the document had adequate review both from key WG members
> >      and from key non-WG members? Does the Document Shepherd have
> >      any concerns about the depth or breadth of the reviews that
> >      have been performed? 

This document has received adequete review and the shepherd does not
have any concerns with those reviews.

> >
> > (1.c) Does the Document Shepherd have concerns that the document
> >      needs more review from a particular or broader perspective,
> >      e.g., security, operational complexity, someone familiar with
> >      AAA, internationalization or XML?

No.

> >
> > (1.d) Does the Document Shepherd have any specific concerns or
> >      issues with this document that the Responsible Area Director
> >      and/or the IESG should be aware of? For example, perhaps he
> >      or she is uncomfortable with certain parts of the document, or
> >      has concerns whether there really is a need for it. In any
> >      event, if the WG has discussed those issues and has indicated
> >      that it still wishes to advance the document, detail those
> >      concerns here. Has an IPR disclosure related to this document
> >      been filed? If so, please include a reference to the
> >      disclosure and summarize the WG discussion and conclusion on
> >      this issue.

No concerns.

> >
> > (1.e) How solid is the WG consensus behind this document? Does it
> >      represent the strong concurrence of a few individuals, with
> >      others being silent, or does the WG as a whole understand and
> >      agree with it? 

The 6man working group understands and supports this document.

> >
> > (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> >      discontent? If so, please summarise the areas of conflict in
> >      separate email messages to the Responsible Area Director. (It
> >      should be in a separate email because this questionnaire is
> >      entered into the ID Tracker.)

No.

> >
> > (1.g) Has the Document Shepherd personally verified that the
> >      document satisfies all ID nits? (See the Internet-Drafts Checklist
> >      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
> >      not enough; this check needs to be thorough. Has the document
> >      met all formal review criteria it needs to, such as the MIB
> >      Doctor, media type and URI type reviews?


The ID Nits tool shows two issues.  The first is the a prefix not in RFC3849's suggested 2001:DB8::/32 address range.  I think this is OK due to the nature of this document.  This is not using the addresses in a manner that would cause someone to build them into an implementation.

The second is discussed below.

> >
> > (1.h) Has the document split its references into normative and
> >      informative?

Yes

> > Are there normative references to documents that
> >      are not ready for advancement or are otherwise in an unclear
> >      state? If such normative references exist, what is the
> >      strategy for their completion?

Yes (this is the second issue).  The document makes a informational reference to draft-ietf-behave-address-format-01.txt.  This is both an old reference (there is a later draft available), and it's not clear when this document will advance.  My reading of the document is that it is referenced as an example along with two other RFC, and could be easily removed if it will take time referced for the referred draft to be published.


> > Are there normative references
> >      that are downward references, as described in [RFC3967]? If
> >      so, list these downward references to support the Area
> >      Director in the Last Call procedure for them [RFC3967].

No (except as noted above).

> >
> > (1.i) Has the Document Shepherd verified that the document IANA
> >      consideration section exists and is consistent with the body
> >      of the document? If the document specifies protocol
> >      extensions, are reservations requested in appropriate IANA
> >      registries? Are the IANA registries clearly identified? If
> >      the document creates a new registry, does it define the
> >      proposed initial contents of the registry and an allocation
> >      procedure for future registrations? Does it suggest a
> >      reasonable name for the new registry? See [RFC5226]. If the
> >      document describes an Expert Review process has Shepherd
> >      conferred with the Responsible Area Director so that the IESG
> >      can appoint the needed Expert during the IESG Evaluation?

Yes, there are not any IANA considerations that needed to be processed.

> >
> > (1.j) Has the Document Shepherd verified that sections of the
> >      document that are written in a formal language, such as XML
> >      code, BNF rules, MIB definitions, etc., validate correctly in
> >      an automated checker?

N/A

> >
> > (1.k) The IESG approval announcement includes a Document
> >      Announcement Write-Up. Please provide such a Document
> >      Announcement Write-Up? Recent examples can be found in the
> >      "Action" announcements for approved documents. The approval
> >      announcement contains the following sections:
> >
> >    Technical Summary
> >      Relevant content can frequently be found in the abstract
> >      and/or introduction of the document. If not, this may be
> >      an indication that there are deficiencies in the abstract
> >      or introduction.


This document defines a canonical text representation format of IPv6 addresses for use by operators, system engineers, and users.  The recommendation complies fully with [RFC4291], is implemented by various operating systems, and is human friendly.  The recommendation in this document SHOULD be followed by systems when generating an address to represent as text, but all implementations MUST accept any legitimate [RFC4291] format.  It is advised that humans also follow these recommendations when spelling an address.


> >
> >    Working Group Summary
> >      Was there anything in WG process that is worth noting? For
> >      example, was there controversy about particular points or
> >      were there decisions where the consensus was particularly
> >      rough?

The working group reviewed and discussed this document several times.  There is a strong consensus to move this forward.

> >
> >    Document Quality
> >      Are there existing implementations of the protocol? Have a
> >      significant number of vendors indicated their plan to
> >      implement the specification? Are there any reviewers that
> >      merit special mention as having done a thorough review,
> >      e.g., one that resulted in important changes or a
> >      conclusion that the document had no substantive issues? If
> >      there was a MIB Doctor, Media Type or other expert review,
> >      what was its course (briefly)? In the case of a Media Type
> >      review, on what date was the request posted?



This document has been reviewed by key members of the 6MAN working group and the chairs.