draft-ietf-mboned-rfc3171bis-04.txt   draft-ietf-mboned-rfc3171bis-05.txt 
Network Working Group M. Cotton Network Working Group M. Cotton
Internet-Draft ICANN Internet-Draft ICANN
Intended status: BCP D. Meyer Obsoletes: 3171, 3138 D. Meyer
Expires: May 7, 2009 November 3, 2008 (if approved) February 3, 2009
Intended status: BCP
Expires: August 7, 2009
IANA Guidelines for IPv4 Multicast Address Assignments IANA Guidelines for IPv4 Multicast Address Assignments
draft-ietf-mboned-rfc3171bis-04 draft-ietf-mboned-rfc3171bis-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. This Internet-Draft will expire on August 7, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document obsoletes RFC 3171. It provides guidance for the This document provides guidance for the Internet Assigned Numbers
Internet Assigned Numbers Authority (IANA) in assigning IPv4 Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes
multicast addresses. RFC 3171 and RFC 3138.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Current Assignment Practice . . . . . . . . . . 4 3. Definition of Current Assignment Practice . . . . . . . . . . 3
4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4 4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4
4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 4
5. Internetwork Control Block (224.0.1/24) . . . . . . . . . . . 5 5. Internetwork Control Block (224.0.1/24) . . . . . . . . . . . 5
5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5
6. AD-HOC Blocks (including 224.0.2.0/24 - 224.0.255.0/24) . . . 5 6. AD-HOC Blocks (including 224.0.2.0 - 224.0.255.255) . . . . . 5
6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5
7. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 5 7. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 5
7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5
8. Source Specific Multicast Block (232/8) . . . . . . . . . . . 6 8. Source Specific Multicast Block (232/8) . . . . . . . . . . . 6
8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6
9. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 6 9. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6
9.2. Extended AD-HOC . . . . . . . . . . . . . . . . . . . . . 6 9.2. Extended AD-HOC . . . . . . . . . . . . . . . . . . . . . 6
10. Administratively Scoped Address Block (239/8) . . . . . . . . 7 10. Administratively Scoped Address Block (239/8) . . . . . . . . 7
10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7 10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7
11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7 11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 8 11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 8
12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8 12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8 12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8
12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8 12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8
13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 9 13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 9
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
15. Security Considerations . . . . . . . . . . . . . . . . . . . 9 15. Security Considerations . . . . . . . . . . . . . . . . . . . 9
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
17.1. Normative References . . . . . . . . . . . . . . . . . . . 9 17.1. Normative References . . . . . . . . . . . . . . . . . . . 9
17.2. Informative References . . . . . . . . . . . . . . . . . . 9 17.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction 1. Introduction
The Internet Assigned Numbers Authority (IANA) (www.iana.org) is The Internet Assigned Numbers Authority (IANA) (www.iana.org) is
charged with allocating parameter values for fields in protocols charged with allocating parameter values for fields in protocols
which have been designed, created or are maintained by the Internet which have been designed, created or are maintained by the Internet
Engineering Task Force (IETF). RFC 2780 [RFC2780] provides the IANA Engineering Task Force (IETF). RFC 2780 [RFC2780] provides the IANA
guidance in the assignment of parameters for fields in newly guidance in the assignment of parameters for fields in newly
developed protocols. This memo expands on section 4.4.2 of RFC 2780 developed protocols. This memo expands on section 4.4.2 of RFC 2780
and attempts to codify existing IANA practice used in the assignment and attempts to codify existing IANA practice used in the assignment
IPv4 multicast addresses. IPv4 multicast addresses.
This document is a revision of RFC 3171 [RFC3171], which it This document is a revision of RFC 3171 [RFC3171], which it
obsoletes. It should retain RFC 3171's status as BCP 51. It also obsoletes. It also obsoletes RFC 3138 [RFC3138].
obsoletes RFC 3138 [RFC3138]."
The terms "Specification Required", "Expert Review", "IESG Approval", The terms "Specification Required", "Expert Review", "IESG Approval",
"IETF Consensus", and "Standards Action", are used in this memo to "IETF Review", and "Standards Action", are used in this memo to refer
refer to the processes described in [RFC2434]. The keywords MUST, to the processes described in [RFC5226].
MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT are to be interpreted as defined in [RFC2119].
In general, due to the relatively small size of the IPv4 multicast In general, due to the relatively small size of the IPv4 multicast
address space, further assignment of IPv4 multicast address space is address space, further assignment of IPv4 multicast address space is
recommended only in limited circumstances. Specifically, the IANA recommended only in limited circumstances. Specifically, the IANA
should only assign addresses in those cases where the dynamic should only assign addresses in those cases where the dynamic
selection (SDP/SAP), GLOP, SSM or Administratively Scoped address selection (SDP/SAP), GLOP, SSM or Administratively Scoped address
spaces cannot be used. The guidelines described below are reflected spaces cannot be used. The guidelines described below are reflected
in <http://www.iana.org/numbers.html>. Network operators should also in <http://www.iana.org/numbers.html>. Network operators should also
be aware of the availability of IPv6 multicast addresses and consider be aware of the availability of IPv6 multicast addresses and consider
using them where feasible. using them where feasible.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
The word "allocation" is defined as a block of addresses managed by a The word "allocation" designates a block of addresses managed by a
registry for the purpose of making assignments and allocations. The registry for the purpose of making assignments and allocations. The
word "assignment" is defined a block of addresses, or a single word "assignment" designates a block of addresses, or a single
address, registered to an end-user for use on a specific network, or address, registered to an end-user for use on a specific network, or
set of networks. set of networks.
3. Definition of Current Assignment Practice 3. Definition of Current Assignment Practice
Unlike IPv4 unicast address assignment, where blocks of addresses are Unlike IPv4 unicast address assignment, where blocks of addresses are
delegated to Regional Internet Registries (RIRs), IPv4 multicast delegated to Regional Internet Registries (RIRs), IPv4 multicast
addresses are assigned directly by the IANA. Current registration addresses are assigned directly by the IANA. Current registration
groups appear as follows [IANA]: groups appear as follows [IANA]:
224.0.0.0 - 224.0.0.255 224.0.0/24 Local Network Control Block Address Range Size Designation
------------- ---- -----------
224.0.1.0 - 224.0.1.255 224.0.1/24 Internetwork Control Block 224.0.0.0 - 224.0.0.255 (/24) Local Network Control Block
224.0.2.0 - 224.0.255.0 64769 AD-HOC Block (1) 224.0.1.0 - 224.0.1.255 (/24) Internetwork Control Block
224.1.0.0 - 224.1.255.255 224.1/16 RESERVED 224.0.2.0 - 224.0.255.255 (65024) AD-HOC Block (1)
224.2.0.0 - 224.2.255.255 224.2/16 SDP/SAP Block 224.1.0.0 - 224.1.255.255 (/16) RESERVED
224.252.0.0 - 224.255.255.255 224.252/14 RESERVED 224.2.0.0 - 224.2.255.255 (/16) SDP/SAP Block
225.0.0.0 - 231.255.255.255 7 /8s RESERVED 224.252.0.0 - 224.255.255.255 (/14) RESERVED
232.0.0.0 - 232.255.255.255 232/8 Source Specific Multicast Block 225.0.0.0 - 231.255.255.255 (7 /8s) RESERVED
233.0.0.0 - 233.251.255.255 16515072 GLOP Block 232.0.0.0 - 232.255.255.255 (/8) Source Specific Multicast Block
233.252.0.0 - 233.255.255.255 233.252/14 AD-HOC Block (2) 233.0.0.0 - 233.251.255.255 (16515072) GLOP Block
234.0.0.0 - 238.255.255.255 5 /8s RESERVED 233.252.0.0 - 233.255.255.255 (/14) AD-HOC Block (2)
239.0.0.0 - 239.255.255.255 239/8 Administratively Scoped Block 234.0.0.0 - 238.255.255.255 (5 /8s) RESERVED
239.0.0.0 - 239.255.255.255 (/8) Administratively Scoped Block
The IANA generally assigns addresses from the Local Network Control, The IANA generally assigns addresses from the Local Network Control,
Internetwork Control and AD-HOC blocks. Assignment guidelines for Internetwork Control and AD-HOC blocks. Assignment guidelines for
each of these blocks, as well as for the Source Specific Multicast, each of these blocks, as well as for the Source Specific Multicast,
GLOP and Administratively Scoped Blocks, are described below. GLOP and Administratively Scoped Blocks, are described below.
4. Local Network Control Block (224.0.0/24) 4. Local Network Control Block (224.0.0/24)
Addresses in the Local Network Control block are used for protocol Addresses in the Local Network Control block are used for protocol
control traffic that is not forwarded off link. Examples of this control traffic that is not forwarded off link. Examples of this
skipping to change at page 5, line 25 skipping to change at page 5, line 19
control that MAY be forwarded through the Internet. Examples include control that MAY be forwarded through the Internet. Examples include
224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover [RFC2730]). 224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover [RFC2730]).
5.1. Assignment Guidelines 5.1. Assignment Guidelines
Pursuant to section 4.4.2 of [RFC2780], assignments from the Pursuant to section 4.4.2 of [RFC2780], assignments from the
Internetwork Control block follow an Expert Review, IESG Approval or Internetwork Control block follow an Expert Review, IESG Approval or
Standards Action process. See IANA [IANA] for the current set of Standards Action process. See IANA [IANA] for the current set of
assignments. assignments.
6. AD-HOC Blocks (including 224.0.2.0/24 - 224.0.255.0/24) 6. AD-HOC Blocks (including 224.0.2.0 - 224.0.255.255)
Addresses in the AD-HOC blocks were traditionally used for Addresses in the AD-HOC blocks were traditionally used for
assignments for those applications that don't fit in either the Local assignments for those applications that don't fit in either the Local
or Internetwork Control blocks. These addresses are globally routed or Internetwork Control blocks. These addresses are globally routed
and are typically used by applications that require small blocks of and are typically used by applications that require small blocks of
addressing (e.g., less than a /24 ). Future assignments of blocks of addressing (e.g., less than a /24 ). Future assignments of blocks of
addresses that do not fit in the Local or Internetwork block will be addresses that do not fit in the Local or Internetwork block will be
made in the Extended block. made in the Extended block.
6.1. Assignment Guidelines 6.1. Assignment Guidelines
skipping to change at page 6, line 19 skipping to change at page 6, line 13
policy is required. Note that while no additional IANA assignment is policy is required. Note that while no additional IANA assignment is
required, addresses in the SDP/SAP block are explicitly for use by required, addresses in the SDP/SAP block are explicitly for use by
SDP/SAP and MUST NOT be used for other purposes. SDP/SAP and MUST NOT be used for other purposes.
8. Source Specific Multicast Block (232/8) 8. Source Specific Multicast Block (232/8)
The Source Specific Multicast (SSM) is an extension of IP Multicast The Source Specific Multicast (SSM) is an extension of IP Multicast
in which traffic is forwarded to receivers from only those multicast in which traffic is forwarded to receivers from only those multicast
sources for which the receivers have explicitly expressed interest, sources for which the receivers have explicitly expressed interest,
and is primarily targeted at one-to-many (broadcast) applications. and is primarily targeted at one-to-many (broadcast) applications.
Note that this block as initially assigned to the VMTP transient Note that this block was initially assigned to the VMTP transient
groups IANA [IANA]. groups [IANA].
8.1. Assignment Guidelines 8.1. Assignment Guidelines
Because the SSM model essentially makes the entire multicast address Because the SSM model essentially makes the entire multicast address
space local to the host, no IANA assignment policy is required. space local to the host, no IANA assignment policy is required.
Note, however, that while no additional IANA assignment is required, Note, however, that while no additional IANA assignment is required,
addresses in the SSM block are explicitly for use by SSM and MUST NOT addresses in the SSM block are explicitly for use by SSM and MUST NOT
be used for other purposes. be used for other purposes.
9. GLOP Block (233/8) 9. GLOP Block (233/8)
Addresses in the GLOP block are globally scoped statically assigned Addresses in the GLOP block are globally scoped statically assigned
addresses. The assignment is made, for a domain with 16 bit addresses. The assignment is made, for a domain with 16 bit
Autonomous System Number (ASN), by mapping a domain's autonomous Autonomous System Number (ASN), by mapping a domain's autonomous
system number, expressed in octets as X.Y, into the middle two octets system number, expressed in octets as X.Y, into the middle two octets
of of the GLOP block, yielding an assignment of 233.X.Y.0/24. The of the GLOP block, yielding an assignment of 233.X.Y.0/24. The
mapping and assignment is defined in [RFC3180]. Domains with 32 bit mapping and assignment is defined in [RFC3180]. Domains with 32 bit
ASN should apply for space in the Extended AD-HOC block, or consider ASN should apply for space in the Extended AD-HOC block, or consider
using IPv6 multicast addresses. using IPv6 multicast addresses.
9.1. Assignment Guidelines 9.1. Assignment Guidelines
Because addresses in the GLOP block are algorithmically pre-assigned, Because addresses in the GLOP block are algorithmically pre-assigned,
no IANA assignment policy is required. no IANA assignment policy is required.
9.2. Extended AD-HOC 9.2. Extended AD-HOC
[RFC3138] delegated assignment of the GLOP sub-block mapped by the [RFC3138] delegated to the RIRs the assignment of the GLOP sub-block
[RFC1930] private AS space (233.252.0.0 - 233.255.255.255) to the (233.252.0.0 - 233.255.255.255) mapped by the private AS space
RIRs. This space was known as eGLOP. RFC 3138 should not have asked (64512-65534) and the IANA reserved ASN 65535 [RFC1930]. This space
the RIRs to develop policies for the EGLOP space because [RFC2860] was known as eGLOP. RFC 3138 should not have asked the RIRs to
reserves that to the IETF. It is important to make this space develop policies for the EGLOP space because [RFC2860] reserves that
available for use by network operators and it is therefore to the IETF. It is important to make this space available for use by
appropriate to obsolete RFC 3138 and classify this address range as network operators and it is therefore appropriate to obsolete RFC
available for AD-HOC assignment as per the guidelines in section 6. 3138 and classify this address range as available for AD-HOC
assignment as per the guidelines in section 6.
The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST- The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST-
TEST-NET" for use in documentation and example code. It SHOULD be TEST-NET" for use in documentation and example code. It SHOULD be
used in conjunction with the [RFC2606] domain names example.com or used in conjunction with the [RFC2606] domain names example.com or
example.net in vendor and protocol documentation. Addresses within example.net in vendor and protocol documentation. Addresses within
this block MUST NOT appear on the public Internet. this block MUST NOT appear on the public Internet.
10. Administratively Scoped Address Block (239/8) 10. Administratively Scoped Address Block (239/8)
Addresses in the Administratively Scoped Address block are for local Addresses in the Administratively Scoped Address block are for local
skipping to change at page 8, line 31 skipping to change at page 8, line 31
Given the dynamic nature of IPv4 multicast and its associated infra- Given the dynamic nature of IPv4 multicast and its associated infra-
structure, and the previously undocumented IPv4 multicast address structure, and the previously undocumented IPv4 multicast address
assignment guidelines, the IANA should conduct an annual review of assignment guidelines, the IANA should conduct an annual review of
currently assigned addresses. currently assigned addresses.
12.1. Address Reclamation 12.1. Address Reclamation
During the review described above, addresses that were mis-assigned During the review described above, addresses that were mis-assigned
should, where possible, be reclaimed or reassigned. should, where possible, be reclaimed or reassigned.
The IANA should also review assignments in the AD-HOC, DIS Transient The IANA should also review assignments in the AD-HOC, "DIS Transient
Groups, and ST Multicast Groups [RFC1190] blocks and reclaim those Groups", and ST Multicast Groups [RFC1190] blocks and reclaim those
addresses that are not in use on the global Internet (i.e, those addresses that are not in use on the global Internet (i.e, those
applications which can use SSM, GLOP, or Administratively Scoped applications which can use SSM, GLOP, or Administratively Scoped
addressing, or are not globally routed). addressing, or are not globally routed).
12.2. Positive renewal 12.2. Positive renewal
It is occasionally appropriate to make temporary assignments that can It is occasionally appropriate to make temporary assignments that can
be renewed as necessary. In cases where this happens the registrant be renewed as necessary. In cases where this happens the registrant
needs to positively request an extension to the temporary assignment needs to positively request an extension to the temporary assignment
or the addresses assigned. When the IANA has not received a request or the addresses assigned. When the IANA has not received a request
skipping to change at page 10, line 10 skipping to change at page 10, line 10
BCP 6, RFC 1930, March 1996. BCP 6, RFC 1930, March 1996.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996. for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998. RFC 2365, July 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. Names", BCP 32, RFC 2606, June 1999.
[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
December 1999. December 1999.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000. BCP 37, RFC 2780, March 2000.
skipping to change at page 11, line 5 skipping to change at page 10, line 38
[RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138,
June 2001. June 2001.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments", "IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001. BCP 51, RFC 3171, August 2001.
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
BCP 53, RFC 3180, September 2001. BCP 53, RFC 3180, September 2001.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses Authors' Addresses
Michelle Cotton Michelle Cotton
Internet Corporation for Assigned Names and Numbers Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330 4676 Admiralty Way, Suite 330
Marina del Rey 90292 Marina del Rey 90292
United States United States
Phone: +310-823-9358 Phone: +310-823-9358
Email: michelle.cotton@icann.org Email: michelle.cotton@icann.org
URI: http://www.iana.org/ URI: http://www.iana.org/
David Meyer David Meyer
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 34 change blocks. 
54 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/