INTERNET-DRAFT Thierry Ernst, WIDE and INRIA Alexis Olivereau, Motorola Labs Paris Ludovic Bellier, INRIA Claude Castelluccia, INRIA Hong-Yon Lach, Motorola Labs Paris March 2002 Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates) draft-ernst-mobileip-v6-network-03.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 draft addresses the problems of routing datagrams to nodes located behind the mobile router (MR) that connects a mobile network (MONET) to the Internet, in IPv6. Mobile IPv6 [MIPv6], the solution to support host mobility, is unable to support an entire network that changes its point of attachment. We show, by means of an experiment, that the Home Agent fails in redirecting packets to nodes behind the MR, and that direct routing can not be performed either. It is thus provided Mobile IPv6 extensions to support simple cases of MONETs. A Prefix Scope Binding Update is an enhanced Mobile IPv6 Binding Update which associates a careof-address (CoA) with a prefix instead of a single address. Ernst & Olivereau Expires September 2002 [Page 1] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 Table of Contents Status of This Memo Abstract 1. Introduction 2. Terminology and Assumptions 2.1. Terminology 2.3. Assumptions 3. Why can't Mobile IPv6 support MONETs ? 3.1. Review of Mobile IP and MONETs 3.2. Experimentation 3.2.1. Test Bed 3.2.1. Registration with the Home Agent 3.2.2. First experiment: Communication between CN and MR 3.2.3. Second experiment: Communication between CN and LFN1 3.3. Conclusion 4. Mobile IPv6 Extensions to Support MONETs 4.1. Packet format of the Binding Update 4.1.1. New Binding Update Option format 4.1.2. MONET Prefix Sub-Option 4.2. Cache Management 4.2.1. Binding Cache Entries 4.2.2. Searching the Binding Cache Entries 4.3. Extended Mobile IPv6 protocol Operation 4.3.1. Correspondent Node Operation 4.3.2. Home Agent Operation 4.3.3. MR Operation 5. Security Issues 5.1. Authentication 5.2. Authorization 5.3. Prefix Ownership 6. Changes since last draft Acknowledgments References Author's Addresses Ernst & Olivereau Expires September 2002 [Page 2] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 1. Introduction The purpose of traditional mobility support is to provide continuous Internet connectivity to mobile hosts (host mobility support). In contrast, network mobility support is concerned with situations where an entire network (composed by one or more subnets) dynamically changes its point of attachment to the Internet and thus its reachability in the topology. We shall refer to such a network as a mobile network (MONET). Cases of MONETs include networks attached to people (PANs) and networks of sensors deployed in aircrafts, ships, trains, busses, cars, etc. Potential scenarios are exhibited in [TERMINOLOGY] and [SCOPE]. Mobile IPv4 [MIPv4] and Mobile IPv6 [MIPv6] are solutions for host mobility support in IPv4 and IPv6 [IPv6] respectively. Although it is claimed that Mobile IPv4 could support MONETs equally as single mobile nodes ([MIPv4] section 4.5, [Perkins98] section 5.12, [Solomon98] section 11.2), we argue that this is not true for Mobile IPv6. Indeed, we have carefully studied Mobile IPv6's ability for supporting MONETs, and we came to the conclusion that some modifications are needed to support them. As we show, the Home Agent (HA) fails in redirecting packets intended to nodes behind the mobile router (MR) which connects the MONET to the Internet. As a result from this, communication cannot be established between nodes behind the MR and nodes in the Internet. Some implementations that do not strictly follows [MIPv6] may interpret it in a way that would allow the HA to redirect packets to nodes behind the MR, but we advocate that is surely leading to misinterpretation and pitfalls. Thus, we advocate that MONETs should be taken into account explicitly. We also advocate that nodes behind the MR MUST NOT take part in the MONET's mobility management as a result of the MR changing its point of attachment. We therefore propose to extend Mobile IPv6 with "Prefix Scope Binding Updates" as a means to provide continuous Internet connectivity for both the MR and nodes behind it, in a simple, easy, optimal and transparent way. It is assumed that all nodes in the MONET share a common prefix (MONET Prefix) and that the careof-address (CoA) belongs to the MR. A Prefix Scope Binding Update is an enhanced Binding Update that associates a CoA to a prefix instead of a single address. A node receiving such a Prefix Scope Binding Update is able to route any packet that shows this prefix in the destination field via the MR's CoA, therefore insuring permanent Internet connectivity and direct routing to all nodes in the MONET. In order to keep things simple, this draft does not address specific issues related with nested mobility, and multi-homing. We only Ernst & Olivereau Expires September 2002 [Page 3] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 consider LFNs (Local Fixed Nodes) behind the MR. This document assumes the reader is familiar with the terminology defined in [TERMINOLOGY] and [MIPv6], while reading [SCOPE, REQUI-1, REQUI-2, REQUI-3] is recommended. More information may be found on the MONET web page and mailing list [WEB-MONET]. The material presented in this document is mostly taken from [Ernst01]. 2. Terminology and Assumptions 2.1. Terminology ____ | | | CN | |____| ___|____________________ | | | | | Internet | | | |________________________| __|_ __|_ ____ | | Access | | | | Home | R2 | Router | R1 | | HA | Agent |____| |____| |____| _____|________|____ home __|_ link | | | MR | Mobile Router |____| _________|_______ internal __|___ __|___ link | | | | | LFN2 | | LFN1 | Local Fixed Nodes |______| |______| Figure 1: MONET attached to its home link The following terms are as defined in [MIPv6]: o Home Agent (HA) o home address o careof-address (CoA) o Mobile Node (MN) Ernst & Olivereau Expires September 2002 [Page 4] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 o home link o foreign link ____ | | | CN | |____| ___|____________________ | | | | | Internet | | | |________________________| __|_ __|_ ____ | | | | | | Home | R2 | | R1 | | HA | Agent |____| |____| |____| _______|__ foreign __|________|____ home __|_ link | link | | | MR | Mobile Router |____| _____|_________ internal __|__ __|__ link | | | | | LFN | | LFN | |_____| |_____| Figure 2: MONET attached to a foreign link The following terms peculiar to MONETs are defined in [TERMINOLOGY]: o MONET (mobile network) o MR (mobile router) o Node behind MR o LFN (Local Fixed Node) o LMN (Local Mobile Node) o VMN (Visiting Mobile Node) o Mobile Network Prefix o ingress interface Ernst & Olivereau Expires September 2002 [Page 5] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 o egress interface Figure 1 illustrates a MONET attached to its home link. In figure 2, the MONET moves and MR attaches to a foreign link. Figure 3 illustrates a larger MONET. ____ | | | CN | |____| ___|____________________ | | | | | Internet | | | |________________________| __|_ __|_ ____ | | Access | | | | | R2 | Router | R1 | | HA | |____| |____| |____| _____|________|____ home Access _|__ link Router | | | _____ |__| MR | Mobile Router | |__| |____| | LFN | | __|_____________ internal |_____| | __|__ __|__ link 1 _____ | | | | | | |__| | LFN | | LFN | Local Fixed Nodes | LFN | | |_____| |_____| |_____| | | internal link 2 Figure 3: Larger MONET with 2 subnets 2.2. Assumptions In order to keep things as simple as possible, we make the following assumptions and observations: o No Multi-homing: the MONET attaches to the Internet through only one MR, and the MR has only one egress interface. o MONET Prefix: network prefix common to all IP addresses in the MONET when the MR is attached to the home link. For a MONET containing only one subnet, the MONET Prefix is the prefix of this Ernst & Olivereau Expires September 2002 [Page 6] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 subnet. Note that the MONET Prefix is NOT the home subnet prefix (i.e. the IP subnet prefix corresponding to the mobile router's home address, as defined in [MIPv6]). We do not either make any assumption on the number of bits common to the MONET Prefix and the home subnet prefix. The MONET Prefix may be a sub-prefix of the home subnet prefix. If, for example, the latter is a /60, the MONET Prefix must be larger than /60, and the first 60 bits of both prefixes are identical. Alternatively, they could also diverge from a smaller number of bits. For instance, an organization may decide to split the SLA field of the IPv6 address in several sub-fields (SLA1, SLA2). In this case, the MONET may be identified by a unique SLA1, and the home subnet prefix by another one. If the length of the SLA1 field is 8 bits, the length of the MONET Prefix is 60 bits and the MONET could contain up to 2^4 subnets. o MR's egress interface is configured with the Home Subnet Prefix o MR's ingress interface is configured with the MONET Prefix. o All LFNs in the MONET are configured with the MONET Prefix. o Nodes behind the MR are only LFNs (Local Fixed Nodes). We therefore do not consider specific issues related with LMNs (Local Mobile Nodes) nor VMNs (Visiting Mobile Nodes). Although we have put these assumptions in order to restrict ourselves to the most common and easiest instances of MONETs, our solution may not necessarily be limited to these. We simply do not address the specific issues related to more complex MONETs like those comprising VMNs and LMNs. This should be investigated later. We note that Hierarchical Mobile IPv6 Extended Mode [HMIPv6] proposes to handle VMNs, but it may need additional features such as the ones proposed in this draft. 3. Why can't Mobile IPv6 support MONETs ? In this section, we first review how the Mobile IP specifications deal with MONETs. We then show the results of an experimentation we have conducted to outline Mobile IPv6's inability to support MONETs. Then we discuss why the existing Mobile IPv6 specification is unable to support MONETs if the MR performs Mobile IPv6. 3.1. Review of Mobile IP and MONET support Mobile IPv4 proposes to support MONETs as standard mobile nodes (see [MIPv4] section 4.5, [Perkins98] section 5.12, [Solomon98] section 11.2). In this situation, the mobile node is the MR connecting the Ernst & Olivereau Expires September 2002 [Page 7] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 MONET to the fixed Internet. It has a permanent home address on its home link and gets a new CoA at each subsequent foreign link. As any mobile node, MR sends a Binding Update to its home agent HA to instruct it to intercept and tunnel packets via the CoA. The HA is therefore able to intercept packets intended to the home address of MR. In order to intercept packets intended to LFNs, Mobile IPv4 suggests either of the following two solutions: o the HA may be configured with a permanent registration for each LFN which indicates MR's address as the LFN's CoA. o the MR may advertise connectivity to the entire MONET using normal IP routing protocols. Mobile IPv6 [MIPv6] and Mobile IPv4 with Routing Optimization [MIPv4-RO] could in principle support MONETs similarly as in Mobile IPv4. However, although mentioned in [MIPv4], the current specifications [MIPv4-RO] and [MIPv6] don't mention them anymore. 3.2. Experimentation The following sections describe an experimentation conducted to highlight shortcomings of the current Mobile IPv6 specification for supporting MONETs. It shows [MIPv6] does not allow to route a packet from the fixed Internet to a LFN behind the MR. This experimentation has been conducted on our IPv6 test bed using Francis Dupont "INRIA" IPv6 implementation under FreeBSD. 3.2.1. Test Bed As this is illustrated on figure 5, MR has two interfaces. At home, the egress interface is attached to the home link (3ffe:306:1130:100::/64) and is configured with the home address (3ffe:306:1130:100::eui64). The ingress interface is on the internal link (3ffe:306:1130:200::/64) and his configured with the MONET Prefix. LFN1 is a fixed node on the internal link. The MR moves and attaches to a foreign link (3ffe:306:5555:7777::/64) while performing MIPv6. In a first experiment, a CN in the fixed Internet pings MR. In a second experiment, the CN pings LFN1. 3.2.2. Registration with the Home Agent MR obtains a CoA on the foreign link and registers its primary CoA with its HA. Once the HA receives a valid Binding Update from the MR, it records in its Binding Cache the binding between MR's home address and MR's CoA. The home address is used as the key for Ernst & Olivereau Expires September 2002 [Page 8] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 searching the Binding Cache [MIPv6, section 4.6]. In order to intercept packets, HA claims to be the MR. This is performed by means of a "gratuitous" Neighbor Advertisement message on behalf of the mobile node (i.e. MR), as described in [MIPv6, section 9.5]. More precisely, when it receives a home registration from MR, the HA: o opens a NDP proxy to intercept packets addressed to MR's home address. o opens a tug (a virtual interface, i.e. IPv6 in IPv6 tunnel) between MR's CoA and itself. o adds a host-specific route (a route to a host, not to a prefix) for MR's home address via MR's CoA through the tug. ____ | | | CN | |____| ___|____________________ | | | | | Internet | | | |________________________| __|_ __|_ ____ | | | | | | Home Agent | R2 | | R1 | | HA | Binding cache: |____| |____| |____| 3ffe:306:1130:100::eui64 -> COA | | | _______|_ foreign __|________|____ home link | link | 3ffe:306:1130:100::/64 | 3ffe:306:5555:7777::/64 __|_ | | Mobile Router | MR | home address 3ffe:306:1130:100::eui64 |____| COA 3ffe:306:5555:7777::eui64 | _____|_________ internal link | | 3ffe:306:1130:200::/64 __|___ __|___ | | | | | LFN2 | | LFN1 | Local Fixed Node 1 |______| |______| 3ffe:306:1130:200::eui64 Figure 5: Packets sent from CN to LFN1 are dropped by Home Agent Ernst & Olivereau Expires September 2002 [Page 9] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 3.2.3. First experiment: Communication between CN and MR CN pings MR's home address (3ffe:306:1130:100::eui64). When the packet gets to the home network via R1, R1 sends NDP messages to discover the MAC address corresponding to the destination address (i.e. MR's home address). HA answers with its address on behalf of MR. The packet gets routed to the HA. In the standard IPv6 input function of the HA, the packet is routed through the tug, i.e. tunneled to MR's CoA. The packet therefore gets re-roouted to the current location of the MR where it is de-tunneled and correctly received. 3.2.4. Second experiment: Communication between CN and LFN1 CN pings LFN1's IP address (3ffe:306:1130:200::eui64). When the packet gets to the home network, R1 checks its routing table to reach LFN1. R1 has a route to the MONET; MR's home address is the next hop toward LFN1. R1 sends NDP messages to discover MR's MAC address. HA answers with its address on behalf of the MR. The packet is transmitted on the home link and intercepted by HA. However, HA does not have a route to the MONET Prefix. The ping packet is thus sent to the default route, i.e. R1, which forwards it again to the HA. THE PING PACKET ENTERS A ROUTING LOOP UNTIL THE TTL EXPIRES. 3.3. Conclusion We see that obtaining a CoA and requesting the HA to redirect incoming packets intended for MR doesn't require modifications in [MIPv6] as this could be done independently for a host or for a router. As a result, packets intended to MR are correctly intercepted by the HA and tunneled to MR. However, although HA is able to intercept datagrams intended to LFNs, it is unable to encapsulate them to MR's CoA because it does not have a route to the MONET Prefix. The MR's registration only tells the HA to record a host-specific route in its routing table. A network route for the MONET Prefix (prefix of the MR's ingress interface) via MR's CoA is missing. Since the HA is unable to redirect packets intended to LFNs and CNs don't have an entry in their Binding Cache to route packets directly to LFNs, no communication at all is possible between CNs and LFNs. We conclude that the Mobile IPv6 specification needs: o explicit clarification in order for the HA to redirect all packets intended to the MONET, but extensions are more likely needed. Ernst & Olivereau Expires September 2002 [Page 10] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 o extension in order to transmit packets from the CN to LFNs by the most optimal route. Some other Mobile IPv6 implementations do indeed interpret the behavior of the HA in face of a MR registration. In such implementations, the HA may have a network route for the MONET Prefix via MR's CoA. We advocate that such an implementation does not strictly follow [MIPv6] and may probably not comply with it. Leaving too much room for interpretation surely leads to misinterpretation and pitfalls, not to say security holes. Thus, MONETs should be taken into account explicitly, and separately from [MIPv6]. 4. Mobile IPv6 extensions to support MONETs 4.0. Overview According to the observations made in section 3.2.4, we propose to extend Mobile IPv6 with "Prefix Scope Binding Updates". Instead of establishing a one-to-one relationship between a home address and a CoA, the binding establishes a many-to-one relationship between the set of nodes that share the same MONET Prefix and a CoA. Prefix Scope Binding Updates are Binding Updates that associate a CoA with the MONET Prefix instead of the full 128-bits IPv6 home address. The MONET Prefix is carried in a new Sub-Option and requires a new flag in the Mobile IPv6 Binding Update Option. MR sends Prefix Scope Binding Updates to its HA and all the CNs communicating with the MR itself or any LFNs behind it. The Prefix Scope Binding Update instructs its recipients to use the MONET Prefix as a netmask in the Binding Cache. The procedure for searching the Binding Cache is slightly modified for this purpose. As a result, the MR's CoA is returned for all destination addresses corresponding to the MONET Prefix. As we can see, a sole Prefix Scope Binding Update message allows registration of an entire MONET, independently of the number of LFNs, and transparently to them. Our solution therefore preserve routing aggregation. In addtion, direct routinng between a CN and the MONET is also made possible by means of a single registration. This is particularly useful for a CN communicating with several LFNs from the same MONET. 4.1. Packet Format of the Binding Update We propose to extend the Mobile IPv6 Binding Update Option with an extra flag "Prefix Scope Registration" (P) taken from the "Reserved" field. In addition, the "MONET Prefix Sub-Option" is a new sub- Ernst & Olivereau Expires September 2002 [Page 11] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 option that contains the MONET Prefix. 4.1.1. New Binding Update Option Format The Binding Update option is encoded in type-length-value (TLV) format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|R|D|P|Rsrvd| Prefix Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Prefix Scope Registration (P) When set, it indicates that the sending mobile node attempts to register a CoA for an entire network. It also requests the receiving node to process the MONET Prefix Sub-Option and to re-route packets with a destination address that corresponds to the MONET Prefix. Rsrvd This field is reduced from a 4-bit field to a 3-bit field to account for the addition of the "Prefix Scope Registration" bit. The remaining 3 bits are unused and MUST be initialized to zero by the sender and MUST be ignored by the receiver. 4.1.2. MONET Prefix Sub-Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| Prefix Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + MONET Prefix + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MONET Prefix is filled by the sending mobile node to request the receiving node to record a Prefix Scope entry in the Binding Ernst & Olivereau Expires September 2002 [Page 12] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 Cache (see section 4.2). The Prefix Length field is set to the (nonzero) length of the MONET Prefix. The MONET Prefix field is set to the prefix of the MONET. 4.2. Cache Management 4.2.1. Binding Cache Entries Binding Cache entries are as defined in [MIPv6] with minor changes: - is added a "Prefix Scope Registration" (P) flag indicating whether this Binding Cache entry corresponds to a 128-bits address or a prefix. If set, the "home address" field is filled with a MONET Prefix instead of a full 128-bits address. - the value of the "Prefix Length" field received in the Binding Update that created or last modified this Binding Cache entry is modified. This field is only valid if the "Prefix Scope Registration" flag or the "Home Registration" flag is set on this Binding Cache entry. If the "Prefix Scope Registration" flag is set, the "Prefix Length corresponds to the length of the MONET Prefix, otherwise the meaning is as defined in [MIPv6]. 4.2.2. Searching the Binding Cache Entries The Binding Cache is searched for an entry corresponding to the destination address of the packet. The destination address is compared against the home address field of entries recorded in the Binding Cache. If the "Prefix Scope Registration" flag is set in the entry under comparison, the comparison is made on the "Prefix Length" set of initial bits. If the prefix of the destination matches the MONET Prefix recorded in the entry, the destination is located in a MONET. If the "Prefix Scope Registration" flag is not set, the comparison is made on the 128-bits addresses. If the destination address matches the home address, the destination is a mobile node. In both case, the CoA of the corresponding entry is returned. 4.3. Extended Mobile IPv6 Protocol Operation Ernst & Olivereau Expires September 2002 [Page 13] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 The MR is a new entity similar to the MN. The MR Operation makes use of most of the MN Operation extended with the ability to set the (P) bit to 1, to fill the MONET Prefix Sub-Option, and to send Binding Updates to all CNs that communicate with any LFN in the MONET. The CN Operation and the HA Operation are extended in order to process the MONET Prefix Sub-Option and to transmit packets to the CoA of the MR. The MONET Prefix Sub-Option is processed if the (P) bit from the Binding Update Option is set. Packets are transmitted to the MR's CoA if the destination address matches the MONET Prefix. The following sections only describe changes according to sections 8, 9 and 10 of the [MIPv6]. 4.3.1. Correspondent Node Operation Receiving (Prefix Scope) Binding Updates Upon receiving a Binding Update, the CN performs validity checks as described in [MIPv6] section 8.2. In addition, if the "Prefix Scope Registration" (P) bit in the Binding Update Option is set, the CN received a Binding Update from a MR and the Binding Update must include a MONET Prefix Sub-Option. This option MUST be ignored if the "Prefix Scope Registration" (P) bit is not set. If the Binding Update is valid, the CN creates a new entry in its Binding Cache as this is performed in [MIPv6]. In addition, if the (P) bit is set, the CN creates a second Binding Cache entry similar to the first one as follows: o the "Prefix Scope Registration" bit is taken from the corresponding field as found in the Binding Update Option, o the "Prefix Length" field is taken from the corresponding field as found in the MONET Prefix Sub-Option, o the "Home Address" field is filled with the prefix taken from the "MONET Prefix" field as found in the MONET Prefix Sub-Option. Figure 6 shows the content of the Binding Cache. Sending Packets Before sending any packet, the CN examines searches the Binding Cache for an entry corresponding to the destination address (see section 4.2.2 "Searching the Binding Cache"). If a CoA is Ernst & Olivereau Expires September 2002 [Page 14] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 returned, a routing header is inserted as specified in [MIPv6]. 4.3.2. Home Agent Operation Primary care-of address registration Upon receiving a Binding Update, the HA performs validity checks as described in [MIPv6] section 9.3. In addition, if the "Prefix Scope Registration" (P) bit in the Binding Update Option is set, the HA received a Binding Update from a MR and the Binding Update must include a MONET Prefix Sub-Option. This option MUST be ignored if the "Prefix Scope Registration" (P) bit is not set. If the Binding Update is valid, the HA creates a new entry in its Binding Cache as it is performed in [MIPv6]. In addition, if the (P) bit is set, the HA creates a second Binding Cache entry similar to the first one as follows: o the "Prefix Scope Registration" bit is taken from the corresponding field as found in the Binding Update Option, o the "Prefix Length" field is taken from the corresponding field as found in the MONET Prefix Sub-Option, o The "Home Address" field is filled with the prefix taken from the "MONET Prefix" field as found in the MONET Prefix Sub-Option. Figure 6 shows the content of the Binding Cache. Intercepting Packets Datagrams sent by the CN to the IP address of the LFN are routed up to the home link of the MR where they are intercepted by the HA as specified in [MIPv6] section 9.5. Tunneling Intercepted Packets to a Mobile Node For any packet sent to a mobile node or a LFN for which the HA is the original sender of the packet, the HA is operating as a CN and the procedures described in section 4.3.1. applies. While acting as a HA, all packets addressed to the MR or a LFN are intercepted on the home link. The HA examines its Binding Cache for an entry corresponding to the destination address (see section 4.2.2 "Searching the Binding Cache"). If a CoA is returned, the packet is tunneled to this CoA as specified in Ernst & Olivereau Expires September 2002 [Page 15] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 [MIPv6]. 4.3.3. MR Operation Obtaining a care-of address Similarly to a standard MN Operation defined in [MIPv6], the MR obtains a new CoA on each subsequent foreign links using either stateless or stateful DHCPv6 address configuration. ____ | | | CN | Binding cache: |____| 3ffe:306:1130:100::eui64 -> COA | 3ffe:306:1130:200/64 -> COA ___|____________________ | | | | | Internet | | | |________________________| __|_ __|_ ____ | | | | | | Home Agent | R2 | | R1 | | HA | Binding cache: |____| |____| |____| 3ffe:306:1130:100::eui64 -> COA | | | 3ffe:306:1130:200/64 -> COA | | | _______|__ foreign __|________|____ home link | link | 3ffe:306:1130:100::/64 __|_ | | Mobile Router | MR | home address 3ffe:306:1130:100::eui64 |____| COA 3ffe:306:5555:7777::eui64 | _____|_________ internal link | | 3ffe:306:1130:200::/64 __|___ __|___ | | | | | LFN2 | | LFN1 | Local Fixed Node 1 |______| |______| 3ffe:306:1130:200::eui64 Figure 6 : MONET Prefix is recorded in the Binding Cache Receiving encapsulated packets from the Home Agent The MR may receive packet encapsulated to its CoA. Those packets may indeed be intended to the MR itself or to any LFN served by the MR. The reception of an encapsulated packet Ernst & Olivereau Expires September 2002 [Page 16] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 tunneled from the MR's HA is an indication that the original sender may not have a Binding Cache entry for the MONET Prefix. In this case, the MR may deduce that a Prefix Scope Binding Update should be sent to the original sender of the packet. Sending Prefix Scope Binding Updates A MR serving as a gateway to a MONET sends Prefix Scope Binding Update datagrams to its HA, its own CNs, and CNs of the LFNs it is serving. Prefix Scope Binding Updates are sent as specified in [MIPv6] section 10.6 and 10.8 and the Binding List is filled accordingly. In addition, the MR sets the "Prefix Scope Registration" bit in the Binding Update Option and inserts a MONET Sub-Option. The "Prefix Length" and the "MONET Prefix" fields are filled according to the MONET Prefix owned by the MR. Bypassing ingress filtering In order to bypass ingress filtering, the MR may encapsulate all outgoing packets to the destination with its CoA as the outer source address. 5. Security Issues Prefix Scope Binding Update faces a number of security issues and is subject to modifications when a solution to secure Mobile IPv6 is found [MIPv6-SECURITY]. We are therefore monitoring ongoing discussion on the IETF mobileip mailing list. 5.1. Authentication The registration of the MR's CoA for a MONET Prefix does not break authentication and does not differ from the standard Mobile IPv6 registration for a Mobile Node. In Mobile IPv6, the Mobile Node is authenticated by the CN based on its home address, whatever the content of the Binding Update. Similarly, nothing breaks the authentication of the sender of a Prefix Scope Binding Update. The MR operates as a standard Mobile Node and has a home address. Authentication is still based on this home address. Recipients of the prefix scope Binding Updates are not misled about the identity of the sender. The MR is clearly authenticated by its HA and CNs whatever is contained in the Binding Update. 5.2. Authorization Discussion in the mailing list and IETF meetings have advocated a need to extend Mobile IPv6 with authorization. In the standard Mobile Ernst & Olivereau Expires September 2002 [Page 17] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 IPv6, the Mobile Node is authenticated by its HA and CNs but those have no guarantee that the Mobile Node is allowed to send a Binding Update for the home address specified in the Binding Update. Indeed, the Mobile IPv6 policy is to accept whatever is being carried in the Binding Update as long as the sender is authenticated. A MR willing to send Prefix Scope Binding Updates faces the same authorization issue. In addition, a means is required to authorize a MR to register a binding between the MONET Prefix and its CoA. In other words, we need a means to certify that the MR actually owns and serves the MONET Prefix. 5.3. Prefix Ownership Two solutions are currently considered as suitable for ensuring address ownership for a Mobile Node: Cryptographically Generated Addresses (CGA) and Return Routability (RR) [IETF-52]. Both could be adapted for MRs, although it would require some enhancements to the protocols. A Cryptographically Generated Address is obtained from a hash of a public key. The address is thus bound to a private key / public key pair that is used to sign the Binding Update. Extending the concept of CGA towards 'Cryptographically Generated Sub-Prefixes' does not seem to be applicable, except for specially long sub-prefixes. Indeed, the robustness of the algorithm against collisions is directly dependent on the space available to generate the (hopefully) unique identifier. Return Routability model consists in verifying that the claimed home address is actually reachable at the given CoA. RR-based solutions would be easier to consider for ensuring prefix ownership. Whereas it cannot be envisioned to check return routability for every possible address behind the claimed prefix, it can be sufficient to check only a limited number of addresses, provided that they are properly chosen. For example, MR Home Agent address, MR Home Address, and any MNN Home Address may be enough for a CN to validate a received Prefix Scope Binding Update. Ernst & Olivereau Expires September 2002 [Page 18] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 6. Changes since last draft Changes from draft-v2 to draft-v3 - Security section updated to take into account recent discussion on the mobileip mailing list about security: section 5.2.1 and 5.2.2 are replaced by section 5.3. - Terminology: all the terminology used in this draft has been refined in order to comply with [TERMINOLOGY] discussed in [WEB- MONET]. - Rewording of most sections Changes from draft-v1 to draft-v2 - Abstract rewritten - Extended section about security issues. - Clarification between "home subnet prefix" and "MONET Prefix" in the terminology. - Section 3.3 divided into 3.3 and 3.4 - Added section "Receiving encapsulated packets from the Home Agent" - Minor misspelling corrections Changes from draft-v0 to draft-v1 - Updated definitions of the terminology section 2.2, particularly: o clarified the distinction between possible kinds of nodes located in the MONET: Local Fixed Nodes (LFN) and Visiting Mobile Nodes (VMN). o clarified that the MR has (at least) two interfaces, one on the home link, one on the internal link (within the MONET) - New example showing IPv6 addresses - Added a description of an experimentation outlining HA is unable to tunnel packets to the MONET if the final destination is not the MR itself. Ernst & Olivereau Expires September 2002 [Page 19] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 - Enhanced section about security concerns Acknowledgments This work has originally been supported by Motorola Labs Paris and ANRT (French ``Association Nationale de la Recherche Technique'') under CIFRE convention number 97595. This CIFRE convention associates: a firm, Motorola Labs (Paris, France); a French academic laboratory (INRIA Rhône-Alpes, Grenoble) and a French university (University Joseph Fourier, Grenoble). We would like to thank Francis Dupont (ENST Bretagne) for his careful reading, valuable comments and suggestions, and also Christophe Janneteau (Motorola Labs), Alexandru Petrescu (Motorola Labs), Ryuji Wakikawa (WIDE Project, Keio University), and Koshiro Mitsuya (WIDE Project, Keio University) for all their comments. The first author would like to thank both Motorola Labs Paris and INRIA Rhône-Alpes, for being given the opportunity to bring this topic to the IETF. References [Ernst01] Thierry Ernst "Network Mobility Support in IPv6", PhD Thesis, University Joseph Fourier Grenoble, France, October 2001. [HMIP] Hesham Soliman, Claude Castelluccia, "Hierarchical MIPv6 mobility management", , IETF, February 2001. Work in progress. [IETF-52] Proceedings IETF Meeting Salt Lake City, December 2001, http://www.ietf.org/proceedings/01dec/slides/mobileip-6/ [IPv6] S. Deering and R. Hinden. Internet Protocol Version 6 (IPv6) Specification. RFC 2460, December 1998. [MIPv4] C. Perkins (Editor). "IP Mobility Support", RFC 2002, October 1996. [MIPv4-RO] C. Perkins and D. B. Johnson. "Route Optimization in Mobile IP", Sun Microsystems and Carnegie Mellon University, February 2000. Work in progress. [MIPv6] D. B. Johnson and C. Perkins. "Mobility Support in IPv6", April 2000. Work in progress. [MIPv6-SECURITY] G. Montenegro, A. Petrescu "MIPv6 Security: Ernst & Olivereau Expires September 2002 [Page 20] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 Assessment of Proposals" , IETF, November 2001. Work in progress. [Ownnership] P. Nikander. An Address Ownership Problem in IPv6, , IETF, February 2001. Work in progress. [Perkins98] C. Perkins, "Mobile IP, Design Principles and Practices". Wireless Communications Series. Addison-Wesley, 1998. ISBN 0-201-63469-4. [REQUI-1] Thierry Ernst, Hong-Yon Lach "Requirements for Network Mobility Support", , IETF, February 2001. Work in progress. [REQUI-2] Lach, Boot, Janneteau, Olivereau, Petrescu "Mobile Network Scenarios, Scope and Requirements", , IETF, February 2002. Work in progress. [REQUI-3] T. J. Kniveton, J. T. Malinen, V. Devarapalli, C. Perkins. "Mobile Router Support with Mobile IP" , IETF, February 2002. Work in progress. [Solomon98] J. D. Solomon. "Mobile IP, The Internet Unplugged". Prentice Hall Series in Computer Networking and Distributed Systems. Prentice Hall PTR, 1998. ISBN 0-13-856246-6. [TERMINOLOGY] Thierry Ernst, Hong-Yon Lach "Terminology for Network Mobility Support", , IETF, February 2002. Work in progress. [WEB-MONET] MONET web page http://www.nal.motlabs.com/monet Author's Addresses Please direct questions about this memo to first author Thierry Ernst, WIDE Project and INRIA Jun Murai lab, Keio University 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. Phone : +81-466-49-1100 Ernst & Olivereau Expires September 2002 [Page 21] INTERNET-DRAFT Prefix Scope Binding Updates for MONETs March 2002 Fax : +81-466-49-1395 E-mail: ernst@sfc.wide.ad.jp Web: http://www.sfc.wide.ad.jp/~ernst/ Alexis Olivereau Motorola Labs Paris, Networking and Applications Lab (NAL) Espace Technologique - Saint Aubin 91193 Gif-sur-Yvette Cedex, France Phone: +33 1 69 35 25 16 Email: Alexis.Olivereau@crm.mot.com Ludovic Bellier INRIA - PLANETE team ZIRST-655 avenue de l'Europe 38330 Montbonnot Saint Martin, France Email: Ludovic.Bellier@inrialpes.fr Claude Castelluccia INRIA - PLANETE team ZIRST-655 avenue de l'Europe 38330 Montbonnot Saint Martin, France Phone: +33 4 76 61 52 15 Email: Claude.Castelluccia@inrialpes.fr Hong-Yon Lach Motorola Labs Paris, Networking and Applications Lab (NAL) Espace Technologique - Saint Aubin 91193 Gif-sur-Yvette Cedex, France Phone: +33 1 69 35 25 36 Email: Hong-Yon.Lach@crm.mot.com Ernst & Olivereau Expires September 2002 [Page 22]