Network Working Group J. Laganier Internet-Draft DoCoMo Euro-Labs Expires: September 7, 2006 S. Narayanan Panasonic March 6, 2006 Network-based Localized Mobility Management Interface between Mobile Node and Access Router draft-laganier-netlmm-mn-ar-if-00 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. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specify an IP layer interface between mobile nodes (MN) and access routers (AR) of a network-based localized mobility management (NetLMM) domain. Such an interface is subject to a Laganier & Narayanan Expires September 7, 2006 [Page 1] Internet-Draft NetLMM MN-AR Interface March 2006 certain number of threats, amongst which are attacks on the mapping between the MN Identifier and IPv6 address set. A binding enforcement mechanism between those two is hence required to prevent malicious nodes to carry on various attacks like service theft or denial-of-service attacks. In the absence of link-layer specific mechanisms enforcing this binding, it is required to implement such mechanism at the IP layer MN-AR interface. Moreover, it is required that no NetLMM specific software support is present on MNs. The IP layer MN-AR interface described in this document fulfills these two requirements by using the SEND public key as the MN identifier, while being solely based on standard track IPv6 protocols (DNA and SEND) implemented by non-NetLMM MNs. Laganier & Narayanan Expires September 7, 2006 [Page 2] Internet-Draft NetLMM MN-AR Interface March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Operating Environment . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 2.1. MN powers on in a NetLMM domain . . . . . . . . . . . . . 9 2.2. First attachment of MN moving into a NetLMM domain . . . . 10 2.3. MN handovers in a NetLMM-domain . . . . . . . . . . . . . 11 2.4. MN configuring additional CGAs . . . . . . . . . . . . . . 13 2.5. MN configuring CGA that is in use by another MN in the NETLMM domain . . . . . . . . . . . . . . . . . . . . . . 13 2.6. MN unconfigures CGAs, powers off, crash or leave the domain . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Mobile Node Specification . . . . . . . . . . . . . . . . . . 16 4. Access Router Specification . . . . . . . . . . . . . . . . . 18 4.1. Promiscuous and all-multicast modes . . . . . . . . . . . 18 4.2. Receiving Neighbor Discovery Messages from MN . . . . . . 18 4.2.1. Receiving DAD Neighbor Solicitations . . . . . . . . . 19 4.2.2. Receiving Solicited Neighbor Advertisements . . . . . 19 4.2.3. Receiving All Others Neighbor Discovery Messages . . . 19 4.3. Sending Neighbor Discovery Messages to MN . . . . . . . . 19 4.3.1. Sending Neighbor Solicitations . . . . . . . . . . . . 19 4.3.2. Sending Proxy Neighbor Advertisements . . . . . . . . 20 4.3.3. Sending Router Advertisements . . . . . . . . . . . . 20 4.3.4. Sending Redirects . . . . . . . . . . . . . . . . . . 20 4.4. Receiving All Others IPv6 Packets from MN . . . . . . . . 20 4.4.1. Authenticated Packets . . . . . . . . . . . . . . . . 20 4.4.2. Unauthenticated Packets . . . . . . . . . . . . . . . 21 4.5. Mobile Node Identifier used by AR . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Normative references . . . . . . . . . . . . . . . . . . . 24 7.2. Informative references . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Laganier & Narayanan Expires September 7, 2006 [Page 3] Internet-Draft NetLMM MN-AR Interface March 2006 1. Introduction It is suggested in [I-D.kempf-netlmm-nohost-ps] that it would be desirable to have a localized mobility management protocol in which the host is not involved. The requirements for such a protocol have been analyzed in [I-D.kempf-netlmm-nohost-req]. Accordingly, a protocol for network-based localized mobility management (NetLMM) of IPv6 nodes will be specified by the NetLMM working group; until this occurs, this document assumes [I-D.wood-netlmm-emp-base] as a strawman NetLMM protocol in use in a NetLMM domain. Further revisions of this document will be adapted to the NetLMM protocol proposal chosen by the working group. Because the NetLMM protocol is network based, the mobile node is not required to implement new mechanism in its IP stack, nor to change its IP address when it attaches to a new access router. Because the IPv6 mobile node will use a vanilla IPv6 stack, the interface between a mobile node and its access router has to be preserved. This means that standard IPv6 should work seamlessly with the network-based localized mobility support. More specifically, we require the proposed solution to be compatible with the mechanisms specified in: o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis] o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis] o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [I-D.ietf-ipv6-privacy-addrs-v2] o Detecting Network Attachment in IPv6 - Best Current Practices for Hosts [I-D.ietf-dna-hosts] o Detecting Network Attachment in IPv6 - Best Current Practices for Routers [I-D.ietf-dna-routers] o Detecting Network Attachment with Unmodified Routers: A Prefix List based approach [I-D.ietf-dna-cpl] o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- protocol] o SEcure Neighbor Discovery [RFC3971] o Cryptographically Generated Addresses [RFC3972] This document specify an IP layer interface between mobile nodes (MN) and access routers (AR) of a network-based localized mobility Laganier & Narayanan Expires September 7, 2006 [Page 4] Internet-Draft NetLMM MN-AR Interface March 2006 management (NetLMM) domain. Such an interface is subject to a certain number of threats, amongst which are attacks on the mapping between the MN Identifier and IPv6 address set. A binding enforcement mechanism between those two is hence required to prevent malicious nodes to carry on various attacks like service theft or denial-of-service attacks. In the absence of link-layer specific mechanisms enforcing this binding, it is required to implement such mechanism at the IP layer MN-AR interface. Moreover, it is required that no NetLMM specific software support is present on MNs. The IP layer MN-AR interface described in this document fulfills these two requirements by by using the SEND public key as the MN identifier, while being solely based on standard track IPv6 protocols (DNA and SEND) implemented by non-NetLMM MNs. 1.1. Terminology 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 [RFC2119]. In addition, new terms are defined below: Network-based Localized Mobility Management Domain (NETLMM domain) : An administrative domain spanning geographically contiguous link layer networks served by access routers. Mobile Node (MN): The MN is an IPv6 node moving in the domain. Access Router (AR): The AR is the Mobile Node's default router. External interface : A network interface of an AR attached to the link used by MN. Mobility Anchor Point (MAP): A Mobility Anchor Point is a router located in the network-based localized mobility domain handling exchanged between that domain and the Internet. 1.2. Abbreviations Throughout this document, figures make use of the following abbreviations: ND: Neighbor Discovery. NDP: Neighbor Discovery Protocol. SEND: SEcure Neighbor Discovery. Laganier & Narayanan Expires September 7, 2006 [Page 5] Internet-Draft NetLMM MN-AR Interface March 2006 DNA: Detecting Network Attachment. LNMP: NetLMM Protocol used in the backhaul of the NetLMM domain (between ARs and MAP.) CGA: Cryptographically Generated Address. CGA_LL: The link-local unicast CGA generated by the MN with its public key (It is assumed that the MN is using a single public key to configure all of its link-local unicast and global unicast CGAs.) CGA_1: One of the Global Unicast CGA generated by the MN with its public key. CGA_2: Another one of the Global Unicast CGA generated by the MN with its public key (e.g. with a different subnet prefix.) CGA_*: Any Unicast CGA generated by the MN with its public key (i.e. link-local or global.) MNID: Mobile node identifier set to the public key used by the MN for generating its CGAs. 1.3. Operating Environment The MN-AR NetLMM interface is used between a mobile node and an access router of a NetLMM domain. In the absence of link-layer specific mechanism, it allows the AR to detect the network attachment of a MN and update routing at the MAP so that the MN stays reachable when it roams across the NetLMM domain. Laganier & Narayanan Expires September 7, 2006 [Page 6] Internet-Draft NetLMM MN-AR Interface March 2006 /-----------\ / Internet \ \ / \-----+-----/ | +-------+ | MAP | +---+---+ | /------------+------------\ / NetLMM \ \ domain / / \-------------------------/ \ | | | +--+--+ +--+--+ +--+--+ | AR1 | | AR2 | | AR3 | +-----+ +-----+ +-----+ / \ / \ / \ / \ / \ / \ / \ / \ / \ MN-AR - -/- - - -\- - - -/- - - -\- - -/- - - -\- - - - - - / \ / \ / \ Interface / +-----+ \ / \ / | MN | -------> X \ / +-----+ movement / \ \ The deployment scenario is shown in the figure above: Several ARs are attached to an IP routing domain connected to the outside Internet via a MAP. The ARs, MAP, and in-between routing fabric constitute the NetLMM domain. Each AR announce on its external interface a common set of prefix(es) which are routed to the MAP from the outside Internet. Packets incoming at the MAP and directed at the MN are tunneled to the appropriate AR based on the information provided by ARs. In the absence of a link-layer specific MN-AR interface, it is required to have a common interface defined at the IP layer. Because no NetLMM specific software support is assumed to be present on MNs, this interface has to rely only on standard tracks IPv6 protocols such as Neighbor Discovery (ND), SEND (Secure ND) and Detecting Network Attachment (DNA). Interactions of these three components with NetLMM are represented below (note that hints received by DNA from other layers are omitted for clarity): Laganier & Narayanan Expires September 7, 2006 [Page 7] Internet-Draft NetLMM MN-AR Interface March 2006 MN|AR Interface | | +------------+ +----------+ | | | | | | +--------+ | NLMP | +------+ | | | NetLMM |<-------->|NetLMM| | | | +--------+ | | +------+ | | ^ ^ | | ^ | +----------+ | | | | | | | | | | | v | | | | | | +------+ | | | +-----+ | | | | | | | DNA | | NDP | | DNA | | | | | | | | SEND |<------|------>|SEND | | | | | | | | ND | | | | ND | | | | | | | +------+ | | | +-----+ | | | | | | ^ | | ^ | | | | | | | | | | | | | | | | | v | | v | | | v | | +------+ | | | +----+ | | | +------+ | | | | | | | |<-+ | | | | | | | | | IPv6 | | | | IPv6 | | | | | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | | +------+ | | +----+ | | +------+ | | | | | | | | | MN | | AR | | MAP | +----------+ | +------------+ +----------+ | Laganier & Narayanan Expires September 7, 2006 [Page 8] Internet-Draft NetLMM MN-AR Interface March 2006 2. Protocol Overview The following subsections present the different situations in which the MN-AR interface is used to trigger the NetLMM protocol. 2.1. MN powers on in a NetLMM domain +-------------------------------------------------------------------+ |Caption :In following figures it is assumed that the MN and AR | | clocks are synchronized enough to allow verification of ND| | messages via SEND timestamps. If that would not be the | | case, in order to verify freshness of ND signaling sent | | by the MN, the AR would be required to solicit the MN by | | sending to it a NS with a fresh nonce, to which the MN | | would reply with a NA containing the same fresh nonce. | +-------------------------------------------------------------------+ MN AR1 MAP | | | | NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) | |----------------------->|---------------------->| bind(CGA_LL,MNID) | |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR1) | |<----------------------| | RS | | |----------------------->| | | RA | | |<-----------------------| | | NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) | |----------------------->|---------------------->| bind(CGA_1,MNID) | | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR1) | |<----------------------| | | | | NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) | |----------------------->|---------------------->| bind(CGA_2,MNID) | | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR1) | |<----------------------| | | | Figure 1: MN powers on and configures a Link-Local and two Global Unicast CGAs When a MN powers on for the first time, it will generate a link local address based on its public key (CGA_LL) as per [RFC3972], and perform DAD on the address as per [RFC2462]. The DAD-NS message generated will contain the public key in the CGA option as defined by SEND [RFC3971]. Upon reception of this NS message, the access router (AR1) SHOULD generate a UPDATE to the MAP with the public key as the Laganier & Narayanan Expires September 7, 2006 [Page 9] Internet-Draft NetLMM MN-AR Interface March 2006 MNID along with CGA_LL. The MAP SHOULD bind the CGA_LL to the MNID and establish a route binding for the CGA_LL to the access router AR1. The MAP acknowledges the receipt of the UPDATE message. While waiting for the completion of DAD, the MN may generate RS message as per [RFC2461] with the unspecified address as the source address. Such an RS message will not contain a CGA option. The access router will respond with a multicast RA as per [RFC2461]. With the prefix information received in the RA message, the MN will cryptographically generate one or more global addresses (CGA_*). For each of these addresses, the MN will perform DAD as the IID is likely to be different for each of these cryptographically generated addresses. For every DAD-NS received from the MN,the access router AR1 will generate a UPDATE message to the MAP establishing binding in the MAP. 2.2. First attachment of MN moving into a NetLMM domain MN AR2 MAP | | | | RS | | |---------------------->| | | RA | | |<----------------------| | | NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) | |---------------------->|---------------------->| bind(CGA_LL,MNID) | |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR2) | |<----------------------| | NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) | |---------------------->|---------------------->| bind(CGA_1,MNID) | | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR2) | |<----------------------| | | | | NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) | |---------------------->|---------------------->| bind(CGA_2,MNID) | | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR2) | |<----------------------| | | | Figure 2: MN moves into a NetLMM domain and configures a Link-Local and two Global Unicast CGAs When a MN moves into a NETLMM domain for the first time, it will initiate link change detection as specified in [I-D.pentland-dna- protocol] by multicast transmission of a RS message. When the MN receives a RA message in response, it will figure out that it has Laganier & Narayanan Expires September 7, 2006 [Page 10] Internet-Draft NetLMM MN-AR Interface March 2006 changed link as defined by the DNA specification [I-D.pentland-dna- protocol]. Once the MN realizes it has changed link, it will discard its current IP addresses and will execute DAD for its link-local address and new global addresses based on the prefix information in the received RA messages. The behavior of the access router AR2 in response to the DAD messages is similar to that of AR1 specific in Section 2.1. 2.3. MN handovers in a NetLMM-domain MN AR3 MAP | | | |RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| route(CGA_LL->AR3) | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR3) | RA(AR->CGA_LL) | CGA_1,CGA_2) | route(CGA_2->AR3) |<-----------------------|<----------------------| | | | Figure 3: MN getting handover hint and receives a unicast RA When the MN moves within the NETLMM domain, it will send a RS message with the source address as its link-local address as specified by [I-D.pentland-dna-protocol]. The access router again can use the public key in CGA option to infer the MNID and send updates to the MAP. If the access router chooses to respond with a unicast RA, all required steps are done. MN AR4 MAP | | | |RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| route(CGA_LL->AR4) | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR4) | RA(AR->All_nodes) | CGA_1,CGA_2) | route(CGA_2->AR4) |<-----------------------|<----------------------| | NS | | |----------------------->| | | NA | | |<-----------------------| | | | | Figure 4: MN getting handover hint and receives a multicast RA Laganier & Narayanan Expires September 7, 2006 [Page 11] Internet-Draft NetLMM MN-AR Interface March 2006 In a similar scenario, if the access router chooses to respond with a multicast RA, the MN will send a NS to learn about the access router and confirm reachability. MN AR5 MAP | | | | NS(AR->CGA_*) | | |<-----------------------| | | NA(CGA_*->AR) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| route(CGA_LL->AR5) | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR5) | | CGA_1,CGA_2) | route(CGA_2->AR5) | |<----------------------| | | | Figure 5: AR getting handover hint of MN whose IP address is known Instead of the MN receiving the hint, in scenarios were the access router receives the hint with the IP address of the handing over MN, the AR can send a NS to that IP address. The NA message received in response will contain the public key of the MN with which the AR can send update message to the MAP. MN AR6 MAP | | | | RA(AR->All_nodes) | | |<-----------------------| | | NS(CGA_*->AR) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| route(CGA_LL->AR6) | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR6) | NA(AR->CGA_*) | CGA_1,CGA_2) | route(CGA_2->AR6) |<-----------------------|<----------------------| | | | Figure 6: AR getting handover hint of MN whose IP address is unknown If the access router does not receive the IP address information of the handing over MN along with the hint, the AR can schedule a multicast RA. The MN will try to fill its neighbor cache information with the new router and confirm its reachability by initiating a NS message to the AR. The AR can then send update message to the MAP based on the public key in the NS message. Laganier & Narayanan Expires September 7, 2006 [Page 12] Internet-Draft NetLMM MN-AR Interface March 2006 2.4. MN configuring additional CGAs If the MN choose to configure new global addresses at any point in time, it will contact DAD on the new address by sending a DAD-NS message. The access router can learn the new address from the NS message and map to the corresponding public key in the CGA option. MN AR MAP | | | | NS(DAD:CGA_3) | UPDATE(MNID,CGA_3) | |----------------------->|---------------------->| bind(CGA_3,MNID) | | REPLY[OK](MNID,CGA_3) | route(CGA_3->AR) | |<----------------------| | | | Figure 7: MN configuring later on additional CGAs 2.5. MN configuring CGA that is in use by another MN in the NETLMM domain The access router learns about new global addresses configured by the MN from the NS-DAD message sent by MN. When the AR sends an UPDATE to the MAP based on this DAD-NS, it waits for a positive acknowledgment from the MAP. If the MAP has an entry for the save CGA with a different MNID, it will respond back with a message indicating collision and the AR must proxy for the other MN by responding to the DAD-NS. MN AR MAP | | | | NS(DAD:CGA_3) | UPDATE(MNID,CGA_3) | |----------------------->|---------------------->| collision(MNID) | NA(CGA_3->MN) |REPLY[COLLISION](CGA_3)| |<-----------------------|<----------------------| | | | Figure 8: MN configuring later on a colliding CGA 2.6. MN unconfigures CGAs, powers off, crash or leave the domain It is recommended that the access router do periodic reachability testing with MN, Neighbor Unreachability Detection (NUD), to learn about addresses being unconfigured or the MN being powered off or crashing. The trigger for this test could be neighbor cache entry timeout or a MLDv2 [RFC3810] unsubscribe for the solicited-node multicast address matching the MN's CGA. [XXX figure TBD.] In the Figure 9, the MN stops using the address CGA_1 and when the Laganier & Narayanan Expires September 7, 2006 [Page 13] Internet-Draft NetLMM MN-AR Interface March 2006 access router tries NUD for each of these addresses, it doesn't receive a response for CGA_1, resulting in a UPDATE message to the MAP to remove the mapping between MNID and CGA_1. MN AR MAP | | | | NS(AR->CGA_LL) | | |<-----------------------| | | NA(CGA_LL->AR) | | |----------------------->| | | NS(AR->CGA_1) | | | X <------------------| | | NS(AR->CGA_2) | | |<-----------------------| | | NA(CGA_2->AR) | | |----------------------->| | | NS(AR->CGA_3) | | |<-----------------------| | | NA(CGA_3->AR) | | |----------------------->| | | |UPDATE[DEL](MNID,CGA_1)| | |---------------------->| del_route(CGA_1) | | REPLY[OK](MNID) | | |<----------------------| | | | Figure 9: MN unconfigures a CGA MN AR MAP | | | | NS(AR->CGA_LL) | | | X <------------------| | | NS(AR->CGA_1) | | | X <------------------| | | NS(AR->CGA_2) | | | X <------------------| | | NS(AR->CGA_3) | | | X <------------------| | | | UPDATE[DEL](MNID) | | |---------------------->| del_route(CGA_LL) | | REPLY[OK](MNID) | del_route(CGA_1) | |<----------------------| del_route(CGA_2) | | | del_route(CGA_3) | | | del_bind(MNID) Laganier & Narayanan Expires September 7, 2006 [Page 14] Internet-Draft NetLMM MN-AR Interface March 2006 Figure 10: MN crashes, powers off or leaves the domain As shown in Figure 10, if the MN crashes, powers off or leaves the domain, the NUD will fail for all the associated addresses. In this case, the access router can remove the entry for the mobile node from the MAP by initiating a UPDATE message. Laganier & Narayanan Expires September 7, 2006 [Page 15] Internet-Draft NetLMM MN-AR Interface March 2006 3. Mobile Node Specification There is no few NetLMM specific requirements place on a Mobile Node in a NetLMM domain. However, for the smooth operation of the NetLMM MN-AR interface, the MN MUST behave as specified in the following documents: o Neighbor Discovery for IP version 6 [RFC2461] (MUST) and [I-D.ietf-ipv6-2461bis] (SHOULD) o IPv6 Stateless Address Autoconfiguration [RFC2462] (MUST) and [I-D.ietf-ipv6-2462bis] (SHOULD) o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [I-D.ietf-ipv6-privacy-addrs-v2] o Detecting Network Attachment in IPv6 - Best Current Practices for Hosts [I-D.ietf-dna-hosts] o Detecting Network Attachment in IPv6 - Best Current Practices for Routers [I-D.ietf-dna-routers] o Detecting Network Attachment with Unmodified Routers: A Prefix List based approach [I-D.ietf-dna-cpl] o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- protocol] o SEcure Neighbor Discovery [RFC3971] o Cryptographically Generated Addresses [RFC3972] and MUST use a single public key to generate all of their CGAs. This requirement is necessary to make it possible for the AR and MAP to bind together different addresses of the MN. That way, when a MN attaches to a new AR, the MAP will correctly updating routing for all MN CGAs even if the MN is currently using only one of those (e.g. its link-local CGA to send a router solicitation.) With respect to the MUST support [RFC2461] and [RFC2462], and SHOULD support [I-D.ietf-ipv6-2461bis] and [I-D.ietf-ipv6-2462bis], the reason is that the SEND requirements avoid complication with the "DAD once per IID" optimization of [RFC2462]. Although it might have been problematic for the AR to detect the configuration of a global address for which the MN does not perform DAD because the IID of the global address is the same than the one of a DADed link-local address, the fact that SEND is used causes IIDs from CGAs with different subnet prefixes to be different because the subnet prefixes Laganier & Narayanan Expires September 7, 2006 [Page 16] Internet-Draft NetLMM MN-AR Interface March 2006 is used as an input parameter to the CGA generation algorithm. Therefore, even per [RFC2461] and [RFC2462] the MN cannot do any optimization and MUST perform DAD for all of its configured CGAs, which allows the AR to correctly detect any address configured on the MN. Laganier & Narayanan Expires September 7, 2006 [Page 17] Internet-Draft NetLMM MN-AR Interface March 2006 4. Access Router Specification A NetLMM AR MUST behave as specified in the following documents: o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis] o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis] o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [I-D.ietf-ipv6-privacy-addrs-v2] o Detecting Network Attachment in IPv6 - Best Current Practices for Hosts [I-D.ietf-dna-hosts] o Detecting Network Attachment in IPv6 - Best Current Practices for Routers [I-D.ietf-dna-routers] o Detecting Network Attachment with Unmodified Routers: A Prefix List based approach [I-D.ietf-dna-cpl] o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- protocol] o SEcure Neighbor Discovery [RFC3971] o Cryptographically Generated Addresses [RFC3972] In addition, the AR MUST conforms to the supplementary NetLMM specific requirements which follows in this section. 4.1. Promiscuous and all-multicast modes The AR SHOULD put its external interface (the one exposed to MNs) in snooping/promiscuous mode so that it can receive most of the packets exchanged on the link it is serving. If a layer 2 switch is present between the AR and MNs, the port to which the AR is connected SHOULD be put in snooping/promiscuous mode. At the minimum, the AR MUST put its interface into a "receive all-multicast traffic" mode, and registers with MLDv2 [RFC3810] to all link-local solicited node multicast addresses to which a MN registers to with MLDv2. This insure that the AR can receive neighbor solicitations so that it can proxy solicited neighbor advertisements when the target MN is off- link. 4.2. Receiving Neighbor Discovery Messages from MN The NetLMM specific processing of received Neighbor Discovery Messages depends on whether a packet is a neighbor solicitation part Laganier & Narayanan Expires September 7, 2006 [Page 18] Internet-Draft NetLMM MN-AR Interface March 2006 of the DAD procedure, a solicited neighbor advertisement, or any other neighbor discovery message. Section 4.2.1 defines the processing rules for neighbor solicitations sent as part of the DAD procedure. Section 4.2.2 defines the processing rules for solicited neighbor advertisements. Section 4.2.3 defines the processing rules for all others ND messages. 4.2.1. Receiving DAD Neighbor Solicitations If the AR receives a DAD neighbor solicitation, and the solicitation is secure according to [RFC3971], it MUST tries to register the target address with the MAP. If the registration fails because this address is used by a different MN, the AR MUST defend the target address by sending a proxy neighbor advertisement as described in Section 4.3.2. 4.2.2. Receiving Solicited Neighbor Advertisements If the AR receives a Solicited Neighbor Advertisement for a target address which does not belong to it, and the advertisement contains both a valid CGA option as specified in Section 5.1.2. of [RFC3971], a valid RSA Signature option as specified in Section 5.2.2. of [RFC3971], and a valid Timestamp option as specified in Section 5.3.4.2. of [RFC3971], then it MUST register the target address with the MAP. 4.2.3. Receiving All Others Neighbor Discovery Messages If the AR receives any other neighbor discovery message than those enumerated above, the solicitation is secure according to [RFC3971], and the source address of the packet is not the unspecified IP address, it MUST tries to register its source address with the MAP. [ XXX do we need to defend the address if registration fails? That should not happen except in case of public key collisions... ] 4.3. Sending Neighbor Discovery Messages to MN 4.3.1. Sending Neighbor Solicitations o The AR receives from the MN a SEND-protected Neighbor Discovery message which does not allows the AR to verify the MN CGA ownership. This can occurs if the MN includes a Nonce parameter which is does not correspond to the Nonce sent by the AR to the MN, or if the MN includes a Timestamp parameters which fail because MN and AR clocks are desynchronized. o The AR receives from the MN sends an IP packet which is not a Neighbor Discovery Message before it sends a SEND-protected Laganier & Narayanan Expires September 7, 2006 [Page 19] Internet-Draft NetLMM MN-AR Interface March 2006 Neighbor Discovery message which allows the AR to verify MN CGA ownership. o The AR is performing the periodic reachability test of a MN it has precedently registered with the MAP. If the MN is unreachable, the AR MUST deregister this MN with the MAP. 4.3.2. Sending Proxy Neighbor Advertisements An AR SHOULD send a proxy neighbor advertisement to a MN performing DAD for an IP address which belongs to a MN which is known to be off- link by the AR in order to defend that address, as specified in Section 5.4. of [I-D.ietf-ipv6-2462bis]. An AR SHOULD send a proxy neighbor advertisement to a MN attempting to communicate directly with a MN (because it think its correspondent is on-link) which is known to be off-link by the AR. The "override" flag (O) should be set to 1 (one) so that an existing neighbor cache entry is replaced, as specified in Section 4.4. of [I-D.ietf-ipv6- 2461bis]. 4.3.3. Sending Router Advertisements All Prefix Information options included in router advertisements sent by an AR SHOULD have the "on-link" flag (L) set to 0 (zero.) This ensure that all packets sent by a MN are sent via the router. This is necessary to insure that a MN trying to communicate with another MN in the NetLMM domain but attached to a different AR is delivered to the AR. 4.3.4. Sending Redirects An AR SHOULD send a redirect to a MN attempting to communicate with a MN which is known to be on-link by the AR, as specified in Section 4.5. of [I-D.ietf-ipv6-2461bis]. 4.4. Receiving All Others IPv6 Packets from MN If the AR receives any other IPv6 packet than those enumerated above from a MN, and the source IP address is not registered yet with the AR, the AR MUST initiate a reachability test with the MN as specified in Section 4.3.1 to verify the MN CGA ownership. 4.4.1. Authenticated Packets If the AR receives any other IPv6 packet than those enumerated above, and the MN origin of this packet is authenticated (by another security mechanism such as 802.11i or IPsec) and tied by any means to Laganier & Narayanan Expires September 7, 2006 [Page 20] Internet-Draft NetLMM MN-AR Interface March 2006 the public key used to generate the source CGA of that packet, then the AR MAY update the MAP based on reception of such packets. [ XXX TBD. ] 4.4.2. Unauthenticated Packets Unauthenticated IPv6 packets MUST not trigger any action in the NetLMM Domain. [ XXX TBD. ] 4.5. Mobile Node Identifier used by AR All NetLMM messages generated by an AR upon reception of triggers described in this document SHOULD use the SEND public key in the MNID field of NetLMM messages. An alternative would be to use a truncated (say 128 bits) secure hash of the public key to reduce message size while keeping an equivalent security level. Laganier & Narayanan Expires September 7, 2006 [Page 21] Internet-Draft NetLMM MN-AR Interface March 2006 5. IANA Considerations There is no IANA considerations. Laganier & Narayanan Expires September 7, 2006 [Page 22] Internet-Draft NetLMM MN-AR Interface March 2006 6. Acknowledgments As usual in the IETF, this document is the result of a collaboration between many people. The authors would like to thanks James Kempf and Christian Vogt for discussion and/or comments that helped with first version of this document. Laganier & Narayanan Expires September 7, 2006 [Page 23] Internet-Draft NetLMM MN-AR Interface March 2006 7. References 7.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-05 (work in progress), October 2005. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [I-D.ietf-ipv6-2462bis] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-2462bis-08 (work in progress), May 2005. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [I-D.ietf-ipv6-privacy-addrs-v2] Narten, T., "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress), Laganier & Narayanan Expires September 7, 2006 [Page 24] Internet-Draft NetLMM MN-AR Interface March 2006 December 2005. [I-D.ietf-dna-hosts] Narayanan, S., "Detecting Network Attachment in IPv6 - Best Current Practices for hosts.", draft-ietf-dna-hosts-02 (work in progress), October 2005. [I-D.ietf-dna-routers] Narayanan, S., "Detecting Network Attachment in IPv6 - Best Current Practices for Routers", draft-ietf-dna-routers-01 (work in progress), October 2005. [I-D.ietf-dna-cpl] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix list based approach", draft-ietf-dna-cpl-02 (work in progress), January 2006. [I-D.pentland-dna-protocol] Narayanan, S., "Detecting Network Attachment in IPv6 Networks (DNAv6)", draft-pentland-dna-protocol-01 (work in progress), July 2005. [I-D.wood-netlmm-emp-base] Wood, J. and K. Nishida, "Edge Mobility Protocol (EMP)", draft-wood-netlmm-emp-base-00 (work in progress), October 2005. 7.2. Informative references [I-D.kempf-netlmm-nohost-ps] Kempf, J., "Problem Statement for IP Local Mobility", draft-kempf-netlmm-nohost-ps-01 (work in progress), January 2006. [I-D.kempf-netlmm-nohost-req] Kempf, J., "Requirements and Gap Analysis for IP Local Mobility", draft-kempf-netlmm-nohost-req-00 (work in progress), July 2005. [I-D.kempf-netlmm-threats] Kempf, J. and C. Vogt, "Security Threats to Network-based Localized Mobility Management", draft-kempf-netlmm-threats-00 (work in progress), February 2006. Laganier & Narayanan Expires September 7, 2006 [Page 25] Internet-Draft NetLMM MN-AR Interface March 2006 Authors' Addresses Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany Phone: +49 89 56824 231 Email: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/ Sathya Narayanan Panasonic Digital Networking Lab Two Research Way, 3rd Floor Princeton, NJ 08536 USA Phone: +1 609 734 7599 Email: sathya@research.panasonic.com Laganier & Narayanan Expires September 7, 2006 [Page 26] Internet-Draft NetLMM MN-AR Interface March 2006 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 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 Internet Society (2006). 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. Laganier & Narayanan Expires September 7, 2006 [Page 27]