Multicast Addresses for Documentation
draft-ietf-mboned-mcaddrdoc-04

[Ballot comment]
I think it is a shame that the useful explanatory text is proposed for deletion from the IANA section. It would be nice to convert this into something that will record the motivation.

[Ballot comment]
I won't object given that RFC5737 and RFC3849 were both Informational, but shouldn't this kind of thing be BCP?

I agree that the IANA Considerations section needs serious rewriting. It needs to include the list of reserved addresses.

[Ballot comment]
I would propose one text improvement:
OLD:

  GLOP [RFC3180] is a method for deriving IPv4 multicast group
  addresses from 16 bit AS numbers.


NEW:
  GLOP [RFC3180] can be used by anyone who owns a registered AS number
  to derive 256 global multicast addresses, by mapping the AS number in the
  middle 16 bits of the IPv4 multicast address 233/8.

[Ballot discuss]
The authors have agreed to update the IANA section following the Routing Directorate review by Geoff Huston and email exchanges with IANA. This Discuss holds the document until that update has been done.

IANA has a question about the IANA Actions requested in this document.

Upon approval, IANA understands that there are two IANA actions which must be
completed.

First, the draft requests that IANA assign a scope relative IPv4 address for
documentation purposes.

IANA proposes 233.252.0.0/24 for this purpose.

IANA Question --> does this assignment meet the authors' requirements?

Second, the draft requests that IANA assign "variable scope" IPv6 multicast
addresses for documentation purposes.

IANA proposes FF0X::1:3/96 for this purpose.

IANA Question --> does this assignment meet the authors' requirements?

IANA understands that these are the only IANA Actions required upon approval of
this document.

[Ballot discuss]
I support the publication of this document, but I think there are a few things that should be DISCUSSed.

1. Should IANA reserve the multicast addresses that are constructed from the unicast prefixes allocated for documentation use?  For example, should FF3X:20:2001:DB8::/64 be reserved?

2. Was there any consideration given for how permanent IPv6 multicast addresses could be represented in documentation (i.e., flag T=0)?

[Ballot comment]
1. This draft states that for IPv4, 233.252.0.0/24 is reserved for documentation.  The IANA registry lists that range as being assigned to MCAST-TEST-NET.  Should this description be updated to reflect its new use as a documentation range?

2. It may be useful for the draft to mention why the IPv6 address request to IANA is for a /96.  Referencing RFC 3307 and its method of allocating the lowest 32-bits of multicast addresses would be sufficient.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Multicast Addresses for Documentation) to Informational RFC





The IESG has received a request from the MBONE Deployment WG (mboned) to

consider the following document:

- 'Multicast Addresses for Documentation'

  as an Informational RFC



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-05-02. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  This document discusses which multicast addresses should be used for

  documentation purposes and reserves multicast addresses for such use.

  Some multicast addresses are derived from AS numbers or unicast

  addresses.  This document also explains how these can be used for

  documentation purposes.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-mboned-mcaddrdoc/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-mboned-mcaddrdoc/ballot/





No IPR declarations have been submitted directly on this I-D.

Technical Summary

It is often useful in documentation, IETF documents, etc., to provide
examples containing IP multicast addresses. For documentation where
examples of general purpose multicast addresses are needed, one
should use multicast addresses that never will be assigned or in
actual use. There is a risk that addresses used in examples may
accidentally be used. It is then important that the same addresses
are not used by other multicast applications or services. It may
also be beneficial to filter out such addresses from multicast
signalling and multicast data sent to such addresses.

For unicast there are both IPv4 and IPv6 addresses reserved for this
purpose, see [RFC5737] and [RFC3849] respectively. This document
reserves multicast addresses for this purpose.

There are also some multicast addresses that are derived from AS
numbers or unicast addresses. For examples where such addresses are
desired, one should derive them from the AS numbers and unicast

addresses reserved for documentation purposes. This document also
discusses the use of these.


Working Group Summary

This draft has received solid support within the working group and no
major controversies were noted.

Document Quality

This document has received several comments from reviewers and the
authors addressed each of these comments.

Personnel

Lenny Giuliano is the Document Shepherd. Ron Bonica is the
Responsible Area Director.

IANA Note

IANA is requested to assign a scope relative IPv4 address for
documentation purposes. The string TBD1 in this document should be
replaced by the assigned offset. Also the string 255-TBD1 should be
replaced by the value of 255 minus the assigned offset. These last
two sentences should be deleted before publishing.

IANA is requested to assign "variable scope" IPv6 multicast addresses
for documentation purposes. This should be a /96 prefix of the form
FF0X:... The word TBD2 in this text should be replaced with the
assigned prefix, and this sentence should be deleted before
publishing.