Re: [MBONED] Protocol Action: 'Unicast-Prefix-based IPv4 Multicast Addresses' to Proposed Standard

[Marshall Eubanks <[e-mail]>]

On Aug 10, 2010, at 5:33 PM, Leonard Giuliano wrote:

> 
> IANA is in the process of assigning.  Thoughts/suggestions as to which /8 
> anyone thinks it should be are welcome.
> 

My suggestion would be to assign the /8's in order - thus 234/8

Regards
Marshall

> 
> On Mon, 9 Aug 2010, Tim Chown wrote:
> 
> -) Hi,
> -) 
> -) What's the news/status on IANA assigning a /8 for this scheme?
> -) 
> -) Tim
> -) 
> -) On 6 Aug 2010, at 23:09, The IESG wrote:
> -) 
> -) > The IESG has approved the following document:
> -) > 
> -) > - 'Unicast-Prefix-based IPv4 Multicast Addresses '
> -) >   <draft-ietf-mboned-ipv4-uni-based-mcast-06.txt> as a Proposed Standard
> -) > 
> -) > 
> -) > This document is the product of the MBONE Deployment Working Group. 
> -) > 
> -) > The IESG contact persons are Ron Bonica and Dan Romascanu.
> -) > 
> -) > A URL of this Internet-Draft is:
> -) > http://www.ietf.org/internet-drafts/draft-ietf-mboned-ipv4-uni-based-mcast-06.txt
> -) > 
> -) > Technical Summary
> -) > 
> -) >    This specification defines an extension to the multicast addressing
> -) >    architecture of the IP Version 4 protocol.  The extension presented
> -) >    in this document allows for unicast-prefix-based assignment of
> -) >    multicast addresses.  By delegating multicast addresses at the same
> -) >    time as unicast prefixes, network operators will be able to identify
> -) >    their multicast addresses without needing to run an inter-domain
> -) >    allocation protocol.
> -) > 
> -) >    This draft specifies a mechanism similar to RFC3306, whereby a
> -) >    range of global IPv4 multicast address space is provided to each
> -) >    organization that has unicast address space.  A resulting advantage
> -) >    over GLOP is that the mechanisms in IPv4 and IPv6 become more
> -) >    similar.
> -) > 
> -) > 
> -) > Working Group Summary
> -) > 
> -) >    This draft has received strong support within the working group and
> -) >    no major controversies were noted.
> -) > 
> -) > Document Quality
> -) > 
> -) >    There were several comments made during working group last call.
> -) >    The author has addressed and/or incorporated all questions and
> -) >    concerns in the document.  This document has also been thoroughly
> -) >    discussed and reviewed for several years on the mailing list and
> -) >    during the working group meetings.
> -) > 
> -) > Personnel
> -) > 
> -) >    Lenny Giuliano is the Document Shepherd. Ron Bonica is the
> -) >    Responsible Area Director.
> -) > 
> -) > RFC Editor Note
> -) > 
> -) > OLD> RFC 3180 [RFC3180] defined an experimental allocation mechanism
> -) > OLD> (called "GLOP") in 233/8 whereby an Autonomous System (AS) number is
> -) > OLD> embedded in the middle 16 bits of an IPv4 multicast address,
> -) > 
> -) > NEW> RFC 3180 [RFC3180] defines an allocation mechanism
> -) > NEW> (called "GLOP") in 233/8 whereby an Autonomous System (AS) number is
> -) > NEW> embedded in the middle 16 bits of an IPv4 multicast address,
> -) > 
> -) > OLD> This draft specifies a mechanism similar to [RFC3306], whereby a
> -) > OLD> range of global IPv4 multicast address space is provided to each
> -) > OLD> organization that has unicast address space.  A resulting advantage
> -) > OLD> over GLOP is that the mechanisms in IPv4 and IPv6 become more
> -) > OLD> similar.
> -) > 
> -) > NEW> This draft specifies a mechanism similar to [RFC3306], whereby a
> -) > NEW> range of global IPv4 multicast address space is provided to each
> -) > NEW> organization that has unicast address space.  A resulting advantage
> -) > NEW> over GLOP is that the mechanisms in IPv4 and IPv6 become more
> -) > NEW> similar.
> -) > NEW>
> -) > NEW> This draft does not obsolete or update RFC 3180, as the mechanism
> -) > NEW> described in RFC 3180 is still required for organizations with
> -) > NEW> prefix allocations more specific than /24. Organizations using RFC
> -) > NEW> 3180 allocations may continue to do so. In fact, it is conceivable
> -) > NEW> that an organization might use both RFC 3180 allocations and the
> -) > NEW> allocation method described in this document.
> -) > 
> -) > 
> -) > 
> -) > OLD> Bits:  |  8  | Unicast Prefix Length | 24 - Unicast Prefix Length |
> -) > OLD>        +-----+-----------------------+----------------------------+
> -) > OLD> Value: | TBD | Unicast Prefix        | Group ID                   |
> -) > OLD>        +-----+-----------------------+----------------------------+
> -) > 
> -) > NEW> Bits:  | 0 thru 7 |      8 thru N         |      N+1 thru 32       
> -) >   |
> -) > NEW>       
> -) > +----------+-----------------------+----------------------------+
> -) > NEW> Value: |   TBD    |    Unicast Prefix     |       Group ID          
> -) >  |
> -) > NEW>       
> -) > +----------+-----------------------+----------------------------+
> -) > 
> -) > _______________________________________________
> -) > IETF-Announce mailing list
> -) > [e-mail]
> -) > https://www.ietf.org/mailman/listinfo/ietf-announce
> -) 
> -) _______________________________________________
> -) MBONED mailing list
> -) [e-mail]
> -) https://www.ietf.org/mailman/listinfo/mboned
> -) 
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
>