Subject: Re: IPv6 w.g. Last Call on "Link Scoped IPv6 Multicast Addresses"

From: Brian Haberman <[email-masked]>
Date: Wed, 22 Oct 2003 07:13:18 -0400

Please ignore this message.  The correct Last Call announcement is
in a separate message.

Brian

Brian Haberman wrote:

> This is a IPv6 working group last call for comments on advancing the
> following document as an Proposed Standard:
> 
>     Title        : Deprecating Site Local Addresses
>     Author(s)    : C. Huitema, B. Carpenter
>     Filename    : draft-ietf-ipv6-deprecate-site-local-01.txt
>     Pages        : 10
>     Date        : 2003-10-13
> 
> Please send substantive comments to the ipv6 mailing list, and minor
> editorial comments to the authors.  This last call period will end on 4
> November 2003.
> 
> Brian Haberman / Bob Hinden
> IPv6 W.G. Chairs
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 22 Oct 2003 07:14:08 -0400

Brian

Brian Haberman wrote:

>     Title        : IPv6 Scoped Address Architecture
>     Author(s)    : S. Deering et al.
>     Filename    : draft-ietf-ipv6-scoping-arch-00.txt
>     Pages        : 22
>     Date        : 2003-6-24
>

---

From: "jspark" <[email-masked]>
Date: Wed, 22 Oct 2003 20:23:58 +0900

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

---

From: "jspark" <[email-masked]>
Date: Fri, 24 Oct 2003 19:55:52 +0900

-----Original Message-----
From: jspark [mailto:[email-masked]] 
Sent: Friday, October 24, 2003 7:51 PM
To: 'Pekka Savola'
Cc: [email-masked]'; [email-masked]'

Hi Pekka. 

On Fri, 24 Oct 2003, Pekka Savola wrote:
> First, there is typically just one link-local address.  
> Either it uses EUI-64 based IID or not.  

Right.

So many types of addresses exist
such as stateless, stateful, manually etc.

> If it doesn't, you can't generate addresses like this.

In our spec,
we mentioned that EUI-64 IID based LL address is only used.

But, I think that stateful or manually configured addresses are also useful
because these kinds of addresses are supported by DAD. 

> Second, the EUI-64 does not guarantee the uniqueness of the method.  
> Otherwise we would not be needing DAD with addresses that are 
> generated with EUI-64.

Right.

The EUI-64 itself is not unique.
So, DAD procedure is needed for link-local address.
And also stateful or manually configured addresses are used after DAD
processing.

> But it is mandated by the specs.  So
> these addresses are
> *not* truly, completely, totally, unique.

In our spec.
The uniqueness of LL unicast address is verified by DAD procedure.
And then, EUI-64 IID (or other) is extracted from LL Unicast address.

Therefore,
our method supposes that LL unicast address should be verified by DAD
procedure.

Jungsoo.