Subject: RE: IETF 59 IPv6 WG Document Status

From: "Dave Thaler" <[email-masked]>
Date: Mon, 1 Mar 2004 21:07:26 -0800

Pekka Savola writes:
> On Tue, 2 Mar 2004, Jung-Soo Park wrote:
> > I revised my draft (-04) according to comments of ML.
> > My revised draft is available as follows:
> > http://www.ipv6.or.kr/eng/draft-ietf-ipv6-link-scoped-mcast-04.txt
> 
> I don't think this addresses my concerns.  This does not work with
> source-specific multicast in general, or even source-specific
> multicast w/ link-local scope in specific.

With source-specific multicast, the problem this draft addresses
does not exist.  That is, there is no need for ensuring uniqueness
on the link.  RFC 3306 already specifies how SSM addresses are done
(including for link-local scope multicast addresses).

-Dave 

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Mar 2004 07:35:26 +0200 (EET)

> (including for link-local scope multicast addresses).

No, the problem is not that.  It is that this document overloads the 
link-local multicast semantics so that a SSM ll multicast address and 
a "link-scoped address" are semantically undistinguishable.

SSM range is FF3X::/32.  This draft invades in that territory.

As stated before, there are a number of ways to achieve the same 
behaviour without these problems, e.g., using 

- FF32:40:fe80::<32 bits where you can plug the least significant 32 
bits off your EUI64 -- pretty good method>
- FF32:A:fe80::<EUI64>, 
- FF02::<EUI64>:<group-ID> ("transient address")

-- 
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: Myung-Ki Shin <[email-masked]>
Date: Tue, 02 Mar 2004 15:54:16 +0900

Please see comments below :

> SSM range is FF3X::/32.  This draft invades in that territory.

   No, as mentioned before,
   SSM format is FF3X::/96 in section 7 of RFC 3306.
   Thus, it is distinguishable.

   So, which one is correct ? (FF3X::/32 or FF3X::/96)
   We shoud ask it to the authors of RFC 3306.

   Anyway, I think this issue can be easily resolved. (depending on
decision)

   Thanks,
    M-K.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Mar 2004 08:57:51 +0200 (EET)

>    Thus, it is distinguishable.

Sorry, SSM WG does not agree with this interpretation.

>    We shoud ask it to the authors of RFC 3306.

The current belief among SSM people is that to identify an SSM 
address, the implementations check for FF3X::/32, even though 
currently only FF3X::/96 is being used.