Re

[holbrook@cisco.com]

[ correcting a typo in the mailing address, cicso->cisco.]

My responses to Pavlin's IPv6-related comments on the ssm-arch draft
are inline.  cc'ing Dave and Brian for confirmation.

Pavlin wrote:
>  * In Section 1, the draft says that FF3x::/32 is reserved for SSM,
>    and cites reference [IPV6-UBM] for that (RFC 3306). However, one
>    of the examples in Section 7 in RFC 3306 is:
>        "SSM - All IPv6 SSM multicast addresses will have the format
>         FF3x::/96"
>    which I find confusing. My confusion is primarily based on the
>    potential ambiguity of the "x" in the above notation: is this
>    always the 4-bit address scope, or sometimes it could be
>    everything up to the 96-th bit?  My initial understanding was that
>    "x" is always the 4-bit address scope, but then Section 3 of RFC
>    3307 mentions FF3x::/96 as the SSM address range.
>    Maybe the draft should clarify the IPv6 SSM address range with
>    some specific examples that also clarify the meaning of "x".

"x" is only supposed to be one of the valid 4-bit scope values, as
stated in RFC3306.  I think the problem is that RFC3306 is confusing
because it says in Section 6:

>  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).

But by setting plen and network prefix to zero, you create a range of
FF3x::/96, not FF3x::/32.

My understanding of RFC3306, from discussions with the authors, was
that the intention of RFC3306 is to reserve all of FF3x::/32 (whenever
P=1 and T=1 and plen=0) for SSM addresses.  Although this is not
really what the draft says.  However, RFC3307 specifies that all
current allocations of v6 SSM addresses must also set network prefix
(bits 32 to 96) to zero as well.  I think the idea was that in the
future there may be some reason to allocate from the broader FF3x::/32
space.  Therefore, applications must treat FF3x::/32 as an SSM
address, although currently network prefix is always zero.

Dave or Brian, could you comment on whether I've got this straight.

Assuming I've got this right, I'd propose to add some text basically
stating what I said in the paragraph above to this document.  This is
not the first time this has come up, and my feeling is that this needs
to be clarified.  Anyone else have comments on this point?

>  * Use consistent notation for the IPv6 hex addresses. E.g., the
>    draft has addresses like FF3x::7fff:ffff which mixes capital with
>    small letters.

Done.

>  * In the examples in Section 2, is address FF23::1234 a valid
>    SSM destination address? I.e., if the P bit is set, then the T
>    bit MUST also be set!? (according to Section 4 in RFC 3306).

Oops.  This should be FF33::1234.  See next point.

>  * In Section 4.3, the address range in
>    "... IPv6 SSM address range FF2x::"
>    is confusing: is this FF2x::/32 or FF2x::/96 or something else?
>    Also, earlier you say that the IPv6 SSM address range is
>    FF3x::/32, so FF2x:: does not fail within the "SSM address
>    range", unless "x" in FF2x:: does not mean "scope identifier"
>    only.
>    Similar question about the mention of FF2x:: in Section 9.
>    Further, the above comment about the P and T bits from RFC 3306
>    applies for FF2x:: as well.

On both of these above points, you're right.  FF2* should be replaced
universally with FF3*, both in the examples and in the text.  This
text was based on an early draft of RFC3306 where the fact that the T
bit had to be set was not clear, and it slipped by in the last round
of revisions.

>  * When a host allocates locally an IPv6 SSM destination address,
>    should the chosen destination address try to include the network
>    prefix as well inside (similar to the unicast-prefix-based IPv6
>    mcast addresses described in RFC 3306)? E.g., in Section 4.3 the
>    recommendation is that "... the randomization should apply to the
>    lower 32 bits of the address", but it doesn't say about the upper
>    bits (between the 32nd and 96th bits).

Bits 32 to 96 should be zero (because the PLEN needs to be zero for an
SSM address, as stated in Section 6 of RFC3306, modulo the comments
above.  I didn't want to restate that here.  I think if we clarify the
issue you raised above, we won't need to say anything about this.

Thanks for the comments.  I'll definitely submit a revised draft as a
result.

-Hugh

> Thanks,
> Pavlin
>