IP Version 6 Addressing Architecture
draft-ietf-ipv6-addr-arch-v4-04

[Note]: 'Need to resolve comments from Thomas and Michelle before advancing (see comment log).

The implementation report for this docment can be found at: http://www.ietf.org/IESG/Implementations/rfc2373-74-implementation.txt' added by Margaret Wasserman

Comments from Thomas:

To: Margaret Wasserman
From: Thomas Narten
Cc: ipv6@ietf.org
Subject: last minute review of draft-ietf-ipv6-addr-arch-v4-03.txt

I know this is late, but better late than never...

Overall, the document is good, but I think that the document would
benefit from slight tweaking w.r.t. to multicast. I.e., I assume that
an "addressing architecture" should be complete and at a minimum offer
pointers to the relevant pieces. I don't think it quite does that in
the case of multicast.

> 2.7 Multicast Addresses

This section only mentions the T flag, and not the P flag. That doesnt
seem right, since the P flag is clearly in use now and not "0". Was
there a concern about a possible normative reference? I don't think
there needs to be. Suggestion:
Old:
>                                      +-+-+-+-+
>        flgs is a set of 4 flags:    |0|0|0|T|
>                                      +-+-+-+-+

New:

                                      +-+-+-+-+
        flgs is a set of 4 flags:    |0|0|P|T|
                                      +-+-+-+-+

and then add something like:

    The definition and use of the P bit can be found in [RFC 3307].

and make the reference informative.

Also, there are no IANA considerations for multicast addresses. But,
if you look at the IANA web page
(http://www.iana.org/assignments/ipv6-multicast-addresses), it says:

> IPv6 multicast addresses are defined in "IP Version 6 Addressing
> Architecture" [RFC2373].  This defines fixed scope and variable scope
> multicast addresses. 

But, this document doesn't use the terminology "fixed" or "variable"
scope. So things seem out of alignment. Does this document need to
straighten things out?

Or, maybe it's the case that RFC 3307 is (now) the definitive
document?  (IANA doesn't seem to have picked up anything from
there...). But 3307 document doesn't seem to use the "fixed/variable"
terminoligy either.

So, it's not immediately clear to me what is needed to get the IANA
page cleaned up, but since it _might_ involve tweaking text in this
document, I think it would be good to understand  what needs to be
done before approving this document.

It's also not immediately clear to me that this document and rfc 3307
are completely aligned, e.g., in terms of consistent terminology. And
this document doesn't seem to reference 3307, which seems incomplete.

Nit:

> 2.5.3 The Loopback Address
>
>    The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
>    It may be used by ...
...snip...
>    address of a virtual interface (typically called "the loopback
>    interface") to an imaginary link that goes nowhere.

better:

  ... to an imaginary link to which only a single node attaches,
  namely the node itself.

(issue: the link does go somewhere, since packet sent there loop
back...)

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[Note]: 'Need to review comments from Thomas and Michelle before advancing. 

The implementation report for this docment can be found at: http://www.ietf.org/IESG/Implementations/rfc2373-74-implementation.txt' added by Margaret Wasserman

[Note]: 'Need to review comments from Thomas and Michelle before advancing. 

The implementation report for this docment can be found at: http://www.ietf.org/IESG/Implementations/rfc2373-74-implementation.txt' added by Margaret Wasserman

[Note]: 'Need to review comments from Thomas and Michelle before advancing. 

The implementation report for this docment can be found at: http://www.ietf.org/IESG/Implementations/rfc2373-74-implementation.txt' added by Margaret Wasserman

IANA Follow-up Comments:
See back and forth communications below.  Sorry for the large posting.
I did not see any comments to Brian Haberman's suggestion.
Can someone plese take a look at this?  Will a revised IANA considerations section be needed?  I believe so.

From: Bob Hinden 
It would be:

http://www.iana.org/assignments/ipv6-address-space

The intent behind the IANA considerations text was to insure that the
address block containing these address continue to be labeled as "reserved
by IETF". This is, don't change anything.

Probably good to add to note that the "IPv4-compatible IPv6 address" was
deprecated by this document. Similar to note [2].

Thanks,
Bob


(IANA to Bob)
For the note, where should it go? Does it replace an existing note or go
under a specific prefix?

(Bob to IANA)
I think a new note (e.g., [5]} and it should be listed after 0000::/8.

(From: Brian Haberman )
There may not need to be a change made. Looking at
http://www.iana.org/assignments/ipv6-address-space
shows that the address block that subsumes the IPv4-compatible
addresses is marked as

0000::/8 Reserved by IETF

I will wait for others to comment, but that may be sufficient. The
other approach would be to specifically list the IPv4-compatible
addresses within this list. Such as:

0000::/96 Reserved by IETF [RFCxxxx]

with a note that it is deprecated.

Regards,
Brian

[Ballot comment]
I was serving on the IAB when this document:

http://www.iab.org/appeals/kre-ipng-address-arch-draft-standard-response.html

was issued.  I believe that this makes it appropriate for me to recuse here.

[Ballot comment]
Maybe I'm just confused, but there seem to be some changes in RFC 3513 and this draft that can't have been addressed in the interop report, which was written for RFC 2373.  For example, Section 2.7 of 2373 says:

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.  The values are:

  0  reserved
  1  node-local scope
  2  link-local scope
  3  (unassigned)
  4  (unassigned)

Section 2.7 of this draft says:

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.  The values are:

  0  reserved
  1  interface-local scope
  2  link-local scope
  3  reserved
  4  admin-local scope
  ...

and

"admin-local scope is the smallest scope that must be
administratively configured, i.e., not automatically
derived from physical connectivity or other, non-
multicast-related configuration."

I don't understand how value 4 can go from being unassigned to having a specific meaning and a configuration requirement without there being an implementation impact that would need to be described in an updated interop report.  Howevere, given that the IESG has approved 3513 in the past I'll just note this observation and abstain.

Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do

  they believe this ID is sufficiently baked to forward to the IESG

  for publication?



Yes



2) Has the document had adequate review from both key WG members and

  key non-WG members? Do you have any concerns about the depth or

  breadth of the reviews that have been performed?



It has been adequately reviewed.  We have no concerns over those reviews.



3) Do you have concerns that the document needs more review from a

  particular (broader) perspective (e.g., security, operational

  complexity, someone familiar with AAA, etc.)?



No.  This is a DS document.



4) Do you have any specific concerns/issues with this document that

  you believe the ADs and/or IESG should be aware of? For example,

  perhaps you are uncomfortable with certain parts of the document,

  or whether there really is a need for it, etc., but at the same

  time these issues have been discussed in the WG and the WG has

  indicated it wishes to advance the document anyway.



No concerns.



5) 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 chairs believe this document has wide support within the WG.



6) Has anyone threatened an appeal or otherwise indicated extreme

  discontent?  If so, please summarize what are they upset about.



No.



7) Have the chairs verified that the document adheres to _all_ of the

  ID nits?



Yes



- Technical Summary



  This specification defines the addressing architecture of the IP

  Version 6 protocol [IPV6].  The document includes the IPv6 addressing

  model, text representations of IPv6 addresses, definition of IPv6

  unicast addresses, anycast addresses, and multicast addresses, and an

  IPv6 node's required addresses.



  This document obsoletes RFC-3513 "IP Version 6 Addressing

  Architecture".



- Working Group Summary



The IPv6 working group has done extensive review of this document and

this document reflects the consensus of the group.



- Protocol Quality



This document has been reviewed by members of the ipv6@ietf.org

mailing list and by the working group chairs.

[Note]: 'This version only removes features (site-local, anycast restrictions, NSAP addresses) and changes wording to address clarity concerns, so no new implementation report should be required.' added by Margaret Wasserman

IANA Last Call Comments:
Upon approval of this document the IANA will need to make some updates however it is not clear in what registry these updates need to be made.

The IANA Considerations says the following:

  The "IPv4-compatible IPv6 address" is deprecated by this document.
  The IANA should continue to list the address block containing this
  address as "Reserved by IETF" and not reassign it for any other
  purpose.

In which registry does this deprecation need to be made?