ReMIME-Version: 1.0

[bkhabs@nc.rr.com]

Comments in-line...

Hugh Holbrook wrote:
 > 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 the 4-bit scope id.  Since it is part of the prefix, it is
hard to represent its concrete meaning without text.  The base
IPv6 address architecture uses the same notation.

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

Correct.  We reserved the /32 but all allocations will come out of
the /96.  That will allow us to grow the 32-bit group id if we
come up with a new mapping strategy for IP->MAC address mapping.

 >
 > 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?
 >

This doc is as good a place as any.

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

Agreed.  Without having PLEN set it is difficult to parse out the
correct prefix.

Brian