Subject: Proposed changes to IPv6 Address Architecture draft

From: Bob Hinden <[email-masked]>
Date: Wed, 18 May 2005 14:46:27 -0700

Hi,

The proposed changes in Section 2.7 on Multicast Addresses and Section 4.0 
IANA Considerations can be found below.  The changes are based on the 
issues raised by Thomas Narten and the IANA.  I believe this will resolve 
the issues.

The complete document can be found at:

   http://people.nokia.net/~hinden/draft-ietf-ipv6-addr-arch-v4-04.txt

along with a diff from the previous version.

   http://people.nokia.net/~hinden/draft-ietf-ipv6-addr-arch-v4-04.html

Please review and let me know if you find any problems.  I plan to submit 
this in a few days.

Thanks,
Bob

-----------------------------------

2.7 Multicast Addresses

    An IPv6 multicast address is an identifier for a group of interfaces
    (typically on different nodes).  An interface may belong to any
    number of multicast groups.  Multicast addresses have the following
    format:

    |   8    |  4 |  4 |                  112 bits                   |
    +------ -+----+----+---------------------------------------------+
    |11111111|flgs|scop|                  group ID                   |
    +--------+----+----+---------------------------------------------+

       binary 11111111 at the start of the address identifies the address
       as being a multicast address.

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

          The high-order flag is reserved, and must be initialized to 0.

          T = 0 indicates a permanently-assigned ("well-known") multicast
          address, assigned by the Internet Assigned Number Authority
          (IANA).

          T = 1 indicates a non-permanently-assigned ("transient" or
          "dynamically" assigned) multicast address.

          The P flag's definition and usage can be found in [RFC3306].

          The R flag's definition and usage can be found in [RFC3956].

       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
          5  site-local scope
          6  (unassigned)
          7  (unassigned)
          8  organization-local scope
          9  (unassigned)
          A  (unassigned)
          B  (unassigned)
          C  (unassigned)
          D  (unassigned)
          E  global scope
          F  reserved

          interface-local scope spans only a single interface on a
          node, and is useful only for loopback transmission of
          multicast.

          link-local multicast scope spans the same
          topological region as the corresponding unicast scope.

          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.

          site-local scope is intended to span a single site.

          organization-local scope is intended to span multiple
          sites belonging to a single organization.

          scopes labeled "(unassigned)" are available for
          administrators to define additional multicast regions.

       group ID identifies the multicast group, either permanent or
       transient, within the given scope.  Additional definitions of the
       multicast group ID field structure is defined in [RFC3306].

-------------------------------------

4. IANA Considerations

    The "IPv4-compatible IPv6 address" is deprecated by this document.
    The IANA should continue to list the address block containing these
    addresses at http://www.iana.org/assignments/ipv6-address-space as
    "Reserved by IETF" and not reassign it for any other purpose.  For
    example:

       0000::/8        Reserved by IETF        [RFC3513]      [1]

    The IANA is requested to add the following note and link it to this
    address block.

       [5]  0000::/96 was previously defined as the "IPv4-compatible IPv6
            address" prefix.  This definition has been deprecated by
            [RFC-ietf-ipv6-addr-arch-v4-04.txt].

    The IANA is requested to update the references for the IPv6 Address
    Architecture in the IANA registries to this RFC when it is published.

------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 May 2005 10:42:19 +0300 (EEST)

On Wed, 18 May 2005, Bob Hinden wrote:
> IANA Considerations can be found below.  The changes are based on the issues 
> raised by Thomas Narten and the IANA.  I believe this will resolve the 
> issues.

You might want to add a note in the changelog about the multicast 
address update, but even without doing so the changes looked 
reasonable.

-- 
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: Bob Hinden <[email-masked]>
Date: Thu, 19 May 2005 09:17:08 -0700

Pekka,

At 12:42 AM 05/19/2005, Pekka Savola wrote:
>>The proposed changes in Section 2.7 on Multicast Addresses and Section 
>>4.0 IANA Considerations can be found below.  The changes are based on the 
>You might want to add a note in the changelog about the multicast address 
>update, but even without doing so the changes looked reasonable.

Good suggestion.  I will add something like:

  o Added the "R" and "P" flags to Section 2.7 on Multicast addresses,
    and pointers to the documents that define them.

Thanks,
Bob

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 May 2005 15:35:53 -0400

Bob,

The changes look good to me.

One thing I noticed while reading this text (and this issue actually

>           The high-order flag is reserved, and must be initialized to 0.

Because the high-order flag is reserved, its contents should be
ignored by all implementations. So "must be initialized to 0" is
perhaps better just dropped, to prevent an implementer from thinking
they need to (somehow) verify/check this. Maybe change to:

           The high-order flag is reserved, and its value should be
           ignored on receipt (other than being considered part of the
           address when performing address comparisons).

(Maybe the last part is too long/complicated/obvious, in which case
just dropping it might be better.)

I'm also fine with not adding any additional text to the IANA
considerations regarding the unicast/multicast instructions.

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Fri, 20 May 2005 13:29:51 -0700

Thomas,

>The changes look good to me.

Thanks!

>just dropping it might be better.)

I agree it gets complicated trying to spell this out because 
implementations don't set the flags in a multicast address like they might 
dynamically set a flag in a protocol header.  However, I think we do want 
to do something to insure that it is zero so as to avoid ending up with two 
different multicast address for the same thing.  How about if it just says:

    The high-order flag is reserved and must be zero.

This avoids the idea that an implementation might have to initialize it 
dynamically.

>considerations regarding the unicast/multicast instructions.

Thanks!

Bob

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 May 2005 16:43:01 -0400

> How about if it just says:

>     The high-order flag is reserved and must be zero.

Actually, the issue that I'm trying to get around is to avoid having
the spec say the flag "must be xxx" where xxx is any value. It should
just (mostly) be ignored. If you say it must be zero, than some
implementation might think if it is non-zero it should be changed to
zero, or something equally silly.

Thus, I think:

      The high-order flag is reserved.

might be better than saying the full sentence.

I.e., a future spec will set it to 1 and presumably all the existing
implementations should continue doing what they did before hand --
i.e., just ignore the bit, not treating it having any special meaning
one way or the other.

With reserved fields in protocol headers, we typically say "ignored on
receipt". But that is not true for an address, because the value isn't
completely ignored, as its considered part of the address when doing
lookups or when comparing against other addresses.

But this is all a pretty minor point overall.

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Fri, 20 May 2005 16:53:00 -0400

> But this is all a pretty minor point overall.

I emphatically agree that it is a minor point.  The current text has 
been
in the spec from day 1 and has not caused problems.  Given that,
I would prefer to leave the text as is.

Regards,
Brian