NEMO Working Group F. Z. Yousaf Internet Draft C. Wietfeld Expires: January 2009 A. Tigyo Communication Networks Institute, Dortmund University of Technology July 30, 2008 Nest Route Optimization for NEMO (NERON) draft-yousaf-ietf-nemo-neron-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering 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 This Internet-Draft will expire on January 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract IETF has proposed MIPv6 based Network Mobility (NEMO) Basic Support protocol that handles the mobility management of IPv6 based mobile networks. However the NEMO protocol has severe performance limitations and does not specify the route optimization method for Yousaf & Wietfeld Expires January 30, 2009 [Page 1] Internet-Draft NERON July 2008 mobile networks and does not take into account the operational and functional complexities involving nested mobile networks. In this draft we present NEst Route Optimization for NEMO (NERON) protocol, a light weight, efficient and scalable approach that aims at enabling nodes behind nested mobile networks to use optimized communication paths with zero tunneling overhead and minimum end-to- end delay, irrespective of the depth of the nest, with minimum but manageable changes to the base MIPv6 and IPv6 Neighbor Discovery protocols and without introducing any new network entities. Table of Contents 1. Requirements notation..........................................3 2. Introduction...................................................3 3. Terminology....................................................4 4. Assumptions....................................................4 5. Problem Statement..............................................5 6. Design Goals...................................................6 7. Network Mobility Background....................................6 7.1. General Handover Process in Mobile Networks...............6 7.2. Non-optimum Packet Routing in Mobile Networks.............7 8. NERON Protocol Overview........................................8 8.1. Nest Formation and Mobile Network Gateway Discovery.......8 8.1.1. Loop Avoidance and Nest Depth Identification.........9 8.2. Route Notification.......................................10 8.3. Return Routability and Binding Registration..............11 9. Data Communication between MNN and CN.........................11 9.1. When CN Is Part of the Internet Infrastructure...........12 9.1.1. MNN Sending Packets to CN...........................12 9.1.2. CN Sending Packets to MNN...........................12 9.2. When CN and MNN Share the Same Mobile Network Domain.....13 10. Data Structures..............................................13 11. Message Formats..............................................14 11.1. Type-3 Routing Header...................................14 11.2. Modified Neighbor Discovery Messages and Options........16 11.2.1. Modified MIPv6 Router Advertisement Message........16 11.2.2. Modified Neighbor Advertisement Message............17 11.2.3. Modified Prefix Information Option.................18 11.3. New Message Options.....................................19 11.3.1. Mobile Network Gateway Option......................19 11.3.2. Route Notification Option..........................21 11.3.3. Nest Gate Option...................................23 12. Security Considerations......................................23 13. IANA Considerations..........................................23 14. Conclusions..................................................24 15. Acknowledgments..............................................24 Yousaf, Wietfeld Expires January 30, 2009 [Page 2] Internet-Draft NERON July 2008 16. References...................................................24 Author's Addresses...............................................25 Intellectual Property Statement..................................26 Disclaimer of Validity...........................................26 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 2. Introduction IETF's Network Mobility (NEMO) Basic Support Protocol [2] proposes the mobility management protocol for Mobile Networks which enables Mobile Network Nodes (MNN) inside the Mobile Network behind a Mobile Router (MR) to communicate with Correspondent Node CN(s) via a bidirectional tunnel maintained between the MR and its Home Agent (HA). Thus [2] doesn't redress and specify the route optimization (RO) solution that would enable direct communication between MNNs and CN(s) over optimized paths without involving any tunnels and bypassing the HA(s) associated with MR(s). The performance issues linked to the absence of any RO solution in mobile networks, which has been detailed in [3], becomes more conspicuous in case of nested mobile networks and gets compounded with every incremental increase in the nest depth. RFC 4889 [4] gives a very detailed account of the solution space of RO in Mobile networks and nested mobile networks by encompassing the different issues and scenarios referenced in [3]. There are solutions available that address either complete or part of the RO issue in nested Mobile networks but the common goal of any solution is to enable a RO solution which fulfills the requirements specified in [3] and [4]. However a close review of the proposed solutions, which would be referenced in the subsequent sections, reveals that the RO solution for nested mobile networks has the tendency of being over-engineered by over estimating the architectural scope of a mobile network, which in fact is limited within very closed and well defined confines of mobile entities such as cars, busses, trains, aircrafts, ships, etc. In such an environment the size of the Mobile network can not exceed beyond a certain constant limit (in terms of nodes) and degree of complexity (in terms of network architecture). A conservative Yousaf, Wietfeld Expires January 30, 2009 [Page 3] Internet-Draft NERON July 2008 estimate is that the probability of the nest depth to increase beyond a nest depth of 3 is very small. With this perspective in consideration, we propose Nest Route Optimization in NEMO (NERON) which is a light weight, efficient and scaleable RO solution for nested, non-nested and intra-NEMO mobile network scenarios and is designed within the boundaries defined in [3] and [4]. NERON is light weight in the sense that it does not introduce any new network entities and utilizes the available MIPv6 [5] and IPv6 Neighbor Discovery [6] protocol messages with minimum but manageable changes to them. 3. Terminology This document assumes that the reader is familiar with the mobility related terms defined in [5] and [7], and particularly with the network mobility terms introduced in [8]. The user must also be familiar with the terms defined in IPv6 Neighbor Discovery Protocol as defined in [6]. The following term is used additionally in this document. NEMO Prefix: The on-link prefix(es) advertised by the nested MRs as part of the Route Notification Process. 4. Assumptions There are RO solutions proposed in the context of nested mobile networks like MANEMO [9], ONEMO [10], MIRON [11] being more prominent. However a close review of the proposed solutions reveal that the RO solution has the tendency of being over-engineered by over estimating the architectural and functional scope of a mobile network, which in fact is limited within very closed and well defined confines of mobile entities such as cars, busses, trains, aircrafts, ships, etc. In such an environment the size of a mob network can not exceed beyond a certain constant limit (in terms of nodes) and degree of complexity (in terms of network architecture). A conservative estimate is that the probability of the nest depth to increase beyond a nest depth of 3 is very small. Also MIPv6 is now becoming a standard part of an OS kernel, such as Linux, and therefore it is safe to assume that in the very near future all nodes will have inherent support for MIPv6. Yousaf, Wietfeld Expires January 30, 2009 [Page 4] Internet-Draft NERON July 2008 With the above considerations in perspective the following assumptions are made while proposing the NERON solution: o The mobile network environment is limited in terms of size and number of users. o The MNN are assumed to be fixed LFN with no mobility support. Although NERON operation makes provision for MIPv6 capable VMN to travel as part of the mobile network however its position in the domain of the mobile network is depth independent. o The Correspondent Node (CN) is MIPv6 aware. This eliminates the need to introduce Correspondent Router (CR). o The CN is a fixed node, either in the Internet or sharing the same mobile network domain as the corresponding MNN. o The root-MR (rMR) will connect to the infrastructure network with a single egress interface. o The visiting MR will connect to the rMR forming a hierarchical nested architecture rather than a flat configuration. 5. Problem Statement The current NBSP [2] does not specify any RO mechanism and the problems and issues related to the absence of any RO mechanism with reference to mobile networks is listed in detail in [3]. According to [3], all data packets to and from the MNNs are tunneled through the HA of its MR i.e., over sub-optimal routes, even though a shorter and more optimized path may exist between the MNN and the CN. In case of nested mobile networks, these data packets then traverse multiple HAs with multiple levels of encapsulation. This would limit the overall performance and give rise to various performance which are summarized as follows: 1. Longer routes leading to increased delay and additional infrastructure load posing crucial problems for real-time applications and video streaming. 2. Increased susceptibility to link failures due to the packets traversing longer routes. 3. Increase packet overhead due to tunneling and maintaining tunnels within tunnels thus reducing the overall bandwidth efficiency. Yousaf, Wietfeld Expires January 30, 2009 [Page 5] Internet-Draft NERON July 2008 4. Increased processing delay due to successive encapsulation and decapsulation. 5. Increased probability of packet fragmentation due to successive tunneling of packets leading towards non-negligible packet loss. 6. Design Goals The design goal of NERON is to develop a light-weight and scalable RO solution by utilizing and leveraging the existing MIPv6 [5] and IPv6 Neighbor Discovery [6] protocols with minimum but manageable changes to them and without introducing any additional network entity and/or third party support protocol(s). The solution space of NERON encompasses all the major considerations and requirements defined in [4] and summarized as follows: o To enable the intercommunication between MNN and corresponding CN(s) over optimized paths without requiring to traverse any and all HA(s) irrespective of the nest depth. o Enable direct intra-communication between MNN and CN when CN may exist within the same domain of the mobile network as the MNN. o To completely eliminate the possibility of establishing any tunnels between any network entities involved in the infrastructure. o Reuse existing protocols such as MIPv6 and IPv6 Neighbor Discovery protocol with minimum changes to the existing messages and network infrastructure. o Abstain from introducing any new network entities or changes that would require drastic changes in the network infrastructure. 7. Network Mobility Background In this section we give a summarized account of how NEMO protocol manages the handover of mobile networks and how data packets are routed between the CN(s) and MNN(s). 7.1. General Handover Process in Mobile Networks According to [2], a mobile network consists of several MNNs attached to a MR's ingress interface whereas the MR connects the mobile network to the Internet via its egress interface. The MNNs are unaware of the mobility of the mobile network. Yousaf, Wietfeld Expires January 30, 2009 [Page 6] Internet-Draft NERON July 2008 When a mobile network is at its home network, it is identified and reachable via its Home Address (HoA), which is auto-configured [12] or assigned [13] on the MR's egress interface based on the Home Agent's (HA) advertised address prefix on the home link. The prefix advertised on the MR's ingress interface inside the mobile network is called a Mobile Network Prefix (MNP), which is delegated from the subnet owned by the HA, and the MNNs configure their addresses with the advertised MNP. When the Mobile Network is away from its home network, the MR configures a Care-of-Address (CoA) on its egress interface only according to the prefix advertised by the access router (AR) of the visit network infrastructure whereas the address of the MR's ingress interfaces, and hence those of the MNNs remain unchanged. The MR will register its CoA with its HA through an exchange of binding update (BU) and binding acknowledgment (BA) message pair, and the HA will in turn create a binding between the MR's CoA and its respective MNP(s) with the MR's Home Address (HoA), all conveyed by the BU message, in a locally maintained cache called Binding Cache (BC). After a successful binding, a bi-directional tunnel is created between the HA and the MR. A packet addressed to a MNN is first routed to its HA, which will intercept the packet and tunnel it to the CoA of the MR, which in turn will decapsulate the outer header of the packet and forward it to the MNN. In the reverse direction the MR will encapsulate the packet originating from the MNN and tunnels it to its respective HA, which in turn will decapsulate the outer header of the packet and forward it to the destination based on Internet routing mechanism. 7.2. Non-optimum Packet Routing in Mobile Networks The basic task of NEMO Basic Support Protocol (NBSP) is to utilize the MIPv6 protocol operation and integrate it into the realm of mobile networks, however this introduces severe performance limitation in terms of sub-optimal communication paths for packets of the MNN as it has to traverse, in both directions, the MR's HA via a bidirectional tunnel established between the MR and its corresponding HA. This sub-optimal routing of packets, also called 'triangular routing', is due to the fact that [2] does not specify any RO mechanism; a mechanism enabling MNN(s) and CN(s) to communicate directly over optimum routes as determined by generic Internet routing protocols and bypassing any or all HAs minimizing the possibility of establishing and maintaining tunnel(s) between the MNN and CN(s). The problems associated with sub-optimal routing have already been highlighted in section 5 above. This problem gets compounded when other MRs (and hence mobile networks) attach behind another MR (or mobile network) in a hierarchical fashion forming a larger mobile network. In such a Yousaf, Wietfeld Expires January 30, 2009 [Page 7] Internet-Draft NERON July 2008 cluster of mobile networks a MR that has connectivity to an infrastructure AR is called a root-MR (rMR) and the MR behind the rMR is called a nest-MR (nMR), and such a topology is termed as ``nest topology'' and the network is called nested mobile network [8]. Although NBSP does not prevent the formation of such a nested architecture but, in the absence of any RO mechanism, when a CN communicates with a MNN located behind a nMR. (where . is the depth of the nest and rMR, which acts as a gateway to the nested mobile network, is considered at depth .=0), the packets of the MNN will traverse over (.+1) HAs (i.e., through the HAs of all the upper level mobile networks present in the nest chain) thereby undergoing (.+1) encapsulations/decapsulations in both directions. This problem gets exacerbated especially in the case of two inter-communicating MNNs belonging to different nMRs but located within the same rMR domain. In such a case the number of encapsulations undergone by a packet will double than the case when the MNN is communicating with a Correspondent Node (CN) outside its mobile network domain. This is also called "pin-ball" routing problem [4]. 8. NERON Protocol Overview The NERON protocol proposes a MIPv6 based RO solution which is independent of the nest depth. The NERON process, similar to other RO solutions such as MANEMO [9] and ONEMO [10], consists of the following three essential steps namely; o Nest formation and mobile network gateway discovery. o Route notification within the rMR nested domain. o Return Routability and binding registration. The proceeding sub-sections will elaborate the above three essential operational steps. 8.1. Nest Formation and Mobile Network Gateway Discovery It is important for a visit MR (VMR) to detect the presence of a Mobile Network domain behind which it can nest and acquire not only the address of the rMR's egress interface, as this will be the gateway for all the nMRs nested behind rMR, but also compute its position in terms of the depth in the the nested architecture. When a mobile network, such as a PAN, enters the domain of another mobile network, it has to first detect and connect to the rMR as nMR. The nMR will be able to distinguish a MR from a regular AR based Yousaf, Wietfeld Expires January 30, 2009 [Page 8] Internet-Draft NERON July 2008 on the status of the R-flag carried by the periodically advertised RA message. When set it will indicate the AR is acting as a MR in which case the RA's are advertised periodically over the ingress interface(s) only and received and processed by the egress interface(s). The RA MUST also carry the new Mobile Network Gateway (MNG) option (see section 11.3.1) which conveys the rMR's depth in the nest (which is 0 by default) and also the address assigned to its egress interface (which can be a HoA or CoA, depending on the rMR location). The receiving nMR will cache the rMR's egress interface address and the incremented value of the "depth" parameter in its two-field Nest Gate Table (NGT) (see section 10). A non-zero Nest-Position value in the local NGT implies that the MR is nested behind a MR as nMR at a depth indicated by the Nest- Position value (see section 10). The nMR in turn MUST include the entry of its local NGT in the appropriate fields of the MNG option of the RA messages advertised periodically over its respective ingress interface(s). In other words the nMR will relay the assigned address of the rMR's egress interface to other nMRs deep inside the nest which in turn will relay it further deeper in the nest using the RA message and this relaying will continue till the last MR in the nest. All nMRs will also store an incremented value of the received Depth field (D-Field) value in the MNG option indicating its depth and position in the nest. In this way all nMRs will not only compute their position in the nest but will also be informed of the rMR's egress interface address that will be stored by the nMRs in their respective NGT. 8.1.1. Loop Avoidance and Nest Depth Identification Since the egress interface of a MR will be able to listen to the RA messages advertised not only from its local ingress interface(s) but also by the ingress interface(s) of the nMR(s), there is a possibility of the MR to form loop either with itself or with its nMR. To achieve loop-less connectivity the MR will compare the advertised prefix(es) with its home prefix and also with the nest- depth value in the NGT. If the advertised "depth" value is greater than the value stored in the local NGT and/or if the advertised prefix matches the home prefix of the egress interface, then in such case(s) the MR will drop/ignore the RA and not attempt connection with the MR. NERON specifies that only the egress interface of the MR should configure CoA as it roams whereas the ingress interface(s) address(es) should remain the same as acquired at the home network. At the home network of a MR, both ingress and egress interface will configure addresses using the prefix of the home agent. Yousaf, Wietfeld Expires January 30, 2009 [Page 9] Internet-Draft NERON July 2008 In order to prevent against race condition i.e., in situation when both MRs will be advertising depth value of 0 in its MNG option, then this will be decided by the state of the P-flag in RANG option (See section 11.3.1 for details). In comparison to NERON, the MANEMO project follows the TD [14] protocol to achieve the above tasks but it uses a much larger and complex 32B Tree Information Option (TIO) with further 5 different sub-options (potentially increasing the size of TIO sub-option to an additional 34B) in its RA message. The extensive and complicated TIO sub-option not only accounts for large size RA messages but also accounts for complexity in terms of logic processing. In contrast NERON uses a 20B fixed size MNG sub-option accounting for smaller RA packets and straightforward processing of the RA message. A similar approach is adopted by ONEMO [10] but ONEMO does not specify how a MR will compute its position in the nest and how to ensure loop-less connectivity. The decision mechanism of the MR concerning preferred rMR is out-of- scope of this work and hence should rely on some decision algorithms. 8.2. Route Notification This is a crucial process that would furnish the routing tables of MRs, within a nested domain, with the information necessary to route data packets between CN and MNN irrespective of the depth of the MNN. After the VMR nests behind a rMR and updates its NGT, it will send an Unsolicited Neighbor Advertisement (UNA) message [6] over its egress interface with the Override flag (O-flag) set to 0. This UNA will convey the respective nMR's egress interface's link local address and respective MNPs embedded in the newly defined "Route Notification Option" (RNO) (see section 11.3.2). A MR upon receiving the UNA on one of its ingress interface will update its local routing table with the MNPs carried by the UNA and assign/specify the corresponding link local address carried by the same UNA message as the next hop address to reach the listed MNPs. If the receiving MR is a nMR (in case depth value listed in local NGT is not 0), it will relay the UNA to the next higher MR by replacing the previous nMR's link local address with the link local address of its own (the relaying MR) egress interface leaving the MNP entries untouched. The next higher MR upon receiving the UNA will add/update its routing table and relay it to the next higher MR as explained above. In this way the routing tables of all the MR will get updated with all the MNPs that are present in the nest and an appropriate Yousaf, Wietfeld Expires January 30, 2009 [Page 10] Internet-Draft NERON July 2008 next hop address will also be assigned for correct routing of the packets. A Relay flag (R-Flag) is added to the RNO which when set will indicate to the next higher MR to relay the MNP carried by the RNO to the next higher MR in the nest chain in case it is not a rMR. The UNA is transmitted on the egress interface(s) and received and processed on the ingress interface(s). In contrast to a much simpler and smaller RNO, NINA [15] uses a new NA message termed as Network In Node Advertisement (NINA) to relay the MNPs up the tree. NINA is a NA message with a 32B Network In Node Option (NINO) as compared to 24B Route Noticiation option which is less complex than NINO. Also NINA/NINO depends on the Tree Discovery protocol [14] before it can relay the MNPs. 8.3. Return Routability and Binding Registration As proposed in [2] and specified in MIRON [11], NERON uses the MIPv6 based Return Routability (RR) procedure [5] but unlike MIRON its performance is independent of the nest depth. In NERON, the MR of the MNN will perform home registration with its HA as specified in [2]. After successful home registration, the MR will perform MIPv6 specified RR procedure on behalf of the MNN as specified in [11]. After a successful RR procedure with the CN, the nMR, on behalf of the MNN, will send a BU carrying the rMR's address (accessed from its NGT) in the newly defined Nest Gate Option (NGO) (see section 11.3.3). It should be noted that the BU is triggered every time the entry in the NGT changes indicating a handover of the Mobile Network. The CN upon receiving the BU, will process it as specified in [2] and [11] and additionally it will extract the address carried in the NGO and records the rMR's address in its Binding Cache (BC) entry. The CN will send a Binding Acknowledgment thus completing the RO and correspondent registration process. 9. Data Communication between MNN and CN After the mobile network has handed over and RO process completes, the packets between MNN and CN will then flow over optimized paths bypassing any and/or all HA(s) without any tunneling over head. NERON address the following two scenarios in terms of data communication between CN and MNN: o When CN is part of the Internet infrastructure. Yousaf, Wietfeld Expires January 30, 2009 [Page 11] Internet-Draft NERON July 2008 o When CN and MNN share the same mobile network domain. It should be noted that the CN in both cases are assumed to be non- mobile i.e., a standard host in the Internet or an LFN in the mobile network (see section 4). 9.1. When CN Is Part of the Internet Infrastructure The communication flow between CN and MNN over optimized path is as follows: 9.1.1. MNN Sending Packets to CN When a MR receives a packet from its MNN destined to the CN, it will replace the source address of the IPv6 header with the CoA assigned to its egress interface and put the address of the MNN in the Home Address Destination option [5]. All the other nMRs on the path to the rMR will simply forward this packet until it reaches the rMR. The rMR will then forward the packet normally to the CN and hence the packet arrives at the CN with no encapsulation and via a direct optimized route bypassing the HAs. 9.1.2. CN Sending Packets to MNN When a CN wants to a send a packet to a nested MNN, it will first search its BC for a valid cached entry for the packet's destination address. If the packet's destination address is found listed in the BC, the CN will then check if a Nest Gate entry (see section 10) exists for the destination. If a valid Nest Gate address is present in the BC, the CN knows that the MNN resides inside a nested mobile network and composes the packet as follows; o The source address field in the IPv6 header is set to the CN address. o The destination address field in the IPv6 header is set to the Nest Gate address found in the BC entry. o The CoA of the nMR found in the BC entry corresponding to the MNN's destination prefix, and the MNN destination address are contained in the newly defined Type 3 Routing Header (T3RH) address vector (see section 11.1). The T3RH gets processed only by the destination router. When receiving the packet with a T3RH, the rMR replaces the destination address with the nMR's CoA found in the T3RH address vector. Since inside the nest routes have already been exchanged Yousaf, Wietfeld Expires January 30, 2009 [Page 12] Internet-Draft NERON July 2008 between the MRs as part of the route notification process (see section 8.2), the rMR, and the subsequent MRs nested behind the rMR, will route the packet to the destination nMR using standard routing algorithm. The destined nMR will then replace the packet's destination address with the address of the MNN carried inside the T3RH address vector and the packet eventually gets delivered to the MNN without any tunneling over head. 9.2. When CN and MNN Share the Same Mobile Network Domain If the MNN and CN are connected behind different MRs that are connected to the same nested mobile network, that is they share the same rMR domain, then without RO, the intercommunicated packets will leave the mobile network to be tunneled back into the same mobile network following a pinball route [3]. NERON solution inherently provides reachable destinations to all MRs inside the nest connected to the rMR by a combination of Route Notification process described in section 8.2 and by advertising off- link prefixes (NEMO prefixes), prefixes of other MRs inside the nest, received via the Route Notification process in the prefix information option of the RA message. When advertising the NEMO prefix in the prefix information option [6], both the On-link flag (L-Flag) and the Autonomous Address- Configuration Flag (A-Flag) MUST be set to zero while the newly defined Update flag (U-Flag) (see section 11.2.3) MUST be set. The combined status of these flags will indicate that the specified prefix MUST be used by MRs to update its local routing table with destination prefixes set to the received prefix and the next hop address set to the source address of the received RA message. This combined exchanged of Route Notification messages via UNA and and NEMO prefixes via unsolicited RA messages prevents against the pinball routing problem by enabling the MNN and CN to intercommunicate directly without having the packets leave the mobile network domain and thus dramatically reduce the packet round trip delay and packet overhead in terms of successive tunneling and de- tunneling. 10. Data Structures Mention the NGT and the small modification in the CN's BC. The NERON protocol defines a new Nest Gate Table (NGT) maintained by each MR. The NGT conceptual data structure consists of the following fields: Yousaf, Wietfeld Expires January 30, 2009 [Page 13] Internet-Draft NERON July 2008 o Nest Position: The position of the respective MR in terms of its depth inside the nested mobile network's nest hierarchy. The MR will calculate its position in the nest hierarchy by incrementing the value carried in the Depth field of the RA's "Mobile Network Gateway" Option (see section 11.3.1). o Mobile Network Gateway: The globally unique IPv6 address configured and assigned to the rMR's egress interface. The MR will update this field in the NGT from the information received in the RA's "Mobile Network Gateway" Option (see section 11.3.1). Besides NGT, NERON proposes to modify the binding cache of the CN [5] by adding the "Nest Gate" field which will contain the rMR's egress interface address received in the Nest Gate Option of the BU message (see section 11.3.3). 11. Message Formats The NERON protocol introduces a new routing header called a Type-3 Routing header (T3RH) and makes use of the existing MIPv6 [5] and IPv6 Neighbor Discovery protocol [6] with minimum but manageable modifications and new message sub-options. 11.1. Type-3 Routing Header NERON defines a new routing header variant, the Type 3 Routing Header (T3RH), to allow the packet to be routed directly from a CN to the MNN inside the nested mobile network without any tunneling overhead. This routing header type is restricted to carry two IPv6 addresses; the nMR's CoA (the address of the egress interface) and the associated MNN address. The rMR's egress interface address is inserted into the IPv6 Destination Address field. Once the packet arrives at the rMR's egress interface, it will swap the destination address of the IPv6 header with the nMR's CoA inside the T3RH and forward the packet inside the mobile network. The packet upon reaching the relevant nMR will then replace the MNN address in the IPv6 destination address field from the T3RH, and this is used as the final destination address for the packet. The nMR will remove the routing header and forward the packet to the required MNN. The T3RH is used instead of the Type 2 Routing Header [5] whenever the CN is sending data packets towards MNN that resides inside a mobile network. See section 9 to understand how CN determines whether the MNN is inside a mobile network or is connected to the Internet infrastructure. Yousaf, Wietfeld Expires January 30, 2009 [Page 14] Internet-Draft NERON July 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Hdr Ext Len = 4|Routing Type=3 |Segment Left=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + nested MR Care of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Node Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 : Type 3 Routing Header The type 3 routing header is shown in figure 1 and has the following format: Next Header 8-bit selector. Identifies the type of header immediately following the routing header. Uses the same values as the IPv6 Next Header field [16]. Hdr Ext Len 4 (8-bit unsigned integer). Length of the routing header in 8-octet units, not including the first 8 octets. Routing Type 3 (8-bit unsigned integer). Segments Left 1 (8-bit unsigned integer). Reserved Yousaf, Wietfeld Expires January 30, 2009 [Page 15] Internet-Draft NERON July 2008 32-bit reserved field. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Nested MR Care of Address The CoA of the nMR's egress interface. Mobile Network Node Address The IPv6 address of the MNN connected to the nMR's ingress interface. 11.2. Modified Neighbor Discovery Messages and Options NERON proposes minor modification to the MIPv6 specified router advertisement message [5], prefix information option and Neighbor Discovery message [6] with the addition of single flag bits. 11.2.1. Modified MIPv6 Router Advertisement Message The NERON protocol modifies the format of the MIPv6 specified router advertisement message [5] by the addition of a single flag bit to differentiate a MR from a regular infrastructure AR. 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Curr Hop Limit |M|O|H|R|Reserve| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+- Figure 2 : Modified RA Message This format represents the following changes over that originally specified for MIPv6: Mobile Router Flag (R) When set indicates that the advertising router is a MR and not a regular infrastructure AR. Yousaf, Wietfeld Expires January 30, 2009 [Page 16] Internet-Draft NERON July 2008 Reserved Reduced from a 5-bit field to a 4-bit field to account for the addition of the R-flag bit. Valid Options: Mobile Network Gateway Option Carries the global unicast IP address configured at the rMR's egress interface. This option MUST be included, when the R-flag is set. 11.2.2. Modified Neighbor Advertisement Message The NERON protocol modifies the format of the IPv6 Neighbor Discovery's neighbor advertisement message [6] by the addition of a single flag bit to differentiate a MR from a regular infrastructure AR. The MR will send unsolicited neighbor advertisement (UNA) to advertise the MNPs of the local and nested MRs up to the higher MR in the nest hierarchy/chain. The UNA is transmitted only on the egress interface and received and processed at the ingress interface. The receiving MR will update its local routing table by assigning the link local address as the next hop address to reach the address prefix(es) carried by the same UNA. 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Link Local Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+ Figure 3 : Modified Neighbor Advertisement Message Yousaf, Wietfeld Expires January 30, 2009 [Page 17] Internet-Draft NERON July 2008 This format represents the following changes over that originally specified in [6]: Mobile Router Flag (M) When set indicates that the advertising router is a MR and not a regular infrastructure AR. When M is set then the R flag MUST be set and the S and the O flag MUST be zero. Reserved Reduced from a 21-bit field to a 20-bit field to account for the addition of the M-flag bit. Link Local Address MUST include the link local address of the egress interface sending out the unsolicited NA when the M-flag is set. The receiving MR will use this address as the next hop address for the prefix(es) carried in the route notification option. Valid Options: Route Notification Option Carries the prefix of the MR's ingress interface. This option MUST be included, when the M-flag is set. The advertisement may carry multiple such options. 11.2.3. Modified Prefix Information Option The format of the modified prefix information option carried by the RA message is shown in figure 4. This format represents the following changes over that originally specified in [5]: Update Flag (U) When set indicates that the prefix option MUST be processed by the MR and that the advertised prefix is a NEMO prefix that MUST be used by the MR to update its local routing table and using the source IP address of the RA message as the next hop address to reach this prefix/address. Reserved Reduced from a 5-bit field to a 4-bit field to account for the addition of the U-flag bit. Yousaf, Wietfeld Expires January 30, 2009 [Page 18] Internet-Draft NERON July 2008 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 | Prefix Length |L|A|R|U| Res 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix (variable length) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 : Prefix Information Option 11.3. New Message Options NERON defines two new message sub-options. 11.3.1. Mobile Network Gateway Option This option is included in the router advertisement message advertised periodically by the MRs on their ingress interfaces. This option MUST be included whenever the R-flag is set. This message option carries the address configured on the rMR's egress interface and also notifies its position in terms of nest-depth. The receiving MR will compute its position in the nest by incrementing the depth value specified in this option. The format of the message is shown in figure 4. Yousaf, Wietfeld Expires January 30, 2009 [Page 19] Internet-Draft NERON July 2008 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 | Prefix Length |P| D |Reserve| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + root Mobile Router CoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 : Mobile Network Gateway Option Type To be assigned by IANA. Length 8-bit unsigned integer. Indicates length of the option field. Primary Flag (P) When set indicates that the MR is attached to a non- mobile infrastructure AR. This flag will eliminate the race condition that may occur when a MR enters the domain of another MR and both have the same Depth value. Depth Field (D) This 3-bit field indicates the position of the advertising MR in terms of nest depth. The rMR will always have a depth value of zero by default and incremented by 1 by the nMR (which receives this option) indicating the depth of its location. Prefix Length The prefix length indicates the number of significant bits of the rMR's CoA. This will enable a MIPv6 capable VMN to derive a topologically correct CoA for initiating its MIPv6 handover process. This option will allow MIPv6 enabled node to co-locate and operate from within the domain of a mobile network. Reserved Yousaf, Wietfeld Expires January 30, 2009 [Page 20] Internet-Draft NERON July 2008 4-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Root Mobile Router CoA The global unicast address assigned/configured on the egress interface of the root mobile router (rMR). It may be a HoA or a CoA depending on the location of the rMR. This value is stored by the receiving MR in its Nest Gate Table and is relayed down to the next MR in its respective RA message. This option enables all the MRs nested behind the same rMR get information about the rMR's CoA. 11.3.2. Route Notification Option This option MUST be carried by the unsolicited neighbor advertisement message whenever the M-flag is set. The MR will convey the MNP that may be local or received from a nMR in a similar option to the next higher MR. 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 = 3 | Prefix Length |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix (variable length) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 : Route Notification Option Type To be assigned by IANA. Length 3 (8-bit unsigned integer). The length of the option (including the type and length fields) in units of 8- octets. Yousaf, Wietfeld Expires January 30, 2009 [Page 21] Internet-Draft NERON July 2008 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Relay Flag (R) The R-flag when set would indicate that this prefix must be relayed to the next higher MR in the chain. The rMR MUST not relay it further up. Reserved 7-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid. Prefix An IP address or a prefix of an IP address. The prefix length field contains the number of valid leading bits in the prefix. Yousaf, Wietfeld Expires January 30, 2009 [Page 22] Internet-Draft NERON July 2008 11.3.3. Nest Gate Option This option MUST be carried by the BU message sent by the nMR on behalf of the LFN during correspondent registration. It carries the address of the mobile network gateway i.e., the address of the rMR's egress interface. After the successful completion of the return Routability procedure (see section 8.3), the rMR/nMR will search and acquire the rMR's egress interface address from its Nest Gate Table and include this address in the Nest Gate Option and append it to the BU. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Nest Gate Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 : Nest Gate Option The format of the Nest Gate option is shown in figure 6 and it is similar to the MIPv6 Alternate Care-of-Address option but with a different type. 12. Security Considerations NERON follows the security aspects defined in [5] and [2]. For packet transmission it uses the IPSec features of IPv6. Further security considerations are still under investigation. 13. IANA Considerations This document requires IANA to assign numbers to the Type value of the 3 message options namely; Nest Gate Option, Route Notification Option and Mobile Network Gateway Option. Yousaf, Wietfeld Expires January 30, 2009 [Page 23] Internet-Draft NERON July 2008 14. Conclusions NERON is a light weight scalable RO solution that is independent of the MNN depth in a nested mobile network and it utilizes the existing MIPv6 and Neighbor Discovery Protocol constructs with minor but manageable modifications to the existing messages. NERON does not introduce any new network entity and all the protocol complexity is limited within the scope of a MR. It tackles the issues described in [3] and encompasses the solution space prescribed in [4]. All of the above considerations makes NERON ideal for quick and early deployment. 15. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 16. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] NEMO RFC 3963: Devarapalli, V., Wakikawa, R. A. Petrescu, P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [3] RFC 4888: C. Ng, P. Thubert, M. Watari, F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, IETF, July 2007. [4] Thubert P., C. Ng., M. Watari, F. Zhao, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007. [5] MIPv6 RFC 3775 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [6] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007. [7] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [8] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, June 2004. [9] MAENMO Project. http://www.mobileip.jp/MANEMO/MANEMO.html. July 2008. Yousaf, Wietfeld Expires January 30, 2009 [Page 24] Internet-Draft NERON July 2008 [10] M. Watari et. al., "Routing Optimization for Nested Mobile Networks", IEICE Transaction on Communications, Volume E-89-B, No 10, October 2006. [11] C. Bernardo, M. Bagnulo, M. Calderon, "MIPv6 Route Optimization for Network Mobility (MIRON)", Internet Draft (Work in progress), January 2008. [12] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [13] R. Droms, et al, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [14] P. Thubert, C. Bontoux, M. Montavont, "Nested NEMO Tree Discovery", Internet Draft (Work in progress), July, 2007. [15] P. Thubert, R. Wakikawa, C. Bernardos, et. al., "Network In Node Advertisement", Internet Draft (Work in progress), July, 2007. [16] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Author's Addresses Faqir Zarrar Yousaf Communication Networks Institute Dortmund University of Technology Otto-Hahn-Str. 6, D-44227 Dortmund, Germany Email: faqir.yousaf@tu-dortmund.de Christian Wietfeld Communication Networks Institute Dortmund University of Technology Otto-Hahn-Str. 6, D-44227 Dortmund, Germany Email: christian.wietfeld@tu-dortmund.de Yousaf, Wietfeld Expires January 30, 2009 [Page 25] Internet-Draft NERON July 2008 Alain Tigyo Communication Networks Institute Dortmund University of Technology Otto-Hahn-Str. 6, D-44227 Dortmund, Germany Email: alain.tigyo@tu-dortmund.de Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). Yousaf, Wietfeld Expires January 30, 2009 [Page 26] Internet-Draft NERON July 2008 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Yousaf, Wietfeld Expires January 30, 2009 [Page 27]