connectivity to these active next hops, using one or more of the
available link or network layer mechanisms, as described below.
- Any suitable link layer notification, such as those provided by
IEEE 802.11, can be used to determine connectivity, each time a
packet is transmitted to an active next hop. For example, absence
of a link layer ACK or failure to get a CTS after sending RTS,
even after the maximum number of retransmission attempts,
indicates loss of the link to this active next hop.
- If layer-2 notification is not available, passive acknowledgment
SHOULD be used when the next hop is expected to forward the
packet, by listening to the channel for a transmission attempt
made by the next hop. If transmission is not detected within
NEXT_HOP_WAIT milliseconds or the next hop is the destination (and
thus is not supposed to forward the packet) one of the following
methods SHOULD be used to determine connectivity:
* Receiving any packet (including a Hello message) from the next
hop.
* A RREQ unicast to the next hop, asking for a route to the next
hop.
* An ICMP Echo Request message unicast to the next hop.
If a link to the next hop cannot be detected by any of these methods,
the forwarding node SHOULD assume that the link is lost, and take
corrective action by following the methods specified in Section 6.11.
6.11. Route Error (RERR) Messages, Route Expiry and Route Deletion
Generally, route error and link breakage processing requires the
following steps:
- Invalidating existing routes
- Listing affected destinations
- Determining which, if any, neighbors may be affected
- Delivering an appropriate RERR to such neighbors
A Route Error (RERR) message MAY be either broadcast (if there are
many precursors), unicast (if there is only 1 precursor), or
iteratively unicast to all precursors (if broadcast is
inappropriate). Even when the RERR message is iteratively unicast to
several precursors, it is considered to be a single control message
for the purposes of the description in the text that follows. With
that understanding, a node SHOULD NOT generate more than
RERR_RATELIMIT RERR messages per second.
A node initiates processing for a RERR message in three situations:
(i) if it detects a link break for the next hop of an active
route in its routing table while transmitting data (and
route repair, if attempted, was unsuccessful), or
(ii) if it gets a data packet destined to a node for which it
does not have an active route and is not repairing (if
using local repair), or
(iii) if it receives a RERR from a neighbor for one or more
active routes.
For case (i), the node first makes a list of unreachable destinations
consisting of the unreachable neighbor and any additional
destinations (or subnets, see section 7) in the local routing table
that use the unreachable neighbor as the next hop. In this case, if
a subnet route is found to be newly unreachable, an IP destination
address for the subnet is constructed by appending zeroes to the
subnet prefix as shown in the route table entry. This is
unambiguous, since the precursor is known to have route table
information with a compatible prefix length for that subnet.
For case (ii), there is only one unreachable destination, which is
the destination of the data packet that cannot be delivered. For
case (iii), the list should consist of those destinations in the RERR
for which there exists a corresponding entry in the local routing
table that has the transmitter of the received RERR as the next hop.
Some of the unreachable destinations in the list could be used by
neighboring nodes, and it may therefore be necessary to send a (new)
RERR. The RERR should contain those destinations that are part of
the created list of unreachable destinations and have a non-empty
precursor list.
The neighboring node(s) that should receive the RERR are all those
that belong to a precursor list of at least one of the unreachable
destination(s) in the newly created RERR. In case there is only one
unique neighbor that needs to receive the RERR, the RERR SHOULD be
unicast toward that neighbor. Otherwise the RERR is typically sent
to the local broadcast address (Destination IP == 255.255.255.255,
TTL == 1) with the unreachable destinations, and their corresponding
destination sequence numbers, included in the packet. The DestCount
field of the RERR packet indicates the number of unreachable
destinations included in the packet.
Just before transmitting the RERR, certain updates are made on the
routing table that may affect the destination sequence numbers for
the unreachable destinations. For each one of these destinations,
the corresponding routing table entry is updated as follows:
1. The destination sequence number of this routing entry, if it
exists and is valid, is incremented for cases (i) and (ii) above,
and copied from the incoming RERR in case (iii) above.
2. The entry is invalidated by marking the route entry as invalid
3. The Lifetime field is updated to current time plus DELETE_PERIOD.
Before this time, the entry SHOULD NOT be deleted.
Note that the Lifetime field in the routing table plays dual role --
for an active route it is the expiry time, and for an invalid route
it is the deletion time. If a data packet is received for an invalid
route, the Lifetime field is updated to current time plus
DELETE_PERIOD. The determination of DELETE_PERIOD is discussed in
Section 10.
6.12. Local Repair
When a link break in an active route occurs, the node upstream of
that break MAY choose to repair the link locally if the destination
was no farther than MAX_REPAIR_TTL hops away. To repair the link
break, the node increments the sequence number for the destination
and then broadcasts a RREQ for that destination. The TTL of the RREQ
should initially be set to the following value:
max(MIN_REPAIR_TTL, 0.5 * #hops) + LOCAL_ADD_TTL,
where #hops is the number of hops to the sender (originator) of the
currently undeliverable packet. Thus, local repair attempts will
often be invisible to the originating node, and will always have TTL
>= MIN_REPAIR_TTL + LOCAL_ADD_TTL. The node initiating the repair
then waits the discovery period to receive RREPs in response to the
RREQ. During local repair data packets SHOULD be buffered. If, at
the end of the discovery period, the repairing node has not received
a RREP (or other control message creating or updating the route) for
that destination, it proceeds as described in Section 6.11 by
transmitting a RERR message for that destination.
On the other hand, if the node receives one or more RREPs (or other
control message creating or updating the route to the desired
destination) during the discovery period, it first compares the hop
count of the new route with the value in the hop count field of the
invalid route table entry for that destination. If the hop count of
the newly determined route to the destination is greater than the hop
count of the previously known route the node SHOULD issue a RERR
message for the destination, with the 'N' bit set. Then it proceeds
as described in Section 6.7, updating its route table entry for that
destination.
A node that receives a RERR message with the 'N' flag set MUST NOT
delete the route to that destination. The only action taken should
be the retransmission of the message, if the RERR arrived from the
next hop along that route, and if there are one or more precursor
nodes for that route to the destination. When the originating node
receives a RERR message with the 'N' flag set, if this message came
from its next hop along its route to the destination then the
originating node MAY choose to reinitiate route discovery, as
described in Section 6.3.
Local repair of link breaks in routes sometimes results in increased
path lengths to those destinations. Repairing the link locally is
likely to increase the number of data packets that are able to be
delivered to the destinations, since data packets will not be dropped
as the RERR travels to the originating node. Sending a RERR to the
originating node after locally repairing the link break may allow the
originator to find a fresh route to the destination that is better,
based on current node positions. However, it does not require the
originating node to rebuild the route, as the originator may be done,
or nearly done, with the data session.
When a link breaks along an active route, there are often multiple
destinations that become unreachable. The node that is upstream of
the lost link tries an immediate local repair for only the one
destination towards which the data packet was traveling. Other
routes using the same link MUST be marked as invalid, but the node
handling the local repair MAY flag each such newly lost route as
locally repairable; this local repair flag in the route table MUST be
reset when the route times out (e.g., after the route has been not
been active for ACTIVE_ROUTE_TIMEOUT). Before the timeout occurs,
these other routes will be repaired as needed when packets arrive for
the other destinations. Hence, these routes are repaired as needed;
if a data packet does not arrive for the route, then that route will
not be repaired. Alternatively, depending upon local congestion, the
node MAY begin the process of establishing local repairs for the
other routes, without waiting for new packets to arrive. By
proactively repairing the routes that have broken due to the loss of
the link, incoming data packets for those routes will not be subject
to the delay of repairing the route and can be immediately forwarded.
However, repairing the route before a data packet is received for it
runs the risk of repairing routes that are no longer in use.
Therefore, depending upon the local traffic in the network and
whether congestion is being experienced, the node MAY elect to
proactively repair the routes before a data packet is received;
otherwise, it can wait until a data is received, and then commence
the repair of the route.
6.13. Actions After Reboot
A node participating in the ad hoc network must take certain actions
after reboot as it might lose all sequence number records for all
destinations, including its own sequence number. However, there may
be neighboring nodes that are using this node as an active next hop.
This can potentially create routing loops. To prevent this
possibility, each node on reboot waits for DELETE_PERIOD before
transmitting any route discovery messages. If the node receives a
RREQ, RREP, or RERR control packet, it SHOULD create route entries as
appropriate given the sequence number information in the control
packets, but MUST not forward any control packets. If the node
receives a data packet for some other destination, it SHOULD
broadcast a RERR as described in subsection 6.11 and MUST reset the
waiting timer to expire after current time plus DELETE_PERIOD.
It can be shown [4] that by the time the rebooted node comes out of
the waiting phase and becomes an active router again, none of its
neighbors will be using it as an active next hop any more. Its own
sequence number gets updated once it receives a RREQ from any other
node, as the RREQ always carries the maximum destination sequence
number seen en route. If no such RREQ arrives, the node MUST
initialize its own sequence number to zero.
6.14. Interfaces
Because AODV should operate smoothly over wired, as well as wireless,
networks, and because it is likely that AODV will also be used with
multiple wireless devices, the particular interface over which
packets arrive must be known to AODV whenever a packet is received.
This includes the reception of RREQ, RREP, and RERR messages.
Whenever a packet is received from a new neighbor, the interface on
which that packet was received is recorded into the route table entry
for that neighbor, along with all the other appropriate routing
information. Similarly, whenever a route to a new destination is
learned, the interface through which the destination can be reached
is also recorded into the destination's route table entry.
When multiple interfaces are available, a node retransmitting a RREQ
message rebroadcasts that message on all interfaces that have been
configured for operation in the ad-hoc network, except those on which
it is known that all of the nodes neighbors have already received the
RREQ For instance, for some broadcast media (e.g., Ethernet) it may
be presumed that all nodes on the same link receive a broadcast
message at the same time. When a node needs to transmit a RERR, it
SHOULD only transmit it on those interfaces that have neighboring
precursor nodes for that route.
7. AODV and Aggregated Networks
AODV has been designed for use by mobile nodes with IP addresses that
are not necessarily related to each other, to create an ad hoc
network. However, in some cases a collection of mobile nodes MAY
operate in a fixed relationship to each other and share a common
subnet prefix, moving together within an area where an ad hoc network
has formed. Call such a collection of nodes a "subnet". In this
case, it is possible for a single node within the subnet to advertise
reachability for all other nodes on the subnet, by responding with a
RREP message to any RREQ message requesting a route to any node with
the subnet routing prefix. Call the single node the "subnet router".
In order for a subnet router to operate the AODV protocol for the
whole subnet, it has to maintain a destination sequence number for
the entire subnet. In any such RREP message sent by the subnet
router, the Prefix Size field of the RREP message MUST be set to the
length of the subnet prefix. Other nodes sharing the subnet prefix
SHOULD NOT issue RREP messages, and SHOULD forward RREQ messages to
the subnet router.
The processing for RREPs that give routes to subnets (i.e., have
nonzero prefix length) is the same as processing for host-specific
RREP messages. Every node that receives the RREP with prefix size
information SHOULD create or update the route table entry for the
subnet, including the sequence number supplied by the subnet router,
and including the appropriate precursor information. Then, in the
future the node can use the information to avoid sending future RREQs
for other nodes on the same subnet.
When a node uses a subnet route it may be that a packet is routed to
an IP address on the subnet that is not assigned to any existing node
in the ad hoc network. When that happens, the subnet router MUST
return ICMP Host Unreachable message to the sending node. Upstream
nodes receiving such an ICMP message SHOULD record the information
that the particular IP address is unreachable, but MUST NOT
invalidate the route entry for any matching subnet prefix.
If several nodes in the subnet advertise reachability to the subnet
defined by the subnet prefix, the node with the lowest IP address is
elected to be the subnet router, and all other nodes MUST stop
advertising reachability.
The behavior of default routes (i.e., routes with routing prefix
length 0) is not defined in this specification. Selection of routes
sharing prefix bits should be according to longest match first.
8. Using AODV with Other Networks
In some configurations, an ad hoc network may be able to provide
connectivity between external routing domains that do not use AODV.
If the points of contact to the other networks can act as subnet
routers (see Section 7) for any relevant networks within the external
routing domains, then the ad hoc network can maintain connectivity to
the external routing domains. Indeed, the external routing networks
can use the ad hoc network defined by AODV as a transit network.
In order to provide this feature, a point of contact to an external
network (call it an Infrastructure Router) has to act as the subnet
router for every subnet of interest within the external network for
which the Infrastructure Router can provide reachability. This
includes the need for maintaining a destination sequence number for
that external subnet.
If multiple Infrastructure Routers offer reachability to the same
external subnet, those Infrastructure Routers have to cooperate (by
means outside the scope of this specification) to provide consistent
AODV semantics for ad hoc access to those subnets.
9. Extensions
In this section, the format of extensions to the RREQ and RREP
messages is specified. All such extensions appear after the message
data, and have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | type-specific data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type 1-255
Length The length of the type-specific data, not including the Type
and Length fields of the extension in bytes.
Extensions with types between 128 and 255 may NOT be skipped. The
rules for extensions will be spelled out more fully, and conform to
the rules for handling IPv6 options.
9.1. Hello Interval Extension Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Hello Interval ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Hello Interval, continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
Length 4
Hello Interval
The number of milliseconds between successive transmissions
of a Hello message.
The Hello Interval extension MAY be appended to a RREP message with
TTL == 1, to be used by a neighboring receiver in determine how long
to wait for subsequent such RREP messages (i.e., Hello messages; see
section 6.9).
10. Configuration Parameters
This section gives default values for some important parameters
associated with AODV protocol operations. A particular mobile node
may wish to change certain of the parameters, in particular the
NET_DIAMETER, MY_ROUTE_TIMEOUT, ALLOWED_HELLO_LOSS, RREQ_RETRIES, and
possibly the HELLO_INTERVAL. In the latter case, the node should
advertise the HELLO_INTERVAL in its Hello messages, by appending a
Hello Interval Extension to the RREP message. Choice of these
parameters may affect the performance of the protocol. Changing
NODE_TRAVERSAL_TIME also changes the node's estimate of the
NET_TRAVERSAL_TIME, and so can only be done with suitable knowledge
about the behavior of other nodes in the ad hoc network. The
configured value for MY_ROUTE_TIMEOUT MUST be at least 2 *
PATH_DISCOVERY_TIME.
Parameter Name Value
---------------------- -----
ACTIVE_ROUTE_TIMEOUT 3,000 Milliseconds
ALLOWED_HELLO_LOSS 2
BLACKLIST_TIMEOUT RREQ_RETRIES * NET_TRAVERSAL_TIME
DELETE_PERIOD see note below
HELLO_INTERVAL 1,000 Milliseconds
LOCAL_ADD_TTL 2
MAX_REPAIR_TTL 0.3 * NET_DIAMETER
MIN_REPAIR_TTL see note below
MY_ROUTE_TIMEOUT 2 * ACTIVE_ROUTE_TIMEOUT
NET_DIAMETER 35
NET_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME * NET_DIAMETER
NEXT_HOP_WAIT NODE_TRAVERSAL_TIME + 10
NODE_TRAVERSAL_TIME 40 milliseconds
PATH_DISCOVERY_TIME 2 * NET_TRAVERSAL_TIME
RERR_RATELIMIT 10
RING_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME *
(TTL_VALUE + TIMEOUT_BUFFER)
RREQ_RETRIES 2
RREQ_RATELIMIT 10
TIMEOUT_BUFFER 2
TTL_START 1
TTL_INCREMENT 2
TTL_THRESHOLD 7
TTL_VALUE see note below
The MIN_REPAIR_TTL should be the last known hop count to the
destination. If Hello messages are used, then the
ACTIVE_ROUTE_TIMEOUT parameter value MUST be more than the value
(ALLOWED_HELLO_LOSS * HELLO_INTERVAL). For a given
ACTIVE_ROUTE_TIMEOUT value, this may require some adjustment to the
value of the HELLO_INTERVAL, and consequently use of the Hello
Interval Extension in the Hello messages.
TTL_VALUE is the value of the TTL field in the IP header while the
expanding ring search is being performed. This is described further
in section 6.4. The TIMEOUT_BUFFER is configurable. Its purpose is
to provide a buffer for the timeout so that if the RREP is delayed
due to congestion, a timeout is less likely to occur while the RREP
is still en route back to the source. To omit this buffer, set
TIMEOUT_BUFFER = 0.
DELETE_PERIOD is intended to provide an upper bound on the time for
which an upstream node A can have a neighbor B as an active next hop
for destination D, while B has invalidated the route to D. Beyond
this time B can delete the (already invalidated) route to D. The
determination of the upper bound depends somewhat on the
characteristics of the underlying link layer. If Hello messages are
used to determine the continued availability of links to next hop
nodes, DELETE_PERIOD must be at least ALLOWED_HELLO_LOSS *
HELLO_INTERVAL. If the link layer feedback is used to detect loss of
link, DELETE_PERIOD must be at least ACTIVE_ROUTE_TIMEOUT. If hello
messages are received from a neighbor but data packets to that
neighbor are lost (e.g., due to temporary link asymmetry), we have to
make more concrete assumptions about the underlying link layer. We
assume that such asymmetry cannot persist beyond a certain time, say,
a multiple K of HELLO_INTERVAL. In other words, a node will
invariably receive at least one out of K subsequent Hello messages
from a neighbor if the link is working and the neighbor is sending no
other traffic. Covering all possibilities,
DELETE_PERIOD = K * max (ACTIVE_ROUTE_TIMEOUT, HELLO_INTERVAL)
(K = 5 is recommended).
NET_DIAMETER measures the maximum possible number of hops between two
nodes in the network. NODE_TRAVERSAL_TIME is a conservative estimate
of the average one hop traversal time for packets and should include
queuing delays, interrupt processing times and transfer times.
ACTIVE_ROUTE_TIMEOUT SHOULD be set to a longer value (at least 10,000
milliseconds) if link-layer indications are used to detect link
breakages such as in IEEE 802.11 [5] standard. TTL_START should be
set to at least 2 if Hello messages are used for local connectivity
information. Performance of the AODV protocol is sensitive to the
chosen values of these constants, which often depend on the
characteristics of the underlying link layer protocol, radio
technologies etc. BLACKLIST_TIMEOUT should be suitably increased if
an expanding ring search is used. In such cases, it should be
{[(TTL_THRESHOLD - TTL_START)/TTL_INCREMENT] + 1 + RREQ_RETRIES} *
NET_TRAVERSAL_TIME. This is to account for possible additional route
discovery attempts.
11. Security Considerations
Currently, AODV does not specify any special security measures. Route
protocols, however, are prime targets for impersonation attacks. In
networks where the node membership is not known, it is difficult to
determine the occurrence of impersonation attacks, and security
prevention techniques are difficult at best. However, when the
network membership is known and there is a danger of such attacks,
AODV control messages must be protected by use of authentication
techniques, such as those involving generation of unforgeable and
cryptographically strong message digests or digital signatures.
While AODV does not place restrictions on the authentication
mechanism used for this purpose, IPsec AH is an appropriate choice
for cases where the nodes share an appropriate security association
that enables the use of AH.
In particular, RREP messages SHOULD be authenticated to avoid
creation of spurious routes to a desired destination. Otherwise, an
attacker could masquerade as the desired destination, and maliciously
deny service to the destination and/or maliciously inspect and
consume traffic intended for delivery to the destination. RERR
messages, while less dangerous, SHOULD be authenticated in order to
prevent malicious nodes from disrupting valid routes between nodes
that are communication partners.
AODV does not make any assumption about the method by which addresses
are assigned to the mobile nodes, except that they are presumed to
have unique IP addresses. Therefore, no special consideration, other
than what is natural because of the general protocol specifications,
can be made about the applicability of IPsec authentication headers
or key exchange mechanisms. However, if the mobile nodes in the ad
hoc network have pre-established security associations, it is
presumed that the purposes for which the security associations are
created include that of authorizing the processing of AODV control
messages. Given this understanding, the mobile nodes should be able
to use the same authentication mechanisms based on their IP addresses
as they would have used otherwise.
12. IANA Considerations
AODV defines a "Type" field for messages sent to port 654. A new
registry has been created for the values for this Type field, and the
following values have been assigned:
Message Type Value
--------------------------- -----
Route Request (RREQ) 1
Route Reply (RREP) 2
Route Error (RERR) 3
Route-Reply Ack (RREP-ACK) 4
AODV control messages can have extensions. Currently, only one
extension is defined. A new registry has been created for the Type
field of the extensions:
Extension Type Value
--------------------------- -----
Hello Interval 1
Future values of the Message Type or Extension Type can be allocated
using standards action [2].
13. IPv6 Considerations
See [6] for detailed operation for IPv6. The only changes to the
protocol are that the address fields are enlarged.
14. Acknowledgments
Special thanks to Ian Chakeres, UCSB, for his extensive suggestions
and contributions to recent revisions.
We acknowledge with gratitude the work done at University of
Pennsylvania within Carl Gunter's group, as well as at Stanford and
CMU, to determine some conditions (especially involving reboots and
lost RERRs) under which previous versions of AODV could suffer from
routing loops. Contributors to those efforts include Karthikeyan
Bhargavan, Joshua Broch, Dave Maltz, Madanlal Musuvathi, and Davor
Obradovic. The idea of a DELETE_PERIOD, for which expired routes
(and, in particular, the sequence numbers) to a particular
destination must be maintained, was also suggested by them.
We also acknowledge the comments and improvements suggested by Sung-
Ju Lee (especially regarding local repair), Mahesh Marina, Erik
Nordstrom (who provided text for section 6.11), Yves Prelot, Marc
Mosko, Manel Guerrero Zapata, Philippe Jacquet, and Fred Baker.
15. Normative References
[1] Bradner, S. "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
16. Informative References
[3] Manner, J., et al., "Mobility Related Terminology", Work in
Progress, July 2001.
[4] Karthikeyan Bhargavan, Carl A. Gunter, and Davor Obradovic.
Fault Origin Adjudication. In Proceedings of the Workshop on
Formal Methods in Software Practice, Portland, OR, August 2000.
[5] IEEE 802.11 Committee, AlphaGraphics #35, 10201 N.35th Avenue,
Phoenix AZ 85051. Wireless LAN Medium Access Control MAC and
Physical Layer PHY Specifications, June 1997. IEEE Standard
802.11-97.
[6] Perkins, C., Royer, E. and S. Das, "Ad hoc on demand distance
vector (AODV) routing for ip version 6", Work in Progress.
17. Authors' Addresses
Charles E. Perkins
Communications Systems Laboratory
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94303
USA
Phone: +1 650 625 2986
Fax: +1 650 691 2170 (fax)
EMail: Charles.Perkins@nokia.com
Elizabeth M. Belding-Royer
Department of Computer Science
University of California, Santa Barbara
Santa Barbara, CA 93106
Phone: +1 805 893 3411
Fax: +1 805 893 8553
EMail: ebelding@cs.ucsb.edu
Samir R. Das
Department of Electrical and Computer Engineering
& Computer Science
University of Cincinnati
Cincinnati, OH 45221-0030
Phone: +1 513 556 2594
Fax: +1 513 556 7326
EMail: sdas@ececs.uc.edu
18. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.