[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