INTERNET DRAFT Ryuji Wakikawa 18 Feb 2003 Keisuke Uehara Koshiro Mitsuya Thierry Ernst Keio University and WIDE Basic Network Mobility Support draft-wakikawa-nemo-basic-00.txt Status of This Memo This document is a submission to the Network Mobility Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the nemo@nal.motlabs.com mailing list. Distribution of this memo is unlimited. 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 draft proposes a solution for Basic Network Support. It proposes Mobile IPv6 extensions as advocated by the NEMO working group. Our solution differs from Prefix Scope Binding Update (PSBU) which was originally proposed before the NEMO working group was set up. Our draft however uses mechanisms similar to those of PSBU, such as ``Prefix binding'' and ``Searching mechanism of prefix binding''. The main difference relies on the management of the permanent address of the MR, which is assigned to the ingress interface, and not to the egress interface. R. Wakikawa et.al. Expires 18 Aug 2003 [Page i]
Internet Draft Basic NEMO Support 18 Feb 2003 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 2 3. Protocol Overview 3 4. Mobile IPv6 extension 5 4.1. Binding Cache and Binding Update Management . . . . . . . 5 4.2. Binding Update . . . . . . . . . . . . . . . . . . . . . 6 4.3. Binding Acknowledgment . . . . . . . . . . . . . . . . . 6 4.4. Prefix Sub-option . . . . . . . . . . . . . . . . . . . . 7 4.5. Extended Use of Home Address Option . . . . . . . . . . . 7 4.6. Search Algorithm of Prefix Binding in Binding Cache . . . 8 5. Mobile Router Operation 9 5.1. Packet Processing . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Forwarding Packets to the Internet . . . . . . . 9 5.1.2. Receiving Packets from HA . . . . . . . . . . . . 9 5.1.3. MR acting as an end-node . . . . . . . . . . . . 9 5.2. Binding Processing . . . . . . . . . . . . . . . . . . . 10 5.2.1. Sending Binding Updates . . . . . . . . . . . . . 10 5.2.2. Receiving Binding Acknowledgments . . . . . . . . 10 5.3. Returning to HA link . . . . . . . . . . . . . . . . . . 11 5.4. Types of Tunneled Packets to HA . . . . . . . . . . . . . 12 6. Home Agent Operation 12 6.1. Processing Bindings . . . . . . . . . . . . . . . . . . . 12 6.1.1. Receiving Binding Updates . . . . . . . . . . . . 12 6.1.2. Sending Binding Acknowledgments . . . . . . . . . 13 6.2. Packet Processing . . . . . . . . . . . . . . . . . . . . 14 6.2.1. Sending Packets to MR . . . . . . . . . . . . . . 14 6.2.2. Receiving Packets from MR . . . . . . . . . . . . 14 6.3. Types of Tunneled Packets to MR . . . . . . . . . . . . . 15 7. Security Overview 15 8. Multicast Support 17 9. Mobile IPv6 Compatibility 17 R. Wakikawa et.al. Expires 18 Aug 2003 [Page ii]
Internet Draft Basic NEMO Support 18 Feb 2003 10. Nested Mobility 18 10.1. Visiting MN Attached to Mobile Network . . . . . . . . . 18 10.2. MR Attached to Mobile Network . . . . . . . . . . . . . . 18 Acknowledgments 18 Appendices 19 A. Specification Comparison with WG requirements 19 References 19 Authors' Addresses 21 1. Introduction The proposed protocol is designed as an extension to Mobile IPv6. All the requirements for a basic NEMO solution are described in [6]. The solution for basic network mobility support is to set up a bi-directional tunnel between the MR and its HA. This protocol establishes the bi-directional tunnel by binding operation of Mobile IPv6. This draft extends the usage of home address option, binding update option, and binding management and defines a prefix sub-option for binding update message. This draft also extends the definition of binding to manage a various prefix length for a home address. Details regarding the modifications to existing Mobile IPv6 will be mentioned later in this document. A similar approach was first proposed as PSBU [7]. PSBU proposed the notion of prefix binding. The difference from PSBU is the management of MR's home address. This draft need not to assign a home address which is different from a mobile network prefix. MR has still a permanent address, but is the address of the ingress interface named on the mobile router address instead of the address of the egress interface on the same link as the HA. This difference makes possible to communicate in various network topologies such as nested mobility and multiple HA links which are like home link of MR. It also achieves to authorize and authenticate mobile network prefix with MR as described in section 7. In addition, MR's host mobility by means of its home address is managed as a part of network mobility. Therefore, it gives several optimization to reduce the size of packets as described in section 5.1.3 and section 5.3. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 1]
Internet Draft Basic NEMO Support 18 Feb 2003 2. Terminology 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]. Most of terms are defined in [8]. Mobile Router Address (MR-A) The permanent address generated by a delegated mobile network prefix and statically assigned to the ingress interface. Mobile Router Care-of Address (MR-CoA) The address which is dynamically assigned to the egress interface of MR on the foreign link. Prefix Binding The prefix binding associates between a mobile network prefix and a MR-CoA. The prefix binding is stored in the binding cache as well as a binding of Mobile IPv6[11]. The prefix binding is first proposed in PSBU, but our prefix binding store the information in the following two way: - If a prefix binding is searched with the registered prefix length, it becomes the binding for a mobile network prefix - If a prefix binding is searched with 128-bit prefix length as general Mobile IPv6, it becomes the binding of the MR. In this case, the MR is treated as a MN. Home Agent (HA) HA MUST be able to delegate a prefix to a MR by any delegation protocols. How to delegate prefix is currently out of scope in this draft, but any updates of prefix delegation for mobile network must be employed on this protocol. This will be clarified in a forthcoming revision of the draft. The HA MUST NOT have an address belonging to a mobile network prefix, but it MUST be addressed by any IPv6 global address. For dynamic configuration, a MR obtain a HA address during prefix delegation operations. MR MUST have a HA configured either statically or dynamically in the Internet. The HA MUST advertise route information R. Wakikawa et.al. Expires 18 Aug 2003 [Page 2]
Internet Draft Basic NEMO Support 18 Feb 2003 of mobile network prefix by any routing protocols such as OSPF6 [3], RIPng [15], BGP [14], etc. and it MUST be identified as a gateway of the prefix in the Internet topology. HA link The HA link is not the link for a mobile network prefix, but it is the link of the HA. The prefix advertised on the HA link MUST be different from the mobile network prefix. The prefix MUST be managed by HA. MR MAY return to the HA link. HA can manage several HA links if needed. There is no difference in the operations between single HA link and multiple HA links. Prefix Sub-option A mobility header sub-option is used to carry a prefix length of a mobile network. This sub-option is valid only in Binding Update (BU). 3. Protocol Overview This section shows the protocol outline. The figure 1 is a typical network configuration of a mobile network. MR is attached to a visiting network in this figure. Protocol operations is split into below steps. 1. MR acquisition of Mobile Network Prefix: At the beginning, MR MUST have a mobile network prefix delegated from its HA. Dynamic HA discovery can be used to discover the HA address by MR. MR can also have a statically configured HA before starting any operations. 2. MR configuration of MR-A to egress interfaces: The MR, carrying a mobile network attaching to the Internet, has a home address (MR-A) assigned to its ingress interface. The MR-A is generated by the mobile network prefix (ex. mobile network prefix and MR's EUI-64 identifier). The MR can be identified with MR-A from the Internet regardless of its location in the Internet. 3. MR configuration of MR-CoA to ingress interfaces: When the MR moves to a different network, the MR obtains a topologically correct global address as a MR-CoA at the egress interface. 4. MR sending BU to HA: The MR sends a BU to its HA to create a prefix binding instead of host binding. The BU MUST contain a home address option containing MR-A and a prefix sub-option with the length of its mobile network prefix. The prefix sub-option R. Wakikawa et.al. Expires 18 Aug 2003 [Page 3]
Internet Draft Basic NEMO Support 18 Feb 2003 CN CN CN CN CN CN ___|__|___|___|___|___|___ | ___|_____________________ | | | Internet | |________________________| __|_ __|__ <-- HA Address 3ffe:306:1130::eui64 | | | | Prefix Binding | AR | | HA | MR-A/64<->MR-CoA |____| |_____| | ____|______ HA Link (3ffe:306:1130:1::/64) _______|________ foreign link 3ffe:306:5555:7777::/64 | | __|<-- MR-CoA 3ffe:306:5555:7777::mr_eui64 | | | MR | Mobile Network Prefix 3ffe:306:1130:200::/64 |____| |<-- MR-A 3ffe:306:1130:200::mr_eui64 _____|_________ | | __|__ __|__ | | | | | MNN | | MNN | |_____| |_____| 3ffe:306:1130:200::eui64 Figure 1: Example of Mobile Network Configuration is defined in section 4.4. If the BU is successfully processed by the HA, the MR creates a tunnel to the HA as shown in [11]. 5. HA caching of Prefix Binding: When receiving the BU, the HA caches prefix binding. The HA retrieves the mobile network prefix from the MR-A with the mobile network prefix length in the prefix sub-option. The MR-A is stored at the home address option in the BU. The MR-CoA is stored in a source address field of IPv6 header. This prefix binding can also be treated as a Mobile IPv6 binding of the MR. 6. HA tunneling packets addressed to Mobile Network: The HA intercepts and tunnels all packets destined to the MR's mobile R. Wakikawa et.al. Expires 18 Aug 2003 [Page 4]
Internet Draft Basic NEMO Support 18 Feb 2003 network prefix by IP-in-IP encapsulation. The HA operation of tunneling packets is same as Mobile IPv6 except for binding search. Since the MR registers the prefix binding containing the prefix length, the HA MUST use address longest-match algorithm to scan the binding cache database. First HA MUST search the binding with 128-bit prefix length for intercepted packets. If HA finds a binding, it MUST tunnel packets as Mobile IPv6 operation. Otherwise, the HA MUST compare the destination address of intercepted packets with the MR's mobile network prefix. If the HA finds a prefix binding, the HA MUST tunnel packets to the registering MR-CoA. 7. Sending packet from MNN to a CN in the global Internet: When a MNN in the mobile network sends packets to the Internet, the MR intercepts the packets and encapsulates them to the HA. The source address of encapsulated packets is the MR-CoA to bypass ingress filtering. MR MUST NOT insert the home address option as general Mobile IPv6, since falsification of MNNs' packets on intermediate nodes like MR should be avoided from security considerations. Although encapsulation of packets [4] add additional IPv6 header, it does not change the orignal packets. 8. Sending packet from MR to HA or a CN in the global Internet: When the MR sends packets to its registered HA as a MN, it is RECOMMENDED to use a home address option storing the MR-A. These operation is the same as Mobile IPv6. This keeps the additional packet's size smaller than the additional size of tunneled packets. e.x. home address option (20byte) is smaller than IPv6 header (40 bytes). The HA is RECOMMENDED to reply packets with a routing header type 2. The MR MAY tunnel packets to the HA instead of using a home address option, and vice versa. If the destination is CNs, the MR MUST always tunnel packets via HA. 9. MR management of routing information inside mobile network The routing management inside a mobile network is not discussed in this draft, but any protocol such as OSPF6, RIPng, or any MANET protocol [18] can be used. 4. Mobile IPv6 extension 4.1. Binding Cache and Binding Update Management This draft requires to have an additional item for binding cache and binding update structures defined in Mobile IPv6, which is R. Wakikawa et.al. Expires 18 Aug 2003 [Page 5]
Internet Draft Basic NEMO Support 18 Feb 2003 - Prefix Length The prefix length of a mobile network prefix. The mobile network prefix is identified by MR-A and the prefix length. MR MUST keep prefix length in its binding update list database. HA MUST register the prefix length in its binding cache if the prefix length is available in the BU. HA MUST use the prefix length to search a binding cache database if needed. 4.2. Binding Update When MR registers its prefix binding to its HA, the MR MUST set 'N' flag and include the prefix sub-option. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|N| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network Mobility Flag (N) Network Mobility Flag: used for a prefix binding registration. This flag defines that this BU contains a prefix sub-option and is for a mobile network. Reserved Reserved field is reduced to 11 bits. 4.3. Binding Acknowledgment Since the 'N' flag is valid only for the HA (i.e. home registration), HA which receives BU with 'N' flag MUST reply BA as described in section 6.1.2. The receiver also MUST reply BA with correspondent error number if it encounters some error while processing BU and its sub-option. This document assigns new status codes for mobile network prefix registration. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 6]
Internet Draft Basic NEMO Support 18 Feb 2003 2 Successfully registered a mobile network prefix 3 Successfully registered a mobile network prefix at HA link 140 Invalid Prefix Length 4.4. Prefix Sub-option Prefix sub-option MAY only be appended in a BU message. Prefix length field contains the length of a mobile network prefix. Receiving nodes MUST use this prefix length whenever they refer to binding cache database. 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 = 2 | Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (alignment requirement: 2n) Type TBD Length 2 The length of the option (excluding the type and length fields) in units of 8 octets. Prefix Length The 8 bit IPv6 prefix length of a mobile network prefix reserved The 8 bit reserved field. MUST be set to zero. 4.5. Extended Use of Home Address Option In Mobile IPv6 [11], Mobile Node (MN) uses one of its Care-of Addresses (CoAs) as the source address in the packets' IPv6 header R. Wakikawa et.al. Expires 18 Aug 2003 [Page 7]
Internet Draft Basic NEMO Support 18 Feb 2003 and puts the home address in a home address option. CNs substitute the MN's home address with the CoA when processing the packet. A Home Address option is used in a packet sent by the MN to inform the recipient of the fact that packets are of the MN's home address. MR only uses home address option for BU packets and MUST NOT use it for any packets other than control packets (i.e. BU) and its originated packets. Insertion of the home address option on MR alters orignal packets. Modifying MNNs' packets on MR should be avoided for security considerations. Therefore, for outgoing data packets from MNN, MR encapsulate packets with MR-CoA as an IPv6 source address to bypass ingress filtering. Although encapsulation of packets add additional IPv6 header, it does not change orignal packets. If MR originates packets to its registering HA as a MN, it SHOULD use the home address option as MN of Mobile IPv6. 4.6. Search Algorithm of Prefix Binding in Binding Cache The similar search algorithm was first proposed in PSBU [7]. Prefix binding enables HA to find an appropriate prefix binding for packets destined to mobile network. Mobile IPv6 always searches a binding cache entry with 128-bit prefix length. Therefore, it can not pick a prefix binding for packets destined to MNNs, because addresses between MR (MR-A) and MNNs are different in 128-bit prefix length. Thus, the binding cache MUST be searched by using a mobile network prefix (a prefix length part of MR-A). The prefix between MR (MR-A) and MNNs are the same. The efficient algorithm for this situation is the address longest-match. The sequence of this search is as shown below: 1 HA searches a binding cache database with 128-bit prefix length as Mobile IPv6. 2 HA searches a binding cache database with a registered prefix length in a prefix binding only if a prefix length is available (i.e. the binding is a prefix binding). When packets are destined to the MR-A itself (not MNN), the algorithm enables HA to find a prefix binding as a Mobile IPv6 binding for the MR-A. This is important when there are multiple MRs in a mobile network and MRs advertised a same mobile network prefix. If HA search a binding cache database only by the second algorithm, HA can not determine which MR is the destination node of the packets. It is because the mobile network prefix of each MR-A is the same value. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 8]
Internet Draft Basic NEMO Support 18 Feb 2003 5. Mobile Router Operation 5.1. Packet Processing 5.1.1. Forwarding Packets to the Internet When MR receives packet from MNNs on its ingress interface and intended to a CN in the global Internet, it MUSTS tunnels these packets to its HA. Outer IP header MUST be constructed as follows whenever the MR tunnels packets. - The source IP address of the outer IP header MUST be the MR-CoA - The destination IP address of the outer IP header MUST be the HA address. 5.1.2. Receiving Packets from HA While away from home, MR will receive packets from correspondent nodes tunneled via HA. Whenever the MR receives tunneled packets destined to its mobile network prefix from the HA, the MR MUST check the following sequences. - The destination address of the outer IP header MUST be MR-CoA. - The source address of the outer IP header MUST be the address of the HA currently registering MR's binding. If tunneled packets do not satisfy above conditions, the MR SHOULD NOT route these packets to the final destination (i.e. The destination node of inner IPv6 packets (MNN)). 5.1.3. MR acting as an end-node If MR needs to communicate with a correspondent node with its MR-A, it MUST send packets through bidirectional tunneling via HA described in section 5.1.1. Instead, if the destination of MR's packet is the MR's current registering HA, MR SHOULD follow general Mobile IPv6 operation except for the operations of ``returning home'' and ``Route Optimization''. Packets from the MR SHOULD be carried with a home address option set to the MR-A. Packets to the MR SHOULD be routed by a routing header type 2 set to the MR-CoA. The HA MUST verify the MR-A with registereing bindings. If the HA can not find the binding for the R. Wakikawa et.al. Expires 18 Aug 2003 [Page 9]
Internet Draft Basic NEMO Support 18 Feb 2003 MR-A, it MUST discard these packets and SHOULD send Binding Error described in the Mobile IPv6 specification. The MR SHOULD also accept tunneled packets originally destined to MR-A from the HA, and the HA SHOULD also accept tunneled packets originally destined to the HA from the MR-A. Operation of ''returning home'' is described in the section 5.3. MR MUST NOT start return routability operation for route optimization. All the packets MUST be tunneled thorough HA (i.e. redirectional tunneling). 5.2. Binding Processing 5.2.1. Sending Binding Updates If prefix length is available in the binding update list, MR MUST send BU with a prefix sub-option. The operation of sending BUs to HA is same as Mobile IPv6 except for following procedure. - 'N' bit MUST be set in BU - 'L' bit MUST NOT be set in BU - 'H' bit MUST be set in BU if the BU is for home registration. - A prefix sub-option MUST be contained in the BU. In the prefix sub-option, MR MUST set the length of its mobile network prefix. MR MUST NOT send BU which do not match the above procedure. 5.2.2. Receiving Binding Acknowledgments BA MUST be protected by IPsec transport mode. If the BA is not protected by appropriate IPsec, MR MUST silently discard the BA. Other procedures to verify BA is described in [11] In the Mobile IPv6 specification, if the status field is less than '128', it indicates successful registration of its binding. On the other hand, this draft requires status value either '2' or '3' for successful registration. MR MUST establish a tunnel with HA after successful registration and starts tunneling packets from the mobile network. If the value is not '2' and '3', the MR SHOULD retry to send BU for its mobile network prefix or MAY stop sending BU. If the status field is '3', the MR is back to HA link. The MR should follow the operation described in section 5.3. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 10]
Internet Draft Basic NEMO Support 18 Feb 2003 If the status field indicates that the BU was rejected, the MR SHOULD NOT send BUs to this destination. 5.3. Returning to HA link CN CN CN CN CN CN ___|__|___|___|___|___|___ | ___|_____________________ | | | Internet | |________________________| __|_ __|__ <-- HA Address 3ffe:306:1130::eui64 | | | | Prefix Binding | AR | | HA | MR-A/64<->MR-CoA* |____| |_____| (*MR-CoA is on-link address for HA) | _________|______ HA Link (3ffe:306:1130:1::/64) | | __|<-- MR-CoA 3ffe:306:1130:1::mr_eui64 | | | MR | Mobile Network Prefix 3ffe:306:1130:200::/64 |____| |<-- MR-A 3ffe:306:1130:200::mr_eui64 _____|_________ | | __|__ __|__ | | | | | MNN | | MNN | |_____| |_____| 3ffe:306:1130:200::eui64 Figure 2: Mobile Network attached to the HA link When MR returns to the link of its HA, the MR will obtain MR-CoA from HA's router advertisement messages. The MR-CoA is different from the mobile network prefix. Therefore, the MR MUST send BU like any other foreign link. This is because the HA needs to know the exact HA link where the MR has attached to. The MR detects the returning to HA link by receiving BA with the status code '3' from the HA. On the HA link, MR becomes on-link with the HA. Therefore the MR SHOULD route packets directly to the HA. The MR MAY receive packets directly route from the HA without any IP-in-IP encapsulation. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 11]
Internet Draft Basic NEMO Support 18 Feb 2003 The MR MUST accept these packets and route them correctly to a destination of packets. The MR SHOULD route packets from MNN to the HA without encapsulation. 5.4. Types of Tunneled Packets to HA MR MUST determine whether packets should be tunneled to HA or not, according to the following ruleset. - Global Scoped Packets sent by MNN If packets are sent by MNN with global scope and are addressed to hosts out of mobile network, MR MUST tunnel these packets to HA. - Link Local Scoped Packets in a mobile network MR MUST NOT tunnel any link-local scoped packets inside mobile network such as Neighbor Discovery Protocol (NDP) [16] packets and packets destined to all node multicast address. - Site Local Scoped Packets in a mobile network This draft currently does not consider site local scoped packets. Therefore, MR MUST NOT tunnel these packets and MUST route them only inside its mobile network. - Routing Messages of Mobile Network Prefix MR MAY tunnel any routing messages of its mobile network prefix. - Multicast Routing Message MR MUST tunnel all control messages of multicast routing protocols [9] [17] to HA. - Multicast Packets MR MUST tunnel multicast routing packets destined to a multicast address with global scope as described in section 8 If MR received tunneled packets which does not satisfy the ruleset described in section 6.3, it MUST silently discard these packets. 6. Home Agent Operation 6.1. Processing Bindings 6.1.1. Receiving Binding Updates BU MUST be protected by IPsec transport mode described in the section 7. Otherwise, HA MUST silently discard the BU. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 12]
Internet Draft Basic NEMO Support 18 Feb 2003 Verification of BU is the same as Mobile IPv6 except for following procedure. - If `N' bit is set in BU, Prefix sub-option MUST be present in the option field. Otherwise, the HA MUST discard the BU and return BA with status code set to '140' (Invalid Prefix Length). - If 'N' bit is set and 'L' bit is also set in BU, the HA MUST discard the BU and returns BA with status code set to '129' (Administratively prohibited). - If the ``Prefix Length'' of the prefix sub-option is equal to '128', the HA MUST discard the BU and returns BA with status code set to '140' (Invalid Prefix Length). - If the ``Prefix Length'' of the prefix sub-option is greater than '128', the HA MUST discard the BU and returns BA with status code set to '140' (Invalid Prefix Length). - If 'N' bit is set and 'H' bit is also set in BU, the HA MUST register the prefix binding as home registration and MUST return BA with status code set to '2'. - If the prefix binding is successfully registered and MR-CoA is generated by one of the HA's managed prefix, the HA MUST return BA with status code set to '3' to indicate returning the HA link. If HA successfully processes BU and registers a prefix binding for the requesting MR, the HA MUST establish a tunnel with the MR. After the registration, the HA MUST intercept packets destined to the mobile network and MUST forward these packets to the MR by IP-in-IP encapsulation. Since the HA is identified as a gateway of the mobile network prefix in the Internet topology, the HA receives these packets routed to itself. 6.1.2. Sending Binding Acknowledgments Operation procedure of sending BA is same as the Mobile IPv6 specification except for following. MR-A is treated as a home address. IF the status code is '140', HA MUST NOT use a prefix binding for the destination address of BA and MUST NOT use a routing header type 2 for BA. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 13]
Internet Draft Basic NEMO Support 18 Feb 2003 6.2. Packet Processing 6.2.1. Sending Packets to MR While MR is away from HA link, HA intercepts packets destined to the registered mobile network prefix. It MUST route packets to the registered MR. Thus, the HA tunnels packets to registered MR-CoA by IP-in-IP encapsulation. Outer IP header MUST be constructed as follows whenever the HA tunnels packets to the MR. - The source IP address of the outer IP header MUST be the HA address. - The destination IP address of the outer IP header MUST be the MR-CoA registered in the prefix binding. If packets do not satisfy above conditions, the MR SHOULD NOT route tunneled packets to the final destination (i.e. destination node of inner IPv6 packets). When MR is attached to a HA link, on the other hand, the HA SHOULD route packets to the mobile network according to general IP routing. The HA MAY NOT have exact routing entries for the mobile network prefix, but it knows the next-hop address of the mobile network prefix from the registered prefix binding. If the MR-CoA is configured by one of the HA's prefix, the MR-CoA becomes on-link at HA link. The HA should route packets to the next-hop address (MR-CoA) of the registered prefix binding. 6.2.2. Receiving Packets from MR While MR is away from HA link, HA receives packets tunneled to the HA from the MR. Whenever the HA receives tunneled packets from the MR, the HA MUST perform following common sequence. - The destination address of the outer IP header MUST be the HA address. - The source address of the outer IP header MUST be the MR-CoA which is registered in the prefix binding. If packets do not satisfy above conditions, the HA SHOULD NOT route tunneled packets to the final destination (i.e. destination node of inner IPv6 packets). R. Wakikawa et.al. Expires 18 Aug 2003 [Page 14]
Internet Draft Basic NEMO Support 18 Feb 2003 If the MR is located at the HA link, it will route packets without IP-in-IP encapsulation. The HA MUST verify MR's availability at its HA link. The HA compares the MR-CoA with HA's managing prefixes. If the MR-CoA is active at one of the HA link, the HA MUST route packets to the destination of packets. Otherwise, the HA MUST silently discard these packets. These packets may not be originated from the mobile network, because the owner of the mobile network prefix (MR) is not located at the HA link. 6.3. Types of Tunneled Packets to MR HA MUST determine whether packets are tunneled to MR or not, according to the following ruleset. - Global Scoped Packets destined to a mobile network If HA received packets destined to a mobile network prefix, the HA MUST tunnel this packet to the MR. - Routing Messages HA MAY tunnel any routing information obtained by routing protocols. While away from HA link, MR MUST NOT accept any routing messages tunneled by the HA. Also, the MR SHOULD NOT accept any routing messages to update its routing table except for default routes at a visiting link. - Multicast Routing Message HA MUST tunnel all control messages of multicast routing protocols [9] [17] to MR. - Multicast Packets HA MUST tunnel multicast packets destined to multicast listers in mobile network according to multicast routing table. If HA received tunneled packets which do not satisfy the ruleset of tunneled packets described in section 5.4, it MUST silently discard these packets. 7. Security Overview BU and Binding Acknowledgment (BA) are protected by IPsec transport mode [12] [13] like Mobile IPv6 [1]. Since this draft uses MR-A as a home address of MR, BU MUST be protected by using MR-A. MR-A is generated by a mobile network prefix, thus HA can authenticate MR and also authorize the mobile network prefix by IPsec transport mode. The establishment of Security Association (SA) by MR-A prevents a malicious MR to send BUs for other MR's mobile network prefix R. Wakikawa et.al. Expires 18 Aug 2003 [Page 15]
Internet Draft Basic NEMO Support 18 Feb 2003 to the specified HA. MR is RECOMMENDED to use ESP mode to give confidentiality to BU by encryption of BU. IPsec tunnel operation for HoTI and HoT is not needed in this draft, because route optimization is out of scope in Basic NEMO Support. IKE [10] is currently not supported. Following example can be applied to set up Security Association between MR and HA. The format of description is defined in section 4.1 of [1]. Security Association on MR is set up manually as follows: MR SPD OUT: - IF source = MR-A & destination = HA & proto = MH THEN USE SA1 MR SPD IN: - IF source = HA & destination = MR-A & proto = MH THEN USE SA2 MR SAD: - SA1(OUT, spi_a, HA, ESP, TRANSPORT): source = MR-A & destination = HA & proto = MH - SA2(IN, spi_b, MR-A, ESP, TRANSPORT): source = HA & destination = MR-A & proto = MH HA MUST NOT set up Security Association for MR before delegating a mobile network prefix to the MR. Security Association on HA is set up manually as follows: HA SPD OUT: - IF source = HA & destination = MR-A & proto = MH THEN USE SA2 HA SPD IN: - IF source = MR-A & destination = HA & proto = MH THEN USE SA1 MR SAD: - SA2(IN, spi_b, MR-A, ESP, TRANSPORT): source = HA & destination = MR-A & proto = MH R. Wakikawa et.al. Expires 18 Aug 2003 [Page 16]
Internet Draft Basic NEMO Support 18 Feb 2003 - SA1(OUT, spi_a, HA, ESP, TRANSPORT): source = MR-A & destination = HA & proto = MH To replace home address with MR-A, steps of processing IPsec calculation is same as section 5.1, 5.2, 5.3, 5.4 of [1]. 8. Multicast Support If a mobile network needs to support multicast, MR SHOULD be capable of operating Multicast Listener Discovery (MLD) [5]. The MR SHOULD know which multicast groups MNNs are currently joining. Also, the MR MUST tunnel packets destined to a multicast address via HA. The MR MUST run a multicast routing protocol, because the MR needs to route multicast packets to the upper multicast router which is the HA. Thus, the HA MUST run a multicast routing protocol in order to exchange multicast routing information from MR. HA SHOULD also be capable of routing multicast packets. The HA routes multicast routing messages from MR and tunnels appropriate multicast packets to MR if there are multicast listers in mobile network. If MR supports multicast, it MUST determine which multicast data packets to forward via the tunnel between HA. The MR operates this depending on address scope as follows. - If multicast packet is addressed to a multicast address with link-local scope, the MR MUST NOT tunnel them to the HA and MUST silently discard them. - If multicast packet is addressed to a multicast address with site-local scope, the MR SHOULD NOT tunnel them to the HA and MUST silently discard them. - If multicast packet is destined to a multicast address with global scope, the MU MUST tunnel them to the HA. If the MR receives tunneled multicast packets from the HA, it MUST route this multicast packets to listers of this multicast group in the mobile network. 9. Mobile IPv6 Compatibility This protocol is fully compatible with Mobile IPv6 without any modifications. MR sends BU only to HA, and MUST NOT send BU to other nodes. Even if Mobile IPv6 CN receives BU from MR, it MUST silently discard the BU. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 17]
Internet Draft Basic NEMO Support 18 Feb 2003 10. Nested Mobility 10.1. Visiting MN Attached to Mobile Network When Visiting MN (VMN) attaches to a mobile network, it obtains a CoA from MR's router advertisements. This address can be used as the general CoA defined in [11]. The VMN sends BU to its HA to register the CoA. Any additional operation is not needed to the VMN. Incoming packets from CN and outgoing packets from the VMN are tunneled between the MR and the MR's HA despite the Mobile IPv6 route optimization. Return Routability procedure can be used in this draft without any modifications. The VMN sends HoT and receives HoT via its HA though the bi-directional tunnel to the MR's HA. The VMN also sends CoTI and receives CoT thorough the bi-directional tunnel. Then, the VMN sends BU with Binding Authorization Data sub-option thorough the bi-directional tunnel. Outgoing packets to CN are route optimized by home address option, but is tunneled to the MR's HA first. Incoming packets are tunneled via the MR's and are routed to the VMN by routing header type 2 option. Packets bypass the VMN's HA in each direction. 10.2. MR Attached to Mobile Network When MR attaches to another mobile network, it obtains a MR-CoA named after the mobile network prefix. This address can be used as the general MR-CoA. The MR sends BU to its HA to register the MR-CoA. Any additional operation is not needed to the MR. Incoming packets to sub-NEMO can be routed to the sub-MR's MR-CoA by double tunneling both via parent-MR's HA and via sub-MR's HA. Outgoing packets from sub-NEMO are routed to a destination by bidirectional tunneling both via sub-MR's HA and via parent-MR's HA. The operation does not differ if there are more nested levels. Acknowledgments The authors would like to thank Masafumi Watari, Susumu Koshiba and InternetCAR group at KEIO University for their comments. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 18]
Internet Draft Basic NEMO Support 18 Feb 2003 A. Specification Comparison with WG requirements This section lists the possible issues compared to WG requirements. This protocol meets the requirements which are not listed in this section. These requirements are proposed in NEMO WG [6]. R12: ``The solution MUST function for multi-homed mobile networks. More precisely:'' R12.1: ``The solution MUST support mobile networks with multiple MRs,'' R12.2: ``The solution MUST support MR with multiple interfaces,'' R12.3: ``The solution must support MR with multiple global addresses on an egress interface.'' R12.2 and R12.3 is achieved by the same operation of Mobile IPv6. See section 11.5.3 of the Mobile IPv6 specification. R12.3 is not discussed in detail in this draft now. we need more consideration. R15: ``The solution MUST ensure transparent continuation of routing and management operations over the bi-directional tunnel when the MR is away from home. (this includes e.g. routing protocols, router renumbering, DHCPv6, etc)'' The solution meets the requirement of transparent continuation of routing, but router renumbering and DHCPv6 need more consideration. References [1] J. Arkko, V. Devarapalli, and F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (draft-ietf-mobileip-mipv6-ha-ipsec-02). Internet Draft, Internet Engineering Task Force, January 2003. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [3] R. Coltun, D. Ferguson, and J. Moy. OSPF for IPv6. Request for Comments (Proposed Standard) 2740, Internet Engineering Task Force, December 1999. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 19]
Internet Draft Basic NEMO Support 18 Feb 2003 [4] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 Specification. Request for Comments (Proposed Standard) 2473, Internet Engineering Task Force, December 1998. [5] S. Deering, W. Fenner, and B. Haberman. Multicast Listener Discovery (MLD) for IPv6. Request for Comments (Proposed Standard) 2710, Internet Engineering Task Force, October 1999. [6] T. Ernst. Network Mobility Support Requirements (draft-ietf-nemo-requirements-00). Internet Draft, Internet Engineering Task Force, February 2003. [7] T. Ernst and et al. Mobile Networks Support in Mobile IPv6 (draft-ernst-mobileip-v6-network-03). Internet Draft, Internet Engineering Task Force, March 2002. [8] T. Ernst and et al. Network Mobility Support Terminology (draft-ernst-monet-terminology-01). Internet Draft, Internet Engineering Task Force, November 2002. [9] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol specification. Request for Comments (Experimental) 2362, Internet Engineering Task Force, June 1998. [10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). Request for Comments (Proposed Standard) 2409, Internet Engineering Task Force, November 1998. [11] D. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6 (draft-ietf-mobileip-ipv6-20). Internet Draft, Internet Engineering Task Force, January 2003. [12] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [13] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). Request for Comments (Proposed Standard) 2406, Internet Engineering Task Force, November 1998. [14] K. Lougheed and Y. Rekhter. Border Gateway Protocol (BGP). Request for Comments (Experimental) 1105, Internet Engineering Task Force, June 1989. [15] G. Malkin and R. Minnear. RIPng for IPv6. Request for Comments (Proposed Standard) 2080, Internet Engineering Task Force, January 1997. R. Wakikawa et.al. Expires 18 Aug 2003 [Page 20]
Internet Draft Basic NEMO Support 18 Feb 2003 [16] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (ipv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [17] D. Waitzman, C. Partridge, and S. E. Deering. Distance Vector Multicast Routing Protocol. Request for Comments (Experimental) 1075, Internet Engineering Task Force, November 1988. [18] R. Wakikawa, J. Malinen, C. Perkins, A. Nilsson, and A. Tuominen. Global Connectivity for IPv6 Mobile Ad Hoc Networks (draft-wakikawa-manet-globalv6-02). Internet Draft, Internet Engineering Task Force, November 2002. Authors' Addresses Ryuji Wakikawa Koshiro Mitsuya Keio University and WIDE Keio University and WIDE 5322 Endo Fujisawa Kanagawa 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN 252-8520 JAPAN Phone: +81-466-49-1394 Phone: +81-466-49-1394 Fax: +81-466-49-1395 Fax: +81-466-49-1395 EMail: ryuji@sfc.wide.ad.jp EMail: mitsuya@sfc.wide.ad.jp Keisuke Uehara Thierry Ernst KEIO University and WIDE Keio University and WIDE 5322 Endo Fujisawa Kanagawa 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN 252-8520 JAPAN Phone: +81-466-49-1394 Phone: +81-466-49-1394 Fax: +81-466-49-1395 Fax: +81-466-49-1395 EMail: kei@wide.ad.jp EMail: ernst@sfc.wide.ad.jp R. Wakikawa et.al. Expires 18 Aug 2003 [Page 21]