Re: [MBONED] draft-ietf-mboned-64-multicast-address-format-03.txt

[Behcet Sarikaya <[e-mail]>]

> I wrote something slightly different:
>
> "Of course we could argue whether we need to support embedded-RP.
> It is very useful, especially inter-domain, but if that is not a
> requirement, we may not need to support it."
>

Embedded-RP prefix is FF7e, so FFxx supports it.

> I left it open to discussion. I'm trying to get all the options on the
> table here.
>
> Alternative 2 above is sufficient if we don't care about embedded-RP,
> and is in draft-kumar-mboned-64mcast-wkp-address-00.txt.
>
> But I do see value in both unicast-prefix based addressing (a good
> way to ensure your addresses are unique), and embedded-RP (which is
> necessary inter-domain, but may at times be used intra-domain). And I
> do know deployments using inter-domain embedded-RP.
>
> If we want to support unicast-prefix based addressing or
> embedded-RP, it appears we need to update RFC 3306.
>
> Note that we would not change 3306 in any way. We only need
> this draft to say that it Updates 3306.

Why?
As far as I understand, the issue here is to use which bit in the
reserved field, Tim suggested the rightmost and your proposal uses the
leftmost.
RFC3946 solves this problem by redefining rsvd field as 4 bits instead
of 8 bits in RFC 3306, i.e. it updates 3306 which is already stated in
there.

Maybe in this draft we can say that we use RFC 3946 definition of the
reserved field.

BTW, in Teemu Kiviniemi's thesis on Implementation of an IPv4 to IPv6 Multicast
Translator
ASM prefix: ff7e:140:2001:db8:ab:cd::/96
is used, which matches Tim's suggestion :-).

This is the SSM prefix: ff3e::/96 that is used.


Behcet