RE: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses"
Hi Erik
Thanks for your comments.
> I'm trying to understand why the RFC 3306 are so broken for scope <=2
> that they can not be used.
> While using the new address format for scope <= 2 would presumably be
>preferred I don't see why prohibiting
> (as the "MUST" above does) the use of RFC 3306 for those scopes.
> If prohibiting them is the right thing I think the document should state
why.
Technically, RFC3306 can be used for scope <=2.
RFC3306 author's consent to the following sentence :
our draft updates the "Unicast-Prefix- based IPv6 Multicast
Addresses" for the link-local scope.
In my memory,
IPv6 guys also agreed on our view during the 54th IETF meeting.
I think ..
RFC3306 needs allocation server of 32bit goup ID
in order to support the uniqueness in the site.
This site is identified by network prefix.
But,
Group ID Autoconfiguration in link-scope will be valuable
without help of allocation server.
Each node in our draft allocates group ID independently.
> The example says:
> This is an example of an interface ID-based multicast address with
> link-local scope. For example in an Ethernet environment, if the
> link-local unicast address is FE80::12:34:56:78:90:AB, the multicast
> prefix of the host is FF32:0:1234:56FF:FE78:90AB::/96. For SSM,
> multicast address will be FF32::/96.
> Typo (I think): FE80::12:34:56:78:90:AB should be FE80::1234:5678:90AB
> and a better example would have a 64 bit iid (the above one has 16 leading
zeros). Such as
> FE80::a12:34ff:fe56:7890
> resulting in
> FF32:0:a12:34ff:fe56:7890::/96
>
> Erik
Good comment.
We will publish new draft with a reflex of reality soon.
Jungsoo
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.