[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: IPv6 Unicast Address Assignment Considerations



Some comments on 3.3.2.  Addresses used by Embedded-RP (RFC3956)

   Embedded-RP [18] reflects the concept of integrating the Rendezvous
   Point (RP) IPv6 address into the IPv6 multicast group address.  Due
   to this embedding and the fact that the length of the IPv6 address
   AND the IPv6 multicast address are 128 bits, it is not possible to
   have the complete IPv6 address of the multicast RP embedded as such.

   This limitation resulted in a restriction of 15 possible multicast
   addresses per subnet prefix.  The space assigned for the embedded-RP

The number of multicast addresses per prefix is huge, what you want to say, is that there are 15 possible RP addresses per prefix that can be used with embedded-RP. For each of those you have 32 bits for multicast addresses.

   is based on the 4 low order bits, while the remainder of the
   Interface ID is set to all '0'.


               [IPv6-prefix (64 bits)][60 bits all '0'][RIID]

                   Where: [RIID] = 4 bit.


   This leads to the constraint that when creating subnet lengths longer
   than 64 bits, the bits between bit 65 and the subnet boundary should
   not be set to be all "0".

I don't understand this constraint. If all 64 low order bits (apart from the lowest 4) are 0 it's possible to use embedded-RP even for prefixes longer than /64. This is perhaps not so good, but it would work just fine. If you choose subnets with prefixes longer than 64 where all those bits are non-zero, then you cannot use embedded-RP with an RP address belonging to that subnet. So while I don't understand your constraint as written in the draft, it might be worth pointing out what I wrote above.

In general it might be good to say that when choosing addresses for routers, it might be worth considering whether the addresses work with embedded-RP. If you might want to use embedded-RP where that router is an RP, then it should have at least one "embeddable" address.

I suppose in many cases (at least AFAIK) people would use an additional loopback address on a router as RP address. This makes it easy to move the RP to another router. Especially for embedded-RP this is useful, since you don't want to change the group addresses applications use just because you want to move the RP. This loopback addresses then need to be "embeddable". In this case, it doesn't matter what addresses the router uses on the physical interfaces.

Stig