Subject: last minute review of draft-ietf-ipv6-addr-arch-v4-03.txt

From: Thomas Narten <[email-masked]>
Date: Thu, 12 May 2005 12:50:46 -0400

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 a node to send an IPv6 packet to itself.  It must
>    not be assigned to any physical interface.   It is treated as having
>    link-local scope, and may be thought of as the link-local unicast
>    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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Thu, 12 May 2005 13:22:37 -0400

> there...).

Update (thank you google!):

http://www.iana.org/assignments/perm-mcast-groupids

Which is findable under "IPv6 Multicast Permanent Group Identifiers"
on the main page.

But, this (IMO) should be a part of the IPv6 multicast assignments
page or at least closely visible there, so one can find it more
easily...

I.e., from http://www.iana.org/numbers.html:

> Internet Protocol version 6 (IPv6) Multicast Address Allocations
> Address Allocations 	RFC3307  	Expert Review (Expert-David Meyer)

The link to the group  identifiers should be here (at a minimum).

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 May 2005 22:20:04 +0300 (EEST)

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

Actually, the bits are currently 0RPT :) -- RFC 3956 (which Updates 
3306).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian Haberman <[email-masked]>
Date: Mon, 16 May 2005 14:27:56 -0400

Hi Thomas,

> and make the reference informative.

Bob and I discussed this and he will be putting text together that
clarifies the bits with informative references to RFC 3306 (not 3307)
and RFC 3956.

> this document doesn't seem to reference 3307, which seems incomplete.

This is a bigger problem than should be handled in an addressing
architecture document.

My suggestion is that we work this issue through the IAB's Ad-hoc IPv6
group since they are already focusing on registry clean-up.  This can be
another sub-bullet on that work list.  I think trying to document to 
IANA
that they need to overall a registry in this spec will be too confusing.

Regards,
Brian