Subject: mboned: IPv6 link-scoped multicast

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Aug 2004 00:24:18 +0300 (EEST)

Hi,

(This will be discussed in IPv6 WG session, but to bring it up in 
MBONED as well as appropriate..)

draft-ietf-ipv6-link-scoped-mcast-04.txt specifies link-local -scoped
IPv6 multicast addressing format, which uses a format which would
conflict with SSM address range FF3x::/32 (but not FF3x::/96).  
Basically it just embeds the EUI64 identifier ("MAC-address") on the
multicast address plus leaves 32 bits for group-id.

I think there are two big problems I see with this:

  1) this conflicts with the (reserved) SSM address range, causing 
     problems with all the implementations which do SSM.

  2) the problem this draft is solving is not sufficiently well
     understood or articulated.

The first is IMHO a sufficient reason to design this in some other 
way.  But IMHO the second is a larger problem, which affects the way 
such a re-design should be made.  We should not go forward until we 
can write down a precise problem statement..

It has been stated that this form of multicast addressing is needed in 
a zero-conf link-local environment.  But this is really vague and 
doesn't answer the real questions: 

  a) how do you perform source discovery / rendezvous in such a 
     zeroconf environment?

  b) do you need to support scenario where sources would be frequently 
     moving from one zero-conf link-local environment to another?

  c) why can't you use transient link-local multicast addresses?  
     There's potentially 112 bits for link-specific group-id's -- that 
     should be enough to randomize an address and not have conflict.

  d) even if you used RFC3306-based addressing with prefix fe80::/64, 
     there would be 32 bits of group-id to pick from.  Isn't this 
     enough?  (If I'd have to choose a redesign, I'd probably pick 
     this.)

  e) if a random group-id is not acceptable, why the group-id must be 
     static, or somehow determinable?

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

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/