Erik,
Apologies for the delay in responding. It took me a little
while to get back to the States from Stockholm. Responses are
in-line...
Erik Nordmark wrote:
>
> I have some comments and questions on the related drafts.
>
> > draft-ietf-ipngwg-uni-based-mcast-02.txt
>
> It would be quite useful to outline a bit more of
> the problem that needs solving in the introduction.
> It would also be useful to have a comparision with IPv4
> (either in the introduction or later in the document).
> Questions I'd like to see answered is whether there are
> approaches and protocols used for IPv4 multicast address allocation that is
> effectively replaced by the techniques in the draft i.e. whether the
> WGs believe that some mechanisms and protocols that do not need to
> be carried forward to IPv6.
Not a problem. There was a fair amount of discussion that never
made it into the document wrt what protocols were not being pulled
forward from v4. The overall goal is to avoid the need for any
inter-domain allocation protocol. Our approach basically will only
need, at most, MADCAP servers.
>
> The first part of section 3 should presumably refer to and use the picture
> from draft-ietf-ipnwg-addr-arch-v3 instead of RFC 2373.
OK.
>
> The description of the fields in section 3 should at a minimum describe
> the group ID field by having a reference to draft-ietf-malloc-ipv6-guide-03.txt
> I wonder if it also makes sense to carry some information from that document
> into this one; e.g. the fact that the high-order bit of the group ID must be
> zero for these types of addresses.
Some of the information in draft-ietf-malloc-ipv6-guide-03.txt was
pulled from this doc and moved. I was trying to separate the
protocol aspects from the operational aspects. However, the bit-setting
may be better off in this document. Any other text you think might
belong in other locations/documents?
>
> Will the unicast prefix based addresses ever need to use the link-local prefix?
> If not it might make sense to explicitly ban that where it talks about scope
> in section 3.
Dave answered this already, but let me add something. The following
text is in section 3:
The scope of the unicast-prefix based multicast address MUST NOT
exceed the scope of the unicast prefix embedded in the multicast
address.
This text was actually put in specifically to address the use of
the link-local prefix. As Dave said, using it doesn't buy you
anything, but allowing it makes the work of allocation servers
easier since they don't have to prohibit particular scopes on the
prefixes. In addition, I could envision the use of this on large
switched LANs with a MADCAP server.
>
> The last paragraph in section 3 is about lifetimes.
> I don't understand what the intended effect is of the statement
> since I don't know what the lifetime is of a multicast address.
> Is the intent that e.g. if the prefixes are advertised with a 1 day valid
> lifetime, that an implementation MUST NOT use multicast addresses derived
> from those prefixes in SDP advertisements that end beyond 1 day ahead?
> If the intent is to really be that strict the document definitely needs
> to be a lot more specific on this point. But I don't see a need to be
> that strict - all these multicast addresses are temporary - is there
> any real danger is for some applications "temporary" spans unicast
> prefix renumbering events?
I will defer comment for another response since it seems that there
has been alot of discussion on this point while I was gone.
>
> > draft-ietf-malloc-ipv6-guide-03.txt
>
> The name of the reference [NEW ARCH] confused me - I was sure it
> was addr-arch-v3. How about "UNICAST PREFIX" or [3] instead?
Ah, a legacy reference. I can change this without any problems. It
was a carryover from the original -00 document where Dave and I had
proposed breaking the multicast address architecture out of RFC 2373.
>
> Section 3 - bullet on SSM. This says that there is a 96 bit multicast
> prefix but the other drafts says it must be zero. Why not explicitly say zero
> here as well? Otherwise folks can be lead to believe they can create non-zero
> middle bits for SSM addresses.
> (If this change is done the second bullet would need to be rewritten since
> it refers to SSM.)
I was referring to the fact that the first 96 bits of the address are
generated using the specifications in the other draft. The 32-bit
group ID is then generated using the techniques in this draft. Given
the restrictions in RFC 2373 and its follow-up, all multicast addresses
are composed of a 96-bit prefix and a 32-bit group-ID.
>
> Section 5 on randomness says:
> The group ID portion of the address is set using either a pseudo-
> random 32-bit number or a 32-bit number created using the guidelines
> in [RFC 1750]. Possible approaches to creating a pseudo-random
> number include using an MD5 message-digest [RFC 1321] or portions of
> an NTP [RFC 1305] timestamp.
> I think the second sentence should be dropped since it could easily be
> read as taking the MD5 digest of a constrant string, or
> the current year+month (high-order bits of timestamp), are good enough as
> random numbers.
I can drop that sentence. It was added because I had several comments
asking for suggestions on creating these random numbers. But, the
reference to RFC 1750 should be enough.
>
> Thus the paragraph on high-order but set to '1' imply that the
> high-order bit should always be the same as the T flag in the address?
> If so it would make sense to explicitly state that.
> If not I'd like to understand the relationship between the two better.
Ah, good point. The high-order bit does reflect the setting of the
T bit. I can add text to elaborate on that.
>
> IANA considerations section seem to be incorrect on the last range.
> The intent as I understand it is not allow private use but that
> the range is reserved for use that conforms to this specification (i.e.
> random group IDs).
Good catch. The last range is for dynamic allocation use.
>
> Also, the IANA considerations seem to be missing the request that IANA
> establish a new registry for permanent group IDs (range 0x40000000-0x7fffffff)
> which is different than the existing registry for IPv6 multicast addresses.
I will try and bolster that section a little to spell it out in
more concrete terms.
Thanks,
Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
