NEMO Working Group Vijay Devarapalli INTERNET DRAFT Nokia 21 June 2003 Ryuji Wakikawa Category: Standards Track Keio University Alexandru Petrescu Motorola Pascal Thubert Cisco Systems Nemo Basic Support Protocol draft-ietf-nemo-basic-support-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document describes a protocol to support network mobility as the mobile network attaches to different points in the Internet. The protocol allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The protocol is based on extensions to Mobile IPv6 [1]. The Mobile Router [2] which connects the network to the Internet runs the NEMO protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. Devarapalli, et al. Expires 21 December 2003 [Page 1] Internet Draft Nemo Basic Support 21 June 2003 Contents Status of This Memo 1 Abstract 1 1. Introduction 4 2. Terminology 5 3. Overview of the NEMO Protocol 7 4. Message Formats 10 4.1. Binding Update . . . . . . . . . . . . . . . . . . . . . 10 4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 10 4.3. Mobile Network Prefix Option . . . . . . . . . . . . . . 11 4.4. Mobile Network Prefix Length Option . . . . . . . . . . . 12 5. Mobile Router Operation 14 5.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 14 5.2. Sending Binding Updates . . . . . . . . . . . . . . . . . 15 5.3. Receiving Binding Acknowledgements . . . . . . . . . . . 15 5.4. Error Processing . . . . . . . . . . . . . . . . . . . . 16 5.5. Establishment of Bi-directional Tunnel . . . . . . . . . 17 5.6. Neighbour Discovery for Mobile Router . . . . . . . . . . 18 5.7. Multicast Groups for Mobile Router . . . . . . . . . . . 18 6. Home Agent Operation 19 6.1. Prefix Table . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Mobile Network Prefix Registration . . . . . . . . . . . 19 6.3. Advertising Mobile Network Reachability . . . . . . . . . 21 6.4. Establishment of Bi-directional Tunnel . . . . . . . . . 21 6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . . 21 6.6. Sending Binding Acknowledgements . . . . . . . . . . . . 22 6.7. Mobile Network Prefix De-Registration . . . . . . . . . . 23 7. Extended Home Network 24 8. Support for Dynamic Routing Protocols 26 9. Use of IPsec to protect the Signaling Messages 27 10. Security Considerations 28 11. IANA Considerations 28 Devarapalli, et al. Expires 21 December 2003 [Page 2] Internet Draft Nemo Basic Support 21 June 2003 12. Contributors 28 13. Acknowledgements 28 A. Examples of Operation 31 Addresses 34 Devarapalli, et al. Expires 21 December 2003 [Page 3] Internet Draft Nemo Basic Support 21 June 2003 1. Introduction This document describes protocol extensions to Mobile IPv6 (MIPv6) [1] to enable support for network mobility. The extensions provide a backward compatibility with Mobile IPv6, and in particular, a Nemo compliant Home Agent can operate as a MIPv6 Home Agent as well. The Nemo Basic Support works in such a way that session continuity is ensured for all the nodes in the mobile network even as the Mobile Router changes its point of attachment to the Internet. It also provides connectivity and reachability for all nodes in the mobile network as the network moves. The solution supports both Local Fixed Nodes [2] and Mobile Nodes in the Mobile Metwork. Within the context of this document, the definition of a Mobile Router extends that of a Mobile IPv6 [1] Mobile Node, by adding the capability of routing between its point of attachment (Care-of Address) and a subnet which moves with the Mobile Router. The solution described in this document requires setting up a bi-directional tunnel between the Mobile Router and its Home Agent. This tunnel is set up when the Mobile Router sends a successful Binding Update to its Home Agent, informing the Home Agent of its current point of attachment. All traffic between the nodes in the Mobile Network and Correspondent Nodes passes through the Home Agent. This document does not describe how to route optimize this traffic. Route Optimization will be dealt with in later specifications. IPsec is used to secure all signalling messages between the Mobile Router and its Home Agent. The use of IPsec to protect the signaling messages is described in [3]. This document does not introduce any additional requirements as far as the use of IPsec is concerned. The terminology document [2] describes Nested Mobility as a scenario where a Mobile Router allows another Mobile Router to attach to its mobile network. There could be arbitrary levels of nested mobility. The operation of each Mobile Router remains the same whether the Mobile Router attaches to another Mobile Router or to a fixed Access Router on the Internet. The solution described here does not place any restriction on the number of levels for nested mobility. But it should be noted that this might introduce important overhead on the data packets as each level of nestedness introduces another IPv6 header encapsulation. Devarapalli, et al. Expires 21 December 2003 [Page 4] Internet Draft Nemo Basic Support 21 June 2003 2. Terminology There is a separate NEMO terminology document [2], which defines the terms related to Network Mobility used in the document. The keywords "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 [2]. Prefix Table It is a list of a mobile network prefixes indexed by the extended Home Address of a Mobile Router. The prefix table is managed by the Home Agent. When a Home Agent receives a Binding Update without any options, it searches a correspondent Mobile Network prefix in the prefix table, keying with the Home Address of the requesting Mobile Router. This is an optional data structure. Mobile Network Prefix The IPv6 prefix advertised in the Mobile Network by one or more Mobile Routers. There could be multiple prefixes in the Mobile Network. extended Home Network Prefix The aggregation of one or more Home Network and Mobile Network prefixes. The extended Home Network is generally the granularity that is exposed by the Home Agents to the routing infrastructure over routing protocols. extended Home Network The network associated with the extended Home Network Prefix. The extended Home Network may be physical or virtual. extended Home Address The Home Address is derived from the Home Network prefix. The extended Home Address is taken from the extended Home Network. More precisely, the extended Home Address can be either from the Home Network or from one of the Mobile Router's Mobile Network prefixes. The extended Home Address inherits from the properties of the Home Devarapalli, et al. Expires 21 December 2003 [Page 5] Internet Draft Nemo Basic Support 21 June 2003 Address and can be used for registration to the Home Agent as described in this document. Devarapalli, et al. Expires 21 December 2003 [Page 6] Internet Draft Nemo Basic Support 21 June 2003 3. Overview of the NEMO Protocol A Mobile Network is a network segment or subnet which can move and attach to arbitrary points in the Internet. A Mobile Network does not allow any transit traffic and can only be accessed via specific Gateways called Mobile Routers that manage its movement. A Mobile Router does not distribute the Mobile Network routes to the infrastructure at its point of attachment (i.e. in the visited network). Instead, it maintains a bidirectional tunnel to a Home Agent that advertises an aggregation of Mobile Networks to the infrasructure. The Mobile Router is also the default gateway for the Mobile Network. A Mobile Network can also consist of multiple and nested subnets. In particular, a router with no support for mobility may be permanently attached to a Mobile Network for local distribution. Also, Mobile Routers may be attached to Mobile Networks owned by different Mobile Routers and form a graph. In particular, with Basic Nemo Support, each Mobile Router is attached to another Mobile Network by a single interface, and if loops are avoided, the graph is a tree. A Mobile Router has an unique Home Address through which it is always reachable. The Home Address is configured from a prefix that is aggregated and advertised by its Home Agent. The prefix could either be the prefix advertised on the home link or the prefix delegated to the Mobile Router. This is described in detail in Section 7. The Mobile Router can have more than one Home Address if there are multiple prefixes in the home link. The Mobile Router also advertises one or more prefixes in the mobile network attached to it. The actual mechanism for allocating these Mobile Network Prefixes is outside the scope of this specification. However, it is recommended that these prefixes are allocated in such a manner that they can be aggregated under the home link. When the Mobile Router moves away from the home link and attaches to a new access router, it acquires a Care-of Address from the visited link. The Mobile Router at any time can appear and behave as a Mobile Host or a Mobile Router. If the Mobile Router wants connectivity, rechability and session continuity for nodes in the Mobile Network, it acts as a Mobile Router. In either case, as soon as the Mobile Router acquires a Care-of Address, it immediately sends a Binding Update to its Home Agent as described in [1]. When the Home Agent receives this Binding Update it creates a binding cache entry binding the Mobile Router's Home Address to its Care-of address at the current point of attachment. If the Mobile Router wishes to act as a Mobile Router and provide connectivity to nodes in the Mobile Network, it indicates this to the Home Agent by setting a flag 'R' in the Binding Update. It also Devarapalli, et al. Expires 21 December 2003 [Page 7] Internet Draft Nemo Basic Support 21 June 2003 includes information about the Mobile Network Prefix in the Binding Update using one of the modes described in Section 5.2, so that the Home Agent can forward packets meant for nodes in the mobile network to the Mobile Router. Two new Mobility Header Options are described in this document to carry prefix information. These new options are described in Section 4.3 and section 4.4. If the Mobile Network has more than one IPv6 prefix and wants the Home Agent to setup forwarding for all these prefixes, it includes multiple prefix information options in a single Binding Update. The Home Agent sets up forwarding for each of these prefixes to the Mobile Router's Care-of Address. In some scenarios the Home Agent already knows which prefixes are owned by a Mobile Router. In these scenarios, the Mobile Router does not include any prefix information in the Binding Update. The Home Agent sets up forwarding for all prefixes owned by the Mobile Router, when it receives a Binding Update from the mobile router. If the Home Agent successfully processes the Binding Update and sets up forwarding for the Mobile Network Prefix, it sends a Binding Acknowledgement to the Mobile Router. Once the binding process completes, a bi-directional tunnel is established between the Home Agent and the Mobile Router. The tunnel end points are Mobile Router's Care-of Address and the Home Agent's address. If a packet with a source address belonging to the Mobile Network Prefix is received from the Mobile Network, the Mobile Router reverse-tunnels the packet to the Home Agent through this tunnel. This reverse-tunneling is done by using IP-in-IP encapsulation [4]. The Home Agent decapsulates this packet and forwards it to the CN. The Mobile Router is however free to use route optimization as described in [1] for packet originated by the Mobile Router itself. When a data packet is sent by a Correspondent Node to a node in the Mobile Network, it gets routed to the Home Agent which currently has the binding for the Mobile Router. It is expected that the Mobile Router's network prefix would be aggregated at the Home Agent, which advertises the resulting aggregation. Alternatively, the Home Agent may receive the data packets meant for the Mobile Network by advertising routes to the Mobile Network prefix. The actual mechanism by which these routes are advertised is outside the scope of this document for now. When the Home Agent receives a data packet meant for a node in the mobile network, it tunnels the packet to Mobile Router's current Care-of address. The Mobile Router decapsulates the packet and forwards it onto the link where the Mobile Network is connected. The Mobile Network could consist of nodes which are Local Fixed Nodes, Local Mobile Nodes and Visiting Mobile Nodes [2]. The protocol described here ensures complete transparency of network mobility to the Local Fixed Nodes. Visiting Mobile Nodes are those Devarapalli, et al. Expires 21 December 2003 [Page 8] Internet Draft Nemo Basic Support 21 June 2003 nodes which are Mobile Nodes as described in Mobile IPv6. Visiting Mobile Nodes treat the Mobile Network as just a normal IPv6 access network and run the Mobile IPv6 protocol. It is also possible for the Mobile Router and the Home Agent to run a routing protocol through the bi-directional tunnel. The Mobile Router need not include prefix information in the Binding Update. Instead the Home Agent uses the routing protocol updates to setup forwarding for the Mobile Network. When running the routing protocol it is required that the bi-directional tunnel be treated as a tunnel interface. The tunnel interface is included as the list of interfaces on which routing protocol is active. The Mobile Router should be careful to not run the routing protocol on its egress interface when it is away from the home link. Finally, the Home Agent(s) may be configured with static routes to the Mobile Network Prefix via the Mobile Router home address.. In that case, the routes are set independently of the binding flows and the returning Home of a Mobile Router. The benefit is that such movement does not induce any additional signalling in the form of routing updates in the Home Network. The drawback of that model is that the routes are present even if the Mobile Routers that are not reachable (at Home or bound) at a given point of time. Devarapalli, et al. Expires 21 December 2003 [Page 9] Internet Draft Nemo Basic Support 21 June 2003 4. Message Formats 4.1. Binding Update A new flag `R' is included in the Binding Update to indicate to the Home Agent if the Binding Update is coming from a Mobile Router and not from a mobile node. The rest of the Binding Update format remains the same as defined in [1]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|R| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mobile Router Flag(R) The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router. If the flag is set to 0, the Home Agent assumes that the Mobile Router is just behaving as a Mobile Node, and should not forward packets destined for the mobile network to the Mobile Router. Mobility Options Variable length field which can include zero or more mobility options. This document defines two new mobility options in addition to what is defined [1]. The receiver MUST skip and ignore any options which it does not understand. 4.2. Binding Acknowledgement There is no change in the Binding Acknowledgement format from what is used in Mobile IPv6 [1]. However, this document introduces the following new status values for the binding acknowledgement. Status Devarapalli, et al. Expires 21 December 2003 [Page 10] Internet Draft Nemo Basic Support 21 June 2003 140 Mobile Router Operation not permitted 141 Invalid Prefix 142 Not Authorized for Prefix 143 Mobile Network Prefix information unavailable. Status values less than 128 indicate that the Binding Update was processed successfully by the receiving nodes. Values greater than 128 indicate that the Binding Update was rejected by the receiving node. 4.3. Mobile Network Prefix Option The Mobile Network Prefix Option is included in the Binding Update to indicate to the Home Agent the prefix information for the mobile network. There could be multiple Mobile Network Prefix Options if the Mobile Router has more than one IPv6 prefix in the Mobile Network and wants the Home Agent to forward packets for each of these prefixes to the Mobile Router's current location. The Mobile Network Prefix Option has an alignment requirement of 8n+4. Its format is as follows. 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 | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Devarapalli, et al. Expires 21 December 2003 [Page 11] Internet Draft Nemo Basic Support 21 June 2003 Length 8 bit unsigned integer indicating the length in octets of the option excluding the type and length fields. Set to 18. Reserved Set to 0. Ignored for now. Prefix Length 8 bit unsigned integer indicating the length of the IPv6 prefix contained in the option. Mobile Network Prefix A 16 byte field contains the Mobile Network Prefix. 4.4. Mobile Network Prefix Length Option The Mobile Network Prefix Length Option can be used by the Mobile Router if the Mobile Network Prefix can be deduced from the Home Address of the Mobile Router. If there is only one Mobile Network Prefix owned by the Mobile Router, using this option helps in saving 16 bytes in the Binding Update by not including the prefix information. There can only be one instance of this option in a Binding Update. The Mobile Network Prefix Option cannot be present in the Binding Update if this option is present. 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 | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 8 bit unsigned integer indicating the length in octets of the option excluding the type and length field. Set to 2. Devarapalli, et al. Expires 21 December 2003 [Page 12] Internet Draft Nemo Basic Support 21 June 2003 Reserved Set to 0. Ignored for now. Prefix Length 8 bit unsigned integer indicating the length of the IPv6 prefix contained in the option Devarapalli, et al. Expires 21 December 2003 [Page 13] Internet Draft Nemo Basic Support 21 June 2003 5. Mobile Router Operation Mobile Router operation is derived largely from the combined behaviors of a Host, of a Router [8], and of a Mobile Node [1] (also please see definition of a Mobile Host in [2] and the definition of an IPv4 Mobile Node [10]). A Mobile Node can act in two different ways: (1) as a Mobile Host (in which case the Mobile IPv6 Home Agent doesn't maintain any prefix information related to the Mobile Host's Home Address, but does maintain a binding cache entry related to the Mobile Host's Home Address) and (2) as a Mobile Router (in which case, in addition to maintaining the binding cache entry corresponding to the Mobile Router Home Address, the Mobile IPv6 Home Agent also maintains forwarding information related to prefixes assigned to the Mobile Network). The distinction between the the two modes is represented by the value of the 'R' bit. Mobile Router uses various data structures, exchanges specific binding messages with Home Agent, performs a specific Neighbour Discovery behavior and joins certain multicast groups. 5.1. Data Structures Like a Mobile Host, a Mobile Router also maintains a Binding Update List, described in section 11.1 of Mobile IPv6 specification[1]. The Binding Update list is a conceptual data structure which records information that is sent in the Binding Updates. There is one entry per each destination that the Mobile Router is currently sending Binding Updates to. This document introduces a new Prefix Information field in the Binding Update list structure. This field is used to store any prefix information that the Mobile Router includes in the Binding Update. If the Mobile Router sets the 'R' bit in the Binding Update, but does not include any prefix information in it (implicit mode), this field is set to null. Similar to a Mobile Host, a Mobile Router also stores the information regarding status of flags of the Binding Update, in the corresponding Binding Update List entry. Additionally, this document introduces a new mobile router flag 'R' for this entry. The status of this flag is stored in the Binding Update list whenever a Binding Update is sent. Similarly to a Mobile Host, a Mobile Router maintains a Home Agent list populated according to the same procedure as a Mobile Host. Devarapalli, et al. Expires 21 December 2003 [Page 14] Internet Draft Nemo Basic Support 21 June 2003 5.2. Sending Binding Updates A Mobile Router will send Binding Updates to its Home Agent according to the same procedures that a Mobile Host uses. The Mobile Router MUST use one of the following modes to instruct the Home Agent to determine the Mobile Network prefix. In all three modes, the Mobile Router sets the 'R' bit to 1. Implicit: In this mode, the Mobile Router does not include either a Mobile Network Prefix Option or a Mobile Network Prefix Length Option in the Binding Update (but it does include the Home Address Option in the Destination Options header, as all Mobile Hosts do). The Home Agent can use any mechanism (not defined in this document) to determine the Mobile Network Prefix(es) owned the Mobile Router. One of the well known mechanisms is where the Home Agent maintains a Pre-configured Prefix Table listing all the Mobile Network prefixes owned by a particular Mobile Router. This table is keyed on the Home Address of the Mobile Router. Explicit: In this mode, the Mobile Router includes one or more Mobile Network Prefix Options in the Binding Update. These options contain information about the Mobile Network Prefix(es) configured on the Mobile Network. Explicit combined: In this mode, the Mobile Router instructs the Home Agent to derive the Mobile Network Prefix by using: (1) the Home Address in the Home Address Option carried in the Destination Options header of the same packet that carries the Mobility Header containing this Binding Update and (2) the prefix length carried in the Mobile Network Prefix Length Option. In this case, Mobile Router includes one and only one Mobile Network Prefix Length Option. It MUST not include a Mobile Network Prefix Option if this method is used. If the Mobile Router flag is set, The Mobile Router MUST also set the Home Registration flag 'H'. 5.3. Receiving Binding Acknowledgements The Mobile Router receives Binding Acknowledgements from the Home Agent, corresponding to the Binding Updates it sent. If the Binding Devarapalli, et al. Expires 21 December 2003 [Page 15] Internet Draft Nemo Basic Support 21 June 2003 Acknowledgement status is set to a value less than 128, the Mobile Router assumes that the Binding Update was processed succesfully by the Home Agent. The Mobile Router can then start using the bi-directional tunnel for reverse tunneling traffic from the mobile network. 5.4. Error Processing If the Binding Acknowledgement status is set to a value between 128 and 140, the Mobile Router takes necessary actions as described in the Mobile IPv6 specification [1]. If the Mobile Router sent a Binding Update to the Home Agent in implicit mode (i.e. the prefix field in the Binding Update list entry is null) then the Mobile Router interprets only the error status '140' (Mobile Router Operation not permitted) and '143' (Mobile Network Prefix information unavailable). For this Binding Update, the Mobile Router will discard Binding Acknowledgements with codes '141' and '142', and log the information. For the same Binding Update, if the status is '140', Mobile Router SHOULD send a similar Binding Update (implicit mode) to another Home Agent on the same home link. If no Home Agent replies positively then the Mobile Router MUST refrain from sending any Binding Update with the 'R' bit set to any Home Agent on the home link, and log the information. For the same Binding Update, if the status is '143', Mobile Router SHOULD send a similar Binding Update (implicit mode) to another Home Agent on the same home link. If no Home Agent replies positively then Mobile Router SHOULD refrain from sending this Binding Update to any Home Agent on the home link, and MAY send Binding Updates in another mode (e.g. explicitly include a prefix) to a Home Agent on the same home link. If the Mobile Router sent a Binding Update to Home Agent in any other mode than implicit mode (i.e. the prefix field in the Binding Update list entry is not null) then the Mobile Router interprets only the error status '141' (Invalid Prefix) and '142' (Not Authorized for Prefix). For this Binding Update, the Mobile Router will discard Binding Acknowledgements with codes '140' and '143', and log the information. For the same Binding Update, if the status is set to '141', then the Mobile Router should send a similar Binding Update (same explicit prefix(es) or prefix lens) to another Home Agent on the same home link. If no Home Agent replies positively then Mobile Router SHOULD refrain from sending this Binding Updates to any Home Agent on the Devarapalli, et al. Expires 21 December 2003 [Page 16] Internet Draft Nemo Basic Support 21 June 2003 home link. At this point, Mobile Router MAY try try to obtain and own a prefix by the same means that it initially got attributed the Invalid Prefix in question. Alternatively, Mobile Router MAY send Binding Updates in another mode (e.g. implicit mode) to a Home Agent on the same home link. For the same Binding Update, if the status is set to '142', then the Mobile Router should send a similar Binding Update (same explicit prefix(es) or prefix lens) to another Home Agent on the same home link. If no Home Agent replies positively then Mobile Router SHOULD refrain from sending this Binding Updates to any Home Agent on the home link. Additionally, the Home Agent MUST stop advertising the respective prefix(es) in the mobile network with associated Router Advertisements, and modify its own forwarding information accordingly. Following this, the Mobile Router MAY send Binding Updates in another mode (e.g. implicit) to a Home Agent on the same home link. If at the end of this Error Processing procedure the Mobile Router has tried every available modes of sending Binding Updates and still has not received a positive Binding Acknowledgement (status valued 0) for this Home Address from any Home Agent on its home link, then the Mobile Router MUST stop sending Binding Updates with the 'R' bit set for this Home Address and log the information. In all the above cases, the Mobile Router should assume that the Home Agent did not create a binding cache entry for the Mobile Router's home address. 5.5. Establishment of Bi-directional Tunnel Only when a successful Binding Acknowledgement ('Status' field valued 0) is received will the Mobile Router set up its endpoint of the bi-directional tunnel. The bi-directional tunnel between Mobile Router and Home Agent allows packets to flow in both directions between these entities, while the Mobile Router is connected to a Visisted Link. The bi-directional tunnel involves two virtual links [4]: one virtual link has the address of the tunnel entry point as the Care-of Address of the Mobile Router and the tunnel exit point as the address of the Home Agent; the other virtual link has as tunnel entry point the Home Agent address and as tunnel exit point the Care-of Address of the Mobile Router. Both addresses are unicast addresses. Packets sent by the nodes in the mobile network (including the Mobile Router) and addressed to any nodes other than nodes in the mobile network are encapsulated by Mobile Router and decapsulated by the Devarapalli, et al. Expires 21 December 2003 [Page 17] Internet Draft Nemo Basic Support 21 June 2003 Home Agent. Packets sent by any nodes other than nodes in the mobile network and addressed to nodes in the mobile network are encapsulated by the Home Agent and decapsulated by the Mobile Router. A Mobile Router MAY limit the number of mobile routers that attach to its mobile network (the number of levels in the nested aggregation) by means of setting the Tunnel Encapsulation Limit field of the Tunnel Encapsulation option. A Mobile Router uses the Tunnel Hop Limit that is normally assigned to routers (not to hosts); see IANA numbers. Following the successful setup of the bi-directional tunnel on the Mobile Router, the forwarding information on the Mobile Router is updated such as to allow forwarding of packets as described above. 5.6. Neighbour Discovery for Mobile Router A Mobile Router MAY be configured to send Router Advertisements and reply to Router Solicitations on the interface attached to the home link. The value of the Router Lifetime field MUST be set to zero to prevent other nodes from configuring the Mobile Router as the default router. A Mobile Router SHOULD NOT send unsolicited Router Advertisements and SHOULD NOT reply to Router Solicitations on any egress interface when that interface is attached to any other link than the home link. However, the Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor Solicitations received on the egress interface, for topologically correct addresses. A Mobile Router MAY use the received Router Advertisements on the interface connected to the home link, but only for logging and administrative purposes. Only when that interface is connected to a visisted link, the Mobile Router uses information in the received Router Advertisements for purposes other than logging; this includes address configuration, setting up a default route and movement detection. 5.7. Multicast Groups for Mobile Router When at home, the Mobile Router joins the multicast group All Routers Address with scopes '1' interface-local (on the home-advertising interface), '2' link-local and '5' site-local on any of its egress interfaces. When in a visited network, the Mobile Router MUST NOT join any of the above groups on the respective interface. Devarapalli, et al. Expires 21 December 2003 [Page 18] Internet Draft Nemo Basic Support 21 June 2003 6. Home Agent Operation In order for a Mobile Router to operate correctly, the home agent MUST satisfy all the requirements listed in Section 8.4 of [1]. 6.1. Prefix Table In some scenarios, the Home Agent might need to maintain a Prefix Table of Mobile Routers and the IPv6 prefixes owned by Mobile Routers. The Home Agent MUST maintain this table if the Mobile Routers operate under the implicit mode where they do not include any prefix information in the Binding Updates. Each entry in the Prefix Table conceptually contains the following fields: - The Home Address of the Mobile Router. This field is used as the key for searching the pre-configured prefix table. - The Mobile Network prefix of the Mobile Router associated with the Home Address. In some deployment scenarios it is important that the Home Agent prevents a misbehaving Mobile Router from claiming Mobile Network Prefixes belonging to another Mobile Router. The Home Agent can prevent such attacks if it maintains the Prefix Table and verifies the Prefix Information provided by the Mobile Router against the entries in the Prefix Table. 6.2. Mobile Network Prefix Registration The Home Agent processes the Binding Update as described in Section 10.3.1 of the Mobile IPv6 specification. This section describes the processing of the Binding Update if the Mobile Router (R) flag is set. The Home Agent performs the following check in addition. - The Binding Update MUST be authenticated by IPsec according to Section 5.1 of [1]. - The Home Registration (H) bit MUST be set. If not, the Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 140. Note: The basic support does not allow sending Binding Update for a Mobile Network prefix to correspondent nodes (for route optimization).. - If the Mobile Network Prefix Length option is present in the Binding Update, then there MUST be only one instance of Devarapalli, et al. Expires 21 December 2003 [Page 19] Internet Draft Nemo Basic Support 21 June 2003 this option in the Binding Update. Also the Mobile Network Prefix Option MUST not be present in the same Binding Update. Otherwise, the Home Agent MUST discard the Binding Update and send an ICMP Parameter Problem, Code 0, message to the Mobile Router If the home agent does not reject the Binding Update as described above, then it retrieves the Mobile Network Prefix information as described below. - If a Mobile Network Prefix Length Option is present in the Binding Update, the Home Address in the Home Address destination option MUST be an extended Home Address. In that case, the Mobile Network Prefix is obtained from that Home Address and the prefix length in the Mobile Network Prefix Length Option. If the Home Agent verfies the prefix information with the Prefix Table and the check fails, the Home Agent MUST discard the Binding Update and send a Binding Acknowldegement with status set to 142 (Not Authorized for Prefix). - If a Mobile Network Prefix Option is present in the Binding Update, the prefix information for the mobile network prefix is retrieved from the Mobile Network Prefix field and the Prefix Length field of the option. If the Binding Update contains more than one option, the Home Agent MUST set up forwarding for all of the Mobile Network Prefixes. Otherwise the Home Agent MUST not forward traffic to any of the prefixes, reject the Binding Update and send a Binding Acknowledgement with status set to 141 (Invalid Prefix). If the Home Agent verfies the prefix information with the Prefix Table and the check fails, the Home Agent MUST discard the Binding Update and send a Binding Acknowldegement with status set to 142 (Not Authorized for Prefix). - If there are no options in the Binding Update, the Home Agent MUST figure out which prefixes are assigned to the Mobile Router from the Pre-configured Prefix Table. If the home agent can not find the correspondent Mobile Network prefix, it MUST reject the Binding Update and send a Binding Acknowledgement with the Status field set to 143 (Prefix Information unavailable). If the Lifetime specified in the Binding Update is zero or the specified care-of address matches the home address for the binding, then this is a request to delete the cached binding for the home address and specified mobile network prefixes. The Binding Update is processed according to the procedure described in Section 6.7. Devarapalli, et al. Expires 21 December 2003 [Page 20] Internet Draft Nemo Basic Support 21 June 2003 If all checks are passed, the home agent creates a binding cache entry for Mobile Router's home address, or updates the binding cache entry if it already exists. Otherwise, the home agent MUST NOT register the binding of the Mobile Router's home address. The home agent also creates a bi-directional tunnel to the mobile router for the requested Mobile Network prefix, or update an existing bi-directional tunnel as described in Section 6.4 6.3. Advertising Mobile Network Reachability In order to be able to receive packets meant for the Mobile Network, the Home Agent advertises reachability to the Mobile Network. If the Mobile Network Prefix can be aggregated under the Home Link prefix, then the routing updates advertising reachability to the Mobile Network are sent only on the Home Link. If the Home Agent is the only router on the Home Link, routes to the Mobile Network Prefix gets aggregated naturally under the Home Agent and the Home Agent does not have to do anything special. If the Home Agent receives routing updates through a dynamic routing protocol from the Mobile Router, those routes are propogated by the routing protocol running on the Home Agent on the relevant interfaces. 6.4. Establishment of Bi-directional Tunnel The establishment and operation of the bi-directional tunnel is implementation specific. However, all implementations MUST be capable of the following operations. - The Home Agent can tunnel packets meant for the Mobile Network Prefix to the Mobile Router's current location, the Care-of Address of the Mobile Router. - The Home Agent can accept packets tunneled by the Mobile Router with source address of the outer IPv6 header set to the Care-of Address of the Mobile Router. 6.5. Forwarding Packets When the Home Agent receives a data packet destined for the mobile network, it fowards the packet to the Mobile Router through the bi-directional tunnel. The Home Agent either uses only the routing table, only the Binding Cache or a combination of routing table Devarapalli, et al. Expires 21 December 2003 [Page 21] Internet Draft Nemo Basic Support 21 June 2003 and Binding Cache to route packets to the Mobile Network. This is implementation specific. Two examples are shown below. 1. The Home Agent maintains a route to the Mobile Network Prefix with the next hop set to the Mobile Router's Home Address. When the Home Agent tries to forward the packet to the next hop, it finds a binding cache entry for the home address. Then the Home Agent extracts the Mobile Router's Care-of address and tunnels the packet to the Care-of address. 2. The Home Agent maintains a route to the Mobile Network Prefix with the outgoing interface set to the bi-directional tunnel interface between the Home Agent and the Mobile Router. For this purpose, the Home Agent MUST treat this tunnel as a tunnel interface. When the packets are forwarded through the tunnel interface, they get encapsulated automatically with the source address and destination address in the outer IPv6 header set to the Home Agent's address and the Mobile Router's Care-of address, respectively. 6.6. Sending Binding Acknowledgements A Home Agent serving a Mobile Router sends Binding Acknowledgements according to the same rules it uses for sending Binding Acknowledgements to Mobile Hosts, with the following enhancements. The Home Agent sets the status code in the Binding Acknowledgement to '0' (Binding Update accepted) in order to indicate to the Mobile Router that it accepted the Binding Update, set up the tunnel endpoint and the necessary forwarding information. If the Home Agent is configured not to support mobile routers, it sets the status code in the Binding Acknowledgement to '140' (Mobile Router Operation not permitted). If one or more prefixes received in the Binding Update are invalid and the Home Agent cannot setup forwarding for the prefixes, the Home Agent sets the status code in the Binding Acknowledgement to '141' (Invalid Prefix) in order to indicate this to the Mobile Router. If the Mobile Router is not authorized to use this Home Address to forward packets for one or more prefixes that are present in the Binding Update, the Home Agent sets the status code in the Binding Acknowledgement to '142' (Not Authorized for Prefix) in order to indicate this. The Home Agent sets the status code in the Binding Acknowledgement to '143' (Mobile Network Prefix information unavailable) in order Devarapalli, et al. Expires 21 December 2003 [Page 22] Internet Draft Nemo Basic Support 21 June 2003 to indicate the Mobile Router that the received Home Address in the Binding Update does not match any prefix entry in the pre-configured prefix table. This is used in the Implicit case where the Mobile Router does not include any prefix information in the Binding Update. 6.7. Mobile Network Prefix De-Registration The Mobile Router de-registers with the Home Agent by sending a Binding Update with the lifetime set to zero. This Binding Update MUST be secured as described in [3]. When the Home Agent successfully processes the de-registration BU, it deletes the Binding Cache Entry for the Mobile Router's Home Address and stops proxying the Home Address. This is described in detail in the Mobile IPv6 specification [1]. In addition, the Home Agent also removes the bi-directional tunnel and stops forwarding packets to the Mobile Network. Devarapalli, et al. Expires 21 December 2003 [Page 23] Internet Draft Nemo Basic Support 21 June 2003 7. Extended Home Network With MIPv6, the Home Network is generally a physical network interconnecting the Home Agents, and the Mobile Nodes that are at Home. The Network Mobility concept introduces the extended Home Network that aggregates the Home Network(s) and the Mobile Network(s) in a single, shorter prefix. For most practical situations, it is expected that: - There is a single Home Network and multiple Mobile Networks - The Home Network and Mobile Network prefixes are tailored to allow for IPv6 Stateless Address Autoconfiguration with typical interface identifier length for the type of interface. - The prefix length of the extended Home Network is shorter than the Home Network and the Mobile Network prefixes, since it is an aggregation. - The Home Agents collectively advertise the extended Home Network aggregation only. The dichotomy of the extended Home Network is kept within the Home Agents and the Mobile Nodes, as opposed to advertised by means of routing protocols to other parties. The Home Network is configured on a physical interface as defined in MIPv6. A Mobile Router may own a Home Address that is built out of the Home Network prefix and use it for Nemo registration and to come back Home. In that case, the Home Network Prefix and prefix length are used in the Binding Update. A Mobile Router owns one or several Mobile Networks. It may form extended Home Addresses from the prefixes of its Mobile Network(s) and register them to the Home Agent using the extended Home Network prefix and prefix length. An extended Home Address may be used for only one registration that it identifies uniquely, regardless of the Home Agent, as for normal Home Addresses. An extended Home Network may be configured on a virtual or a physical interface of the Home Agent. It is partitioned in Mobile Networks and Home Networks. If the extended Home Network is configured on a physical Network, a Mobile Router that registers using an extended Home Address may come back home by: - Autoconfiguring a Care-of Address from the Home Network and providing Proxy Neighbor Discovery for its Mobile Network Prefixes or Devarapalli, et al. Expires 21 December 2003 [Page 24] Internet Draft Nemo Basic Support 21 June 2003 - Attaching directly by its Ingress Link if it has only one of them. Multihoming, and in particular the associated coordination of the Home Agents, is out of the scope of this document. Yet, this specification does not prevent that: - More than one Mobile Network may be connected to a Mobile Router - A Mobile Network Prefix may be shared between Mobile Routers and registered by some of them - An Mobile Network Prefix may be registered several times to several Home Agents using different (extended) Home Addresses for each registration. This description is open to a: - Mobile Router autoconfiguring one or several extended Home Address to carry out many registrations in parallel. It owns the full prefix so it may use any address in there for a MNLP based registration, and several of them for multihoming. - Mobile Node autoconfiguring one or several Care-of Addresses from the Mobile Network Prefix - Mobile Host autoconfiguring one or several Home Addresses from the Home Network. Mobile Nodes' Home Addresses may still be configured manually from the Home Network Prefix as described in Mobile IPv6. Devarapalli, et al. Expires 21 December 2003 [Page 25] Internet Draft Nemo Basic Support 21 June 2003 8. Support for Dynamic Routing Protocols In the solution described so far, forwarding to the Mobile Network at the Home Agent is set up when the Home Agent receives a Binding Update from the Mobile Router. An alternative to this is for the Home Agent and the Mobile Router to run a intra-doamin routing protocol like RIPng [6] and OSPF [7] through the bi-directional tunnel. The Mobile Router can continue running the same routing protocol that it was running when it was attached to the home link. This feature is very useful when the Mobile Network is large with multiple subnets containing different IPv6 prefixes. Routing changes in the Mobile Network are propagated to the Home Agent quickly. Routing changes in the home link are also propogated to the Mobile Router very quickly. When the Mobile Router is attached to the home link, it runs a routing protocol by sending routing updates through its egress interface. When the mobile router moves and attaches to a visited network, it MUST stop sending routing updates on the interface with which it attaches to the visited link. This is very important so that IPv6 prefixes specific to the Mobile Network do not leak into the visited network. The Mobile Router then starts sending routing protocol messages through the bi-directional tunnel towards the Home Agent. Most routing protocols use link local addresses as source addresses for the routing information messages. The Mobile Router is allowed to use link local addresses for the inner IPv6 header of an encapsulated packet. But these messages after decapsulation MUST NOT be forwarded to another link by either the Mobile Router or the Home Agent. When the Home Agent receives the encapsulated routing protocol message, it processes the inner packets and updates its routing table accordingly. The next hop information in these routing entries is filled with the Mobile Router's link local address with the outgoing interface set to the bi-directional tunnel. Similary, the Home Agent also sends routing updates through the bi-directional tunnel to the Mobile Router. The Mobile Router processes these routing protocol messages and updates its routing table. For all routes advertised by the Home Agent, the Mobile Router sets the outgoing interface to the bi-directional tunnel to the Home Agent. The tunneled routing messages MUST be authenticated and encrypted by using IPsec ESP [5] in tunnel mode. Devarapalli, et al. Expires 21 December 2003 [Page 26] Internet Draft Nemo Basic Support 21 June 2003 9. Use of IPsec to protect the Signaling Messages The use of IPsec to protect to Mobile IPv6 signaling messages is described in detail in HA-MN IPsec specification [3]. This document does not require any changes or anything more that what is described in the HA-MN IPsec specification. Devarapalli, et al. Expires 21 December 2003 [Page 27] Internet Draft Nemo Basic Support 21 June 2003 10. Security Considerations The Home Agent has to verify that packets received through the bi-directional tunnel belong to the Mobile Network. This check is necessary in order to prevent nodes from using the Home Agent to launch attacks that would have otherwise been prevented by ingress filtering. The source address of the outer IPv6 header MUST be set the Mobile Router's current Care-of address. The source address of the inner IPv6 header MUST belong to the Mobile Network Prefix owned by the Mobile Router. When the Mobile Router is running a dynamic routing protocol as described in Section 8, it injects routing update messages into the Home Link. The Home Agent MUST verify that the Mobile Router is allowed to send routing updates before processing the messages and propagating the routing information. Please refer to the Mobile IPv6 specification [1] for security considerations when the Mobile Router operates as a Mobile Host. 11. IANA Considerations This document defines two new Mobility Header Options. - Mobile Network Prefix Option - Mobile Network Prefix Length Option. These options are described in section 4.3 and section 4.4. The type values for these options need to assigned from the same space used by the mobility options defined in [1] 12. Contributors We would like to acknowledge Thierry Ernst, Miguel Catalina-Gallego, Christophe Janneteau, T.J. Kniveton, Hong-Yon Lach, Jari T. Malinen, Koshiro Mitsuya, Charles E. Perkins and Keisuke Uehara, for their work on earlier proposals for Network Mobility. This document inherits a lot of ideas from these earlier proposals. 13. Acknowledgements We also thank all members of the NEMO Working Group, and of the preceding MONET BoF for fruitful discussions on the mailing list and at IETF meetings. Devarapalli, et al. Expires 21 December 2003 [Page 28] Internet Draft Nemo Basic Support 21 June 2003 Tim Leinumeller for many insightful remarks and implementation aspects. Devarapalli, et al. Expires 21 December 2003 [Page 29] Internet Draft Nemo Basic Support 21 June 2003 References [1] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6 (work in progress). Internet Draft, IETF. draft-ietf-mobileip-ipv6-22.txt. May 2003. [2] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology (work in progress). Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt. May 2003. [3] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (work in progress). Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-05.txt May 2003. [4] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 Specification. RFC 2473, IETF. December 1998. [5] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2402, IETF. November 1998. [6] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080, IETF. January 1997. [7] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470, IETF. December 1999. [8] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460, IETF. December 1998. [9] T. Narten, E. Nordmark and W. Simpson. Neighbour Discovery for IP Version 6 (IPv6). RFC 2461, IETF. December 1998. [10] C. Perkins, ed. IP Mobility Support for IPv4. RFC 3344, IETF. August 2002. Devarapalli, et al. Expires 21 December 2003 [Page 30] Internet Draft Nemo Basic Support 21 June 2003 A. Examples of Operation This section tries to illustrate the NEMO protocol using a Mobile Router and a Mobile Node belonging to different administrative domains. The Mobile Router's mobile network consists of a Local Fixed Node (LFN) and a Local Fixed Router (LFR) [2]. The LFR has an access link to which other Mobile Nodes or Mobile Routers could attach to. Figure 1 depicts the scenario where both the Mobile Router and the Mobile Node are at home. +----+ +-------+ | MN | | HA_MN | +--+-+ 1:: +---+---+ 2+-------------+3 | | +-------+2 2:: +-------------------+ 3:: 2+-------+ | CN_MN |------| Internet |------| CN_MR | +-------+ +-------------------+ +-------+ 4:: | | 2+-------------+3 +--+-+ +---+---+ | MR | | HA_MR | +--+-+ +-------+ 5:: |1 ---------- 2| |3 +--+-+ +--+-+ | LFN| | LFR| +--+-+ +--+-+ 6:: |1 ---------- Figure 1: Mobile Router and Mobile Node at home. Devarapalli, et al. Expires 21 December 2003 [Page 31] Internet Draft Nemo Basic Support 21 June 2003 The Mobile Router then moves away from the home link and attaches to a visited link. This is shown in Figure 2. The Mobile Router sends a Binding Update to HA_MR when it attaches to a visited link and configures a Care-of Addres. HA_MR creates a binding cache entry for the Mobile Router's Home Address and also sets up forwarding for the prefixes on the mobile network. +----+ +-------+ | MN | | HA_MN | +--+-+ 1:: +---+---+ 2+-------------+3 | | +-------+2 2:: +-------------------+ 3:: 2+-------+ | CN_MN |------| Internet |------| CN_MR | +-------+ ++------------------+ +-------+ | 7:: 4:: | 4::2->7::2 | | 2+ +3 +--+-+ +---+---+ | MR | | HA_MR | 4::2->7::2 +--+-+ +-------+ 5::/prefixlen -> forward 5:: |1 to MR ---------- 6::/prefixlen -> forward 2| |3 to MR +--+-+ +--+-+ | LFN| | LFR| +--+-+ +--+-+ 6:: |1 ---------- Figure 2: Mobile Router on a Visited Link. Devarapalli, et al. Expires 21 December 2003 [Page 32] Internet Draft Nemo Basic Support 21 June 2003 Figure 3 shows the Mobile Node moving away from its home link and attaching to the Mobile Router. The Mobile Node configures a Care-of Address from the prefix advertised on the mobile network and sends a Binding Update to its Home Agent (HA_MN) and its Correspondent Node (CN_MN). Both HA_MN and CN_MN create binding cache entries for the Mobile Node's Home Address. +-------+ | HA_MN | 1::2->6::2 1:: +---+---+ ---------|3 | | +-------+2 2:: +-------------------+ 3:: 2+-------+ | CN_MN |------| Internet |------| CN_MR | +-------+ ++------------------+ +-------+ 3::2->6::2 | 7:: 4:: | 4::2->7::2 | | 2+ +3 +--+-+ +---+---+ | MR | | HA_MR | 4::2->7::2 +--+-+ +-------+ 5::/prefixlen -> forward 5:: |1 to MR ---------- 6::/prefixlen -> forward 2| |3 to MR +--+-+ +--+-+ | LFN| | LFR| +--+-+ +--+-+ 6:: |1 --------+- |2 +--+-+ | MN | +----+ Figure 3: Mobile Node attached to Mobile Router on a Visited Link Devarapalli, et al. Expires 21 December 2003 [Page 33] Internet Draft Nemo Basic Support 21 June 2003 Authors Addresses Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: vijay.devarapalli@nokia.com Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 Japan Email: ryuji@sfc.wide.ad.jp Alexandru Petrescu Motorola Labs Espace Technologique de St Aubin Gif-sur-Yvette 91193 France Email: Alexandru.Petrescu@motorola.com Pascal Thubert Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 France Email: pthubert@cisco.com Devarapalli, et al. Expires 21 December 2003 [Page 34] Internet Draft Nemo Basic Support 21 June 2003 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 assignees. 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 RFC Editor function is currently provided by the Internet Society. Devarapalli, et al. Expires 21 December 2003 [Page 35]