Re: [MBONED] Last Call: <draft-ietf-mboned-64-multicast-address-format-01.txt>

[Stig Venaas <[e-mail]>]

On 4/20/2012 10:47 AM, Brian Haberman wrote:
> On 4/20/12 12:58 PM, Stig Venaas wrote:
>
>>>
>>> * Why is there a new set of flags (64IX) being created within the
>>> address? There is only one bit being used in that field and there is
>>> still a bit available in the standard flags field. Why is that not being
>>> used to indicate a "translatable" multicast address?
>>
>> Hi, just a comment on this one. Unfortunately these are not treated as
>> individual bits. For instance implementations have hardcoded that the
>> flag nibble 3 is SSM (and also what is specified in various RFC), so if
>
> I consider it unfortunate that people interpreted RFC 3306 as specifying
> a hard-coded SSM prefix when there are undefined flag bits present in
> the prefix.

Me too, but I don't blame them, see below.

> The implementation I worked on didn't blindly check for a fixed prefix.
> That was intentional given the existence of two bits in the flgs field
> that were undefined.
>
>> this bit is set, it would not be treated as SSM without a number of
>> documents and implementations being updated. Same issue with
>> Embedded-RP. I know this is unfortunate. Do you see it differently? I
>> think we need a new field that is a true flag field.
>
> Sorry, I don't see it any differently. I would file bug reports with
> implementations that make that assumption, but I would not use that as
> justification to change an address architecture.

OK, I've seen implementations using a fixed value, which I think is
unfortunate. I wouldn't mind if we investigate this further.

I can check some Cisco implementations to see what they are doing. Maybe
people from other vendors could check too.

Regarding RFCs.

RFC 3306:

6. Source-Specific Multicast Addresses

    The unicast prefix-based IPv6 multicast address format supports
    Source-specific multicast addresses, as defined by [SSM ARCH].  To
    accomplish this, a node MUST:

          o  Set P = 1.
          o  Set plen = 0.
          o  Set network prefix = 0.

    These settings create an SSM range of FF3x::/32 (where 'x' is any
    valid scope value).  The source address field in the IPv6 header
    identifies the owner of the multicast address.

This is sort of OK, but it doesn't mention that there may be other SSM
ranges.

RFC 4607:

    For IPv6, the address prefix FF3x::/32 is reserved for source-
    specific multicast use, where 'x' is any valid scope identifier, by
    [IPv6-UBM].  Using the terminology of [IPv6-UBM], all SSM addresses
    must have P=1, T=1, and plen=0.  [IPv6-MALLOC] mandates that the
    network prefix field of an SSM address also be set to zero, hence all
    SSM addresses fall in the FF3x::/96 range.  Future documents may
    allow a non-zero network prefix field if, for instance, a new IP-
    address-to-MAC-address mapping is defined.  Thus, address allocation
    should occur within the FF3x::/96 range, but a system should treat
    all of FF3x::/32 as SSM addresses, to allow for compatibility with
    possible future uses of the network prefix field.

It should also talk about FFBx then.

RFC 3956:

    The behavior is unspecified if P or T is not set to 1, as then the
    prefix would not be FF70::/12.  Likewise, the encoding and the
    protocol mode used when the two high-order bits in "flgs" are set to
    11 ("FFF0::/12") is intentionally unspecified until such time that
    the highest-order bit is defined.  Without further IETF
    specification, implementations SHOULD NOT treat the FFF0::/12 range
    as Embedded-RP.

But based on this, implementations following this SHOULD, would also
need to be updated.

With what was proposed in the draft, there is no need to update every
router to use Embedded-RP, only the ones that need to be aware of
translation taking place. If we define a new flag, Embedded-RP
implementations will need to change.

Regarding the flags in this document. My initial thought was having
well-known prefixes for embedding v4 in v6, both ASM and SSM. You
may think of this draft as defining well-known prefixes, rather
than a new flag.

Stig

>
> Regards,
> Brian