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

Re: Fwd: IPv6 Unicast Address Assignment Considerations

Hi Stig,

Thanks for the review and reading the document. Please see inline:

At 09:34 16/03/2006 +0100, Stig Venaas wrote:

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. 

That is exactly what we wanted to mention. We will revise the text.



   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.
The above text is pointing towards an awareness (maybe the word 'constraint' was too strong). 
If one makes a subnet longer as 64 bits, that the all '0' should/may be avoided
as there is risk that one of the addresses could in that case overlap with an embedded-RP address. And yes, it will/should still work as unicast IPv6 address, but i think it is not very good practice to have addresses used that have may have double usage/meaning. 

I also see the point you are making and it makes a good addition to the draft.
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. 

I agree. Although the above text is more a design recommendation which is
not the main focus of this draft.

Thanks again,
G/


Stig