676 lines
24 KiB
Plaintext
676 lines
24 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group R. Hinden
|
||
Request for Comments: 2374 Nokia
|
||
Obsoletes: 2073 M. O'Dell
|
||
Category: Standards Track UUNET
|
||
S. Deering
|
||
Cisco
|
||
July 1998
|
||
|
||
|
||
An IPv6 Aggregatable Global Unicast Address Format
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||
|
||
1.0 Introduction
|
||
|
||
This document defines an IPv6 aggregatable global unicast address
|
||
format for use in the Internet. The address format defined in this
|
||
document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
|
||
Addressing Architecture" [ARCH]. It is designed to facilitate
|
||
scalable Internet routing.
|
||
|
||
This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
|
||
Address Format". RFC 2073 will become historic. The Aggregatable
|
||
Global Unicast Address Format is an improvement over RFC 2073 in a
|
||
number of areas. The major changes include removal of the registry
|
||
bits because they are not needed for route aggregation, support of
|
||
EUI-64 based interface identifiers, support of provider and exchange
|
||
based aggregation, separation of public and site topology, and new
|
||
aggregation based terminology.
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC 2119].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 1]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
2.0 Overview of the IPv6 Address
|
||
|
||
IPv6 addresses are 128-bit identifiers for interfaces and sets of
|
||
interfaces. There are three types of addresses: Unicast, Anycast,
|
||
and Multicast. This document defines a specific type of Unicast
|
||
address.
|
||
|
||
In this document, fields in addresses are given specific names, for
|
||
example "subnet". When this name is used with the term "ID" (for
|
||
"identifier") after the name (e.g., "subnet ID"), it refers to the
|
||
contents of the named field. When it is used with the term "prefix"
|
||
(e.g. "subnet prefix") it refers to all of the addressing bits to
|
||
the left of and including this field.
|
||
|
||
IPv6 unicast addresses are designed assuming that the Internet
|
||
routing system makes forwarding decisions based on a "longest prefix
|
||
match" algorithm on arbitrary bit boundaries and does not have any
|
||
knowledge of the internal structure of IPv6 addresses. The structure
|
||
in IPv6 addresses is for assignment and allocation. The only
|
||
exception to this is the distinction made between unicast and
|
||
multicast addresses.
|
||
|
||
The specific type of an IPv6 address is indicated by the leading bits
|
||
in the address. The variable-length field comprising these leading
|
||
bits is called the Format Prefix (FP).
|
||
|
||
This document defines an address format for the 001 (binary) Format
|
||
Prefix for Aggregatable Global Unicast addresses. The same address
|
||
format could be used for other Format Prefixes, as long as these
|
||
Format Prefixes also identify IPv6 unicast addresses. Only the "001"
|
||
Format Prefix is defined here.
|
||
|
||
3.0 IPv6 Aggregatable Global Unicast Address Format
|
||
|
||
This document defines an address format for the IPv6 aggregatable
|
||
global unicast address assignment. The authors believe that this
|
||
address format will be widely used for IPv6 nodes connected to the
|
||
Internet. This address format is designed to support both the
|
||
current provider-based aggregation and a new type of exchange-based
|
||
aggregation. The combination will allow efficient routing
|
||
aggregation for sites that connect directly to providers and for
|
||
sites that connect to exchanges. Sites will have the choice to
|
||
connect to either type of aggregation entity.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 2]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
While this address format is designed to support exchange-based
|
||
aggregation (in addition to current provider-based aggregation) it is
|
||
not dependent on exchanges for it's overall route aggregation
|
||
properties. It will provide efficient route aggregation with only
|
||
provider-based aggregation.
|
||
|
||
Aggregatable addresses are organized into a three level hierarchy:
|
||
|
||
- Public Topology
|
||
- Site Topology
|
||
- Interface Identifier
|
||
|
||
Public topology is the collection of providers and exchanges who
|
||
provide public Internet transit services. Site topology is local to
|
||
a specific site or organization which does not provide public transit
|
||
service to nodes outside of the site. Interface identifiers identify
|
||
interfaces on links.
|
||
|
||
______________ ______________
|
||
--+/ \+--------------+/ \+----------
|
||
( P1 ) +----+ ( P3 ) +----+
|
||
+\______________/ | |----+\______________/+--| |--
|
||
| +--| X1 | +| X2 |
|
||
| ______________ / | |-+ ______________ / | |--
|
||
+/ \+ +-+--+ \ / \+ +----+
|
||
( P2 ) / \ +( P4 )
|
||
--+\______________/ / \ \______________/
|
||
| / \ | |
|
||
| / | | |
|
||
| / | | |
|
||
_|_ _/_ _|_ _|_ _|_
|
||
/ \ / \ / \ / \ / \
|
||
( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C )
|
||
\___/ \___/ \___/ \___/ \___/
|
||
| / \
|
||
_|_ _/_ \ ___
|
||
/ \ / \ +-/ \
|
||
( S.D ) ( S.E ) ( S.F )
|
||
\___/ \___/ \___/
|
||
|
||
As shown in the figure above, the aggregatable address format is
|
||
designed to support long-haul providers (shown as P1, P2, P3, and
|
||
P4), exchanges (shown as X1 and X2), multiple levels of providers
|
||
(shown at P5 and P6), and subscribers (shown as S.x) Exchanges
|
||
(unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
|
||
Organizations who connect to these exchanges will also subscribe
|
||
(directly, indirectly via the exchange, etc.) for long-haul service
|
||
from one or more long-haul providers. Doing so, they will achieve
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 3]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
addressing independence from long-haul transit providers. They will
|
||
be able to change long-haul providers without having to renumber
|
||
their organization. They can also be multihomed via the exchange to
|
||
more than one long-haul provider without having to have address
|
||
prefixes from each long-haul provider. Note that the mechanisms used
|
||
for this type of provider selection and portability are not discussed
|
||
in the document.
|
||
|
||
3.1 Aggregatable Global Unicast Address Structure
|
||
|
||
The aggregatable global unicast address format is as follows:
|
||
|
||
| 3| 13 | 8 | 24 | 16 | 64 bits |
|
||
+--+-----+---+--------+--------+--------------------------------+
|
||
|FP| TLA |RES| NLA | SLA | Interface ID |
|
||
| | ID | | ID | ID | |
|
||
+--+-----+---+--------+--------+--------------------------------+
|
||
|
||
<--Public Topology---> Site
|
||
<-------->
|
||
Topology
|
||
<------Interface Identifier----->
|
||
|
||
Where
|
||
|
||
FP Format Prefix (001)
|
||
TLA ID Top-Level Aggregation Identifier
|
||
RES Reserved for future use
|
||
NLA ID Next-Level Aggregation Identifier
|
||
SLA ID Site-Level Aggregation Identifier
|
||
INTERFACE ID Interface Identifier
|
||
|
||
The following sections specify each part of the IPv6 Aggregatable
|
||
Global Unicast address format.
|
||
|
||
3.2 Top-Level Aggregation ID
|
||
|
||
Top-Level Aggregation Identifiers (TLA ID) are the top level in the
|
||
routing hierarchy. Default-free routers must have a routing table
|
||
entry for every active TLA ID and will probably have additional
|
||
entries providing routing information for the TLA ID in which they
|
||
are located. They may have additional entries in order to optimize
|
||
routing for their specific topology, but the routing topology at all
|
||
levels must be designed to minimize the number of additional entries
|
||
fed into the default free routing tables.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 4]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
This addressing format supports 8,192 (2^13) TLA ID's. Additional
|
||
TLA ID's may be added by either growing the TLA field to the right
|
||
into the reserved field or by using this format for additional format
|
||
prefixes.
|
||
|
||
The issues relating to TLA ID assignment are beyond the scope of this
|
||
document. They will be described in a document under preparation.
|
||
|
||
3.3 Reserved
|
||
|
||
The Reserved field is reserved for future use and must be set to
|
||
zero.
|
||
|
||
The Reserved field allows for future growth of the TLA and NLA fields
|
||
as appropriate. See section 4.0 for a discussion.
|
||
|
||
3.4 Next-Level Aggregation Identifier
|
||
|
||
Next-Level Aggregation Identifier's are used by organizations
|
||
assigned a TLA ID to create an addressing hierarchy and to identify
|
||
sites. The organization can assign the top part of the NLA ID in a
|
||
manner to create an addressing hierarchy appropriate to its network.
|
||
It can use the remainder of the bits in the field to identify sites
|
||
it wishes to serve. This is shown as follows:
|
||
|
||
| n | 24-n bits | 16 | 64 bits |
|
||
+-----+--------------------+--------+-----------------+
|
||
|NLA1 | Site ID | SLA ID | Interface ID |
|
||
+-----+--------------------+--------+-----------------+
|
||
|
||
Each organization assigned a TLA ID receives 24 bits of NLA ID space.
|
||
This NLA ID space allows each organization to provide service to
|
||
approximately as many organizations as the current IPv4 Internet can
|
||
support total networks.
|
||
|
||
Organizations assigned TLA ID's may also support NLA ID's in their
|
||
own Site ID space. This allows the organization assigned a TLA ID to
|
||
provide service to organizations providing public transit service and
|
||
to organizations who do not provide public transit service. These
|
||
organizations receiving an NLA ID may also choose to use their Site
|
||
ID space to support other NLA ID's. This is shown as follows:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 5]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
| n | 24-n bits | 16 | 64 bits |
|
||
+-----+--------------------+--------+-----------------+
|
||
|NLA1 | Site ID | SLA ID | Interface ID |
|
||
+-----+--------------------+--------+-----------------+
|
||
|
||
| m | 24-n-m | 16 | 64 bits |
|
||
+-----+--------------+--------+-----------------+
|
||
|NLA2 | Site ID | SLA ID | Interface ID |
|
||
+-----+--------------+--------+-----------------+
|
||
|
||
| o |24-n-m-o| 16 | 64 bits |
|
||
+-----+--------+--------+-----------------+
|
||
|NLA3 | Site ID| SLA ID | Interface ID |
|
||
+-----+--------+--------+-----------------+
|
||
|
||
The design of the bit layout of the NLA ID space for a specific TLA
|
||
ID is left to the organization responsible for that TLA ID. Likewise
|
||
the design of the bit layout of the next level NLA ID is the
|
||
responsibility of the previous level NLA ID. It is recommended that
|
||
organizations assigning NLA address space use "slow start" allocation
|
||
procedures similar to [RFC2050].
|
||
|
||
The design of an NLA ID allocation plan is a tradeoff between routing
|
||
aggregation efficiency and flexibility. Creating hierarchies allows
|
||
for greater amount of aggregation and results in smaller routing
|
||
tables. Flat NLA ID assignment provides for easier allocation and
|
||
attachment flexibility, but results in larger routing tables.
|
||
|
||
3.5 Site-Level Aggregation Identifier
|
||
|
||
The SLA ID field is used by an individual organization to create its
|
||
own local addressing hierarchy and to identify subnets. This is
|
||
analogous to subnets in IPv4 except that each organization has a much
|
||
greater number of subnets. The 16 bit SLA ID field support 65,535
|
||
individual subnets.
|
||
|
||
Organizations may choose to either route their SLA ID "flat" (e.g.,
|
||
not create any logical relationship between the SLA identifiers that
|
||
results in larger routing tables), or to create a two or more level
|
||
hierarchy (that results in smaller routing tables) in the SLA ID
|
||
field. The latter is shown as follows:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 6]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
| n | 16-n | 64 bits |
|
||
+-----+------------+-------------------------------------+
|
||
|SLA1 | Subnet | Interface ID |
|
||
+-----+------------+-------------------------------------+
|
||
|
||
| m |16-n-m | 64 bits |
|
||
+----+-------+-------------------------------------+
|
||
|SLA2|Subnet | Interface ID |
|
||
+----+-------+-------------------------------------+
|
||
|
||
The approach chosen for structuring an SLA ID field is the
|
||
responsibility of the individual organization.
|
||
|
||
The number of subnets supported in this address format should be
|
||
sufficient for all but the largest of organizations. Organizations
|
||
which need additional subnets can arrange with the organization they
|
||
are obtaining Internet service from to obtain additional site
|
||
identifiers and use this to create additional subnets.
|
||
|
||
3.6 Interface ID
|
||
|
||
Interface identifiers are used to identify interfaces on a link.
|
||
They are required to be unique on that link. They may also be unique
|
||
over a broader scope. In many cases an interfaces identifier will be
|
||
the same or be based on the interface's link-layer address.
|
||
Interface IDs used in the aggregatable global unicast address format
|
||
are required to be 64 bits long and to be constructed in IEEE EUI-64
|
||
format [EUI-64]. These identifiers may have global scope when a
|
||
global token (e.g., IEEE 48bit MAC) is available or may have local
|
||
scope where a global token is not available (e.g., serial links,
|
||
tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE
|
||
EUI-64 terminology) in the EUI-64 identifier must be set correctly,
|
||
as defined in [ARCH], to indicate global or local scope.
|
||
|
||
The procedures for creating EUI-64 based Interface Identifiers is
|
||
defined in [ARCH]. The details on forming interface identifiers is
|
||
defined in the appropriate "IPv6 over <link>" specification such as
|
||
"IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
|
||
|
||
4.0 Technical Motivation
|
||
|
||
The design choices for the size of the fields in the aggregatable
|
||
address format were based on the need to meet a number of technical
|
||
requirements. These are described in the following paragraphs.
|
||
|
||
The size of the Top-Level Aggregation Identifier is 13 bits. This
|
||
allows for 8,192 TLA ID's. This size was chosen to insure that the
|
||
default-free routing table in top level routers in the Internet is
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 7]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
kept within the limits, with a reasonable margin, of the current
|
||
routing technology. The margin is important because default-free
|
||
routers will also carry a significant number of longer (i.e., more-
|
||
specific) prefixes for optimizing paths internal to a TLA and between
|
||
TLAs.
|
||
|
||
The important issue is not only the size of the default-free routing
|
||
table, but the complexity of the topology that determines the number
|
||
of copies of the default-free routes that a router must examine while
|
||
computing a forwarding table. Current practice with IPv4 it is
|
||
common to see a prefix announced fifteen times via different paths.
|
||
|
||
The complexity of Internet topology is very likely to increase in the
|
||
future. It is important that IPv6 default-free routing support
|
||
additional complexity as well as a considerably larger internet.
|
||
|
||
It should be noted for comparison that at the time of this writing
|
||
(spring, 1998) the IPv4 default-free routing table contains
|
||
approximately 50,000 prefixes. While this shows that it is possible
|
||
to support more routes than 8,192 it is matter of debate if the
|
||
number of prefixes supported today in IPv4 is already too high for
|
||
current routing technology. There are serious issues of route
|
||
stability as well as cases of providers not supporting all top level
|
||
prefixes. The technical requirement was to pick a TLA ID size that
|
||
was below, with a reasonable margin, what was being done with IPv4.
|
||
|
||
The choice of 13 bits for the TLA field was an engineering
|
||
compromise. Fewer bits would have been too small by not supporting
|
||
enough top level organizations. More bits would have exceeded what
|
||
can be reasonably accommodated, with a reasonable margin, with
|
||
current routing technology in order to deal with the issues described
|
||
in the previous paragraphs.
|
||
|
||
If in the future, routing technology improves to support a larger
|
||
number of top level routes in the default-free routing tables there
|
||
are two choices on how to increase the number TLA identifiers. The
|
||
first is to expand the TLA ID field into the reserved field. This
|
||
would increase the number of TLA ID's to approximately 2 million.
|
||
The second approach is to allocate another format prefix (FP) for use
|
||
with this address format. Either or a combination of these
|
||
approaches allows the number of TLA ID's to increase significantly.
|
||
|
||
The size of the Reserved field is 8 bits. This size was chosen to
|
||
allow significant growth of either the TLA ID and/or the NLA ID
|
||
fields.
|
||
|
||
The size of the Next-Level Aggregation Identifier field is 24 bits.
|
||
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 8]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
This allows for approximately sixteen million NLA ID's if used in a
|
||
flat manner. Used hierarchically it allows for a complexity roughly
|
||
equivalent to the IPv4 address space (assuming an average network
|
||
size of 254 interfaces). If in the future additional room for
|
||
complexity is needed in the NLA ID, this may be accommodated by
|
||
extending the NLA ID into the Reserved field.
|
||
|
||
The size of the Site-Level Aggregation Identifier field is 16 bits.
|
||
This supports 65,535 individual subnets per site. The design goal
|
||
for the size of this field was to be sufficient for all but the
|
||
largest of organizations. Organizations which need additional
|
||
subnets can arrange with the organization they are obtaining Internet
|
||
service from to obtain additional site identifiers and use this to
|
||
create additional subnets.
|
||
|
||
The Site-Level Aggregation Identifier field was given a fixed size in
|
||
order to force the length of all prefixes identifying a particular
|
||
site to be the same length (i.e., 48 bits). This facilitates
|
||
movement of sites in the topology (e.g., changing service providers
|
||
and multi-homing to multiple service providers).
|
||
|
||
The Interface ID Interface Identifier field is 64 bits. This size
|
||
was chosen to meet the requirement specified in [ARCH] to support
|
||
EUI-64 based Interface Identifiers.
|
||
|
||
5.0 Acknowledgments
|
||
|
||
The authors would like to express our thanks to Thomas Narten, Bob
|
||
Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
|
||
Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
|
||
for their review and constructive comments.
|
||
|
||
6.0 References
|
||
|
||
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management",
|
||
RFC 1881, December 1995.
|
||
|
||
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
|
||
RFC 2373, July 1998.
|
||
|
||
[AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August
|
||
1995.
|
||
|
||
[AUTO] Thompson, S., and T. Narten., "IPv6 Stateless Address
|
||
Autoconfiguration", RFC 1971, August 1996.
|
||
|
||
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
|
||
Networks", Work in Progress.
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 9]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
|
||
Registration Authority",
|
||
http://standards.ieee.org/db/oui/tutorials/EUI64.html,
|
||
March 1997.
|
||
|
||
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
|
||
Networks", Work in Progress.
|
||
|
||
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
|
||
(IPv6) Specification", RFC 1883, December 1995.
|
||
|
||
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
|
||
and J. Postel, "Internet Registry IP Allocation
|
||
Guidelines", BCP 12, RFC 1466, November 1996.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
7.0 Security Considerations
|
||
|
||
IPv6 addressing documents do not have any direct impact on Internet
|
||
infrastructure security. Authentication of IPv6 packets is defined
|
||
in [AUTH].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 10]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
8.0 Authors' Addresses
|
||
|
||
Robert M. Hinden
|
||
Nokia
|
||
232 Java Drive
|
||
Sunnyvale, CA 94089
|
||
USA
|
||
|
||
Phone: 1 408 990-2004
|
||
EMail: hinden@iprg.nokia.com
|
||
|
||
|
||
Mike O'Dell
|
||
UUNET Technologies, Inc.
|
||
3060 Williams Drive
|
||
Fairfax, VA 22030
|
||
USA
|
||
|
||
Phone: 1 703 206-5890
|
||
EMail: mo@uunet.uu.net
|
||
|
||
|
||
Stephen E. Deering
|
||
Cisco Systems, Inc.
|
||
170 West Tasman Drive
|
||
San Jose, CA 95134-1706
|
||
USA
|
||
|
||
Phone: 1 408 527-8213
|
||
EMail: deering@cisco.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 11]
|
||
|
||
RFC 2374 IPv6 Global Unicast Address Format July 1998
|
||
|
||
|
||
9.0 Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hinden, et. al. Standards Track [Page 12]
|
||
|