Subject: uni-based-mcast and malloc-ipv6-guide

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Sep 2001 10:39:45 +0200 (CEST)

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.

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.

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.

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.

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?

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

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

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.

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.

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

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.

   Erik

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Brian Haberman" <[email-masked]>
Date: Tue, 18 Sep 2001 10:01:17 -0400

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

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

> from draft-ietf-ipnwg-addr-arch-v3 instead of RFC 2373.

OK. 

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

> If not it might make sense to explicitly ban that where it talks about scope

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.

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

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

> (If this change is done the second bullet would need to be rewritten since

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.

> the current year+month (high-order bits of timestamp), are good enough as

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.

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

> the range is reserved for use that conforms to this specification (i.e.

Good catch.  The last range is for dynamic allocation use.

> 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