Network Working Group J. Laganier Internet-Draft DoCoMo Euro-Labs Expires: December 28, 2006 S. Narayanan Panasonic F. Templin Boeing Phantom Works June 26, 2006 Network-based Localized Mobility Management Interface between Mobile Node and Access Router draft-ietf-netlmm-mn-ar-if-01 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 December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies an IP layer interface between mobile nodes Laganier, et al. Expires December 28, 2006 [Page 1] Internet-Draft NetLMM MN-AR Interface June 2006 (MN) and access routers (AR) of a network-based localized mobility 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 using the SEND public key as the MN identifier, while being solely based on standard track IPv6 protocols (DNA and SEND.) 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.1.1. SLAAC Method . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. DHCP Method . . . . . . . . . . . . . . . . . . . . . 10 2.2. First attachment of MN moving into a new NetLMM domain . . 11 2.2.1. SLAAC Method . . . . . . . . . . . . . . . . . . . . . 11 2.2.2. DHCP Method . . . . . . . . . . . . . . . . . . . . . 13 2.3. MN handovers in a NetLMM-domain . . . . . . . . . . . . . 13 2.3.1. MN using SLAAC getting handover hint . . . . . . . . . 13 2.3.2. MN using DHCP getting handover hint . . . . . . . . . 14 2.3.3. AR getting handover hint . . . . . . . . . . . . . . . 15 2.4. MN configuring additional CGAs/prefixes . . . . . . . . . 16 2.5. MN configuring CGA that is in use by another MN in the NetLMM domain . . . . . . . . . . . . . . . . . . . . . . 16 2.5.1. MN using SLAAC configuring colliding CGA . . . . . . . 16 2.5.2. MN using DHCP configuring colliding global CGA . . . . 17 2.6. MN unconfigures CGAs, powers off, crashes or leaves the domain . . . . . . . . . . . . . . . . . . . . . . . . 17 3. MN Specification . . . . . . . . . . . . . . . . . . . . . . . 20 4. AR Specification . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Promiscuous and all-multicast modes . . . . . . . . . . . 22 4.2. Receiving ND Messages from MN . . . . . . . . . . . . . . 23 4.2.1. Receiving DAD NSs . . . . . . . . . . . . . . . . . . 23 4.2.2. Receiving All Others ND Messages . . . . . . . . . . . 23 4.3. Sending ND Messages to MN . . . . . . . . . . . . . . . . 23 4.3.1. Sending NSs . . . . . . . . . . . . . . . . . . . . . 23 4.3.2. Sending Proxy NAs . . . . . . . . . . . . . . . . . . 24 Laganier, et al. Expires December 28, 2006 [Page 2] Internet-Draft NetLMM MN-AR Interface June 2006 4.3.3. Sending RAs . . . . . . . . . . . . . . . . . . . . . 24 4.3.4. Sending Redirects . . . . . . . . . . . . . . . . . . 24 4.4. Receiving All Other IPv6 Packets from MN . . . . . . . . . 24 4.4.1. Authenticated Packets . . . . . . . . . . . . . . . . 24 4.4.2. Unauthenticated Packets . . . . . . . . . . . . . . . 24 4.4.3. Forwarding Packets . . . . . . . . . . . . . . . . . . 25 4.5. MN Identifier and IP addresses . . . . . . . . . . . . . . 25 5. Multilink Subnet Considerations . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative references . . . . . . . . . . . . . . . . . . . 29 8.2. Informative references . . . . . . . . . . . . . . . . . . 30 Appendix A. Version history . . . . . . . . . . . . . . . . . . . 32 A.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 34 Laganier, et al. Expires December 28, 2006 [Page 3] Internet-Draft NetLMM MN-AR Interface June 2006 1. Introduction It is suggested in [I-D.ietf-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.ietf-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 need to be adapted to the NetLMM protocol proposal chosen by the working group. Because the NetLMM protocol is network based, the mobile node (MN) 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 (AR.) Because the IPv6 MN will use a vanilla IPv6 stack, the interface between a MN and its AR 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 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 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 specifies an IP layer interface between MNs and ARs of Laganier, et al. Expires December 28, 2006 [Page 4] Internet-Draft NetLMM MN-AR Interface June 2006 a 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 using the SEND public key as the MN identifier, while being solely based on standard track IPv6 protocols (DNA and SEND.) 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]. The following terms are defined within the scope of this document: Mobile Node (MN) an IPv6 node moving in the NetLMM domain. Access Router (AR) a default router that connects the MN to the NetLMM domain. access interface a network interface of an AR attached to the link used by the MN. Mobility Anchor Point (MAP) a router located in the NetLMM domain that handles packet exchanges with nodes in the domain. Network-based Localized Mobility Management Domain (NetLMM domain) an administrative domain spanning links served by a set of MAPs (and their associated ARs and MNs) that provision addresses from the same IP subnet prefix(es). Network-based Localized Mobility Management Protocol (NLMP) The NetLMM Protocol used in the backhaul of the NetLMM domain between ARs and MAP. 1.2. Abbreviations The following abbreviations are used throughout this document: NetLMM: Network-based Localized Mobility Management Laganier, et al. Expires December 28, 2006 [Page 5] Internet-Draft NetLMM MN-AR Interface June 2006 ND: Neighbor Discovery. NS: Neighbor Solicitation. NA: Neighbor Advertizement. RS: Router Solicitation. RA: Router Advertisement. NDP: Neighbor Discovery Protocol. SLAAC: StateLess Address AutoConfiguration DHCP: Dynamic Host Configuration Protocol SEND: SEcure Neighbor Discovery. DNA: Detecting Network Attachment. 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: MN 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 MN and an AR of a NetLMM domain. In the absence of link-layer specific mechanism, it allows the AR and/or MN to detect network attachment, causing the AR to use NLMP to update routing at the MAP so that the MN stays reachable when it roams across the NetLMM domain. Laganier, et al. Expires December 28, 2006 [Page 6] Internet-Draft NetLMM MN-AR Interface June 2006 /-------------------------\ / Internet \ \ / \-------+---------+-------/ | | /-------+---------+-------\ ---- / \ ^ / +-----+ \ | | | MAP |-+ | N | +-----+ |-+ | E | +-----+ | | T | +-----+ | L | Backhaul Network | M | +-----+ +-----+ | M |- - | AR1 | ..... | ARn | - -| | +-----+ +-----+ | d | / \ Access / \ | o | / \ Network / \ | m | / \ / \ | a | +----+ | i | | MN | -------> | n \ +----+ AR change / | \ / v \-------------------------/ ---- Figure 1: Reference Network Diagram The deployment scenario is shown in Figure 1 above: Several ARs are attached to an IP routing domain connected to the outside Internet via a MAP. The MNs, ARs, MAPs, and in-between routing fabric constitute the NetLMM domain. Each AR announces on its access interface a common set of prefix(es) which are routed to the MAP from the outside Internet. Packets arriving at the MAP and destined to a MN are tunneled to the appropriate AR. 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 ND, DHCP, SEND, and DNA. Interactions of these components with NetLMM are represented in Figure 2 below (note that hints received by DNA from other layers are omitted for clarity): Laganier, et al. Expires December 28, 2006 [Page 7] Internet-Draft NetLMM MN-AR Interface June 2006 MN|AR Interface | | +------------+ +----------+ | | | | | | +--------+ | NLMP | +------+ | | | NetLMM |<-------->|NetLMM| | | | +--------+ | | +------+ | | ^ ^ | | ^ | +----------+ | | | | | | | | | | | v | | | | | | +------+ | | | +-----+ | | | | | | | DNA | | NDP/DHCP | | DNA | | | | | | | | SEND |<------|------>|SEND | | | | | | | | ND | | | | ND | | | | | | | | DHCP | | | | |DHCP | | | | | | | +------+ | | +-----+ | | | | | | ^ | | | ^ | | | | | | | | | | | | | | | | v | | | v | | | v | | +------+ | | +----+ | | | +------+ | | | | | | | | |<-+ | | | | | | | | | IPv6 | | | | IPv6 | | | | | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | | +------+ | | +----+ | | +------+ | | | | | | | | | MN | | AR | | MAP | +----------+ | +------------+ +----------+ | Figure 2: NetLMM Component Interactions Laganier, et al. Expires December 28, 2006 [Page 8] Internet-Draft NetLMM MN-AR Interface June 2006 2. Protocol Overview The following subsections present the different situations in which an IP-based MN-AR interface is used to trigger the NetLMM protocol. In the 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 an NS with a fresh nonce, to which the MN would reply with an NA containing the same fresh nonce. 2.1. MN powers on in a NetLMM domain 2.1.1. SLAAC Method MN AR MAP | | | | NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) | |----------------------->|---------------------->| bind(CGA_LL,MNID) | |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR) | |<----------------------| |RS(CGA_LL->All_routers) | | |----------------------->| | | RA(AR->{MN,All_nodes}) | | |<-----------------------| | | | | | NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) | |----------------------->|---------------------->| bind(CGA_1,MNID) | | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR) | |<----------------------| | | | | NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) | |----------------------->|---------------------->| bind(CGA_2,MNID) | | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR) | |<----------------------| | | | Figure 3: MN powers on and configures a Link-Local and two Global Unicast CGAs using SLAAC As shown in Figure 3 above, when a MN using SLAAC 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 NS(DAD) message generated will contain the public key in the CGA option as defined by SEND [RFC3971]. Upon reception of this NS message, the AR MUST generate an UPDATE to the MAP with the Laganier, et al. Expires December 28, 2006 [Page 9] Internet-Draft NetLMM MN-AR Interface June 2006 public key as the MNID along with CGA_LL. The MAP MUST bind the CGA_LL to the MNID and establish a route binding for the CGA_LL to the AR. The MAP acknowledges the receipt of the UPDATE message. While waiting for the completion of DAD, the MN may generate an RS message as per [RFC2461] with the unspecified address as the source address. Such a message will not contain a CGA option. The AR will respond with a multicast RA as per [RFC2461]. Alternatively, the MN will wait for completion of DAD and generate an RS message with its CGA-LL as the source address. With the prefix information received in the RA message, the MN can 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 NS(DAD) received from the MN, the AR will generate an UPDATE message to the MAP establishing binding in the MAP. The use of multicast RAs may however not be acceptable in all NetLMM domains, e.g., when multiple MAPs and/or prefixes are used. In that case, the network has to somehow force the MN to source RSs from its CGA-LL, so that the AR can send to that CGA-LL a unicast RA containing the appropriate prefix information. This can be achieved by having the AR simply discard any RS sourced from the unspecified address, so that eventually the MN will complete DAD for its CGA-LL and start to use it as a source address while retransmitting RSs. 2.1.2. DHCP Method MN AR MAP | | | | NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) | |----------------------->|---------------------->| bind(CGA_LL,MNID) | |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR) | |<----------------------| |RS(CGA_LL->All_routers) | | |----------------------->| | | RA(AR->{MN,All_nodes}) | | |<-----------------------| | | | | | DHCP SOLICIT(CGA_*) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| bind(CGA_1,MNID) | DHCP REPLY(STATUS) | REPLY[OK](MNID,CGA_*) | route(CGA_1->AR) |<-----------------------|<----------------------| route(CGA_2->AR) | | | Figure 4: MN powers on and configures a Link-Local and two Global Unicast CGAs using DHCP with two-message exchange Laganier, et al. Expires December 28, 2006 [Page 10] Internet-Draft NetLMM MN-AR Interface June 2006 As shown in Figure 4 above, when a MN using DHCP powers on for the first time it will cryptographically generate a CGA_LL and perform an RS/RA exchange as specified for the SLAAC method in Section 2.1.1. The MN will then use its public key to generate a DHCP Unique Identifier (DUID) and Identity Association (IA) per ([RFC3315], Sections 9 and 10). If prefix information is included in the RA message, the MN can next cryptographically generate one or more global addresses (CGA_*). (The MN can additionally request delegation of prefixes per [RFC3633].) The MN will then issue a DHCP SOLICIT message including the DUID, IA and IA Address options that encode any CGA_*s as options. (Alternatively, the MN can omit IA Address options and allow the network to delegate non-CGA addresses.) If a two-message exchange is preferred, the MN will also include a Rapid Commit option in the DHCP SOLICIT per ([RFC3315], Section 17.1.2). When the AR receives the DHCP SOLICIT (using two-message exchange) or DHCP REQUEST (using four-message exchange), it performs the same UPDATE/REPLY procedure as specified in Section 2.1.1, and returns a DHCP REPLY message with an appropriate status code to the MN. The issues involved with the use of multicast RAs as described in Section 2.1.1 might be valid when DHCP is used for address configuration. 2.2. First attachment of MN moving into a new NetLMM domain 2.2.1. SLAAC Method Laganier, et al. Expires December 28, 2006 [Page 11] Internet-Draft NetLMM MN-AR Interface June 2006 MN AR MAP | | | | RS | UPDATE(MNID,CGA_LL) | |---------------------->|---------------------->| bind(CGA_LL,MNID) | RA |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR) |<----------------------|<----------------------| | NS(DAD:CGA_LL) | | |---------------------->| | | | | | | | | NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) | |---------------------->|---------------------->| bind(CGA_1,MNID) | | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR) | |<----------------------| | | | | NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) | |---------------------->|---------------------->| bind(CGA_2,MNID) | | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR) | |<----------------------| | | | Figure 5: MN moves into a NetLMM domain and configures a Link-Local and two Global Unicast CGAs using SLAAC As shown in Figure 5 above, when a MN using SLAAC 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 an RS message. When the MN receives an RA message in response, it will figure out that it has changed to a link in a new NetLMM domain as defined by the DNA specification [I-D.pentland-dna-protocol]. Once the MN realizes it has changed to a new NetLMM domain, 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 global address configuration procedures of the MN, AR and MAP are the same as specified in Section 2.1.1. Laganier, et al. Expires December 28, 2006 [Page 12] Internet-Draft NetLMM MN-AR Interface June 2006 2.2.2. DHCP Method MN AR MAP | | | |RS(CGA_LL->All_routers)| UPDATE(MNID,CGA_LL) | |---------------------->|---------------------->| bind(CGA_LL,MNID) | RA |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR2) |<----------------------|<----------------------| | NS(DAD:CGA_LL) | | |---------------------->| | | | | | DHCP SOLICIT(CGA_*) | UPDATE(MNID,CGA_*) | |---------------------->|---------------------->| bind(CGA_1,MNID) | DHCP REPLY(STATUS) | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR) |<----------------------|<----------------------| route(CGA_2->AR) | | | Figure 6: MN moves into a NetLMM domain and configures a Link-Local and two Global Unicast CGAs using DHCP As shown in Figure 6 above, when a MN using DHCP 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 an RS message. When the MN receives an RA message in response, it will figure out that it has changed to a link in a new NetLMM domain as defined by the DNA specification [I-D.pentland-dna-protocol] and/or by sending a DHCP CONFIRM message as specified in Section 2.3.2. Once the MN realizes it has changed to a new NetLMM domain, it will discard its current IP addresses and will execute DAD for its link-local address and configure new global addresses/ prefixes using DHCP. The global address configuration procedures of the MN, AR and MAP are the same as specified in Section 2.1.2. 2.3. MN handovers in a NetLMM-domain 2.3.1. MN using SLAAC getting handover hint Laganier, et al. Expires December 28, 2006 [Page 13] Internet-Draft NetLMM MN-AR Interface June 2006 MN AR MAP | | | |RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| route(CGA_LL->AR) | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR) | RA(AR->CGA_LL) | CGA_1,CGA_2) | route(CGA_2->AR) |<-----------------------|<----------------------| | | | Figure 7: MN using SLAAC getting handover hint and receives a unicast RA As shown in Figure 7, when MN using SLAAC moves within the NetLMM domain, it will send an RS message with the source address as its link-local address as specified by [I-D.pentland-dna-protocol]. The AR again can use the public key in the CGA option to infer the MNID and send UPDATEs to the MAP. If the AR chooses to respond with a unicast RA, all required steps are done. MN AR MAP | | | |RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| route(CGA_LL->AR) | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR) | RA(AR->All_nodes) | CGA_1,CGA_2) | route(CGA_2->AR) |<-----------------------|<----------------------| | NS(CGA_LL->AR) | | |----------------------->| | | NA(AR->CGA_LL) | | |<-----------------------| | | | | Figure 8: MN using SLAAC getting handover hint and receives a multicast RA In a similar scenario, as shown in Figure 8, if the AR chooses to respond with a multicast RA, the MN will send an NS to learn about the AR and confirm reachability. 2.3.2. MN using DHCP getting handover hint When a MN using the DHCP access method moves within the NetLMM domain, it receives the same handover hints as specified in Section 2.3.1. Laganier, et al. Expires December 28, 2006 [Page 14] Internet-Draft NetLMM MN-AR Interface June 2006 MN AR MAP | | | | DHCP CONFIRM(CGA_*) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| route(CGA_LL->AR) | DHCP REPLY(STATUS) | REPLY[OK](MNID,CGA_*) | route(CGA_1->AR) |<-----------------------|<----------------------| route(CGA_2->AR) | | | Figure 9: DHCP CONFIRM message exchange As shown in Figure 9, when the MN figures out that it has changed link, it sends a DHCP CONFIRM message containing its IA and all of the CGAs/prefixes it has previously registered per ([RFC3315], Section 18.1.2). The AR will generate an UPDATE message to the MAP and will send a DHCP REPLY message to the MN with appropriate status codes. 2.3.3. AR getting handover hint MN AR MAP | | | | NS(AR->CGA_*) | | |<-----------------------| | | NA(CGA_*->AR) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| route(CGA_LL->AR) | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR) | | CGA_1,CGA_2) | route(CGA_2->AR) | |<----------------------| | | | Figure 10: AR getting handover hint of MN whose IP address is known As shown in Figure 10, instead of the MN receiving the hint in scenarios where the AR receives the hint with the IP address of the handing over MN, the AR can send an 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 an UPDATE message to the MAP. Laganier, et al. Expires December 28, 2006 [Page 15] Internet-Draft NetLMM MN-AR Interface June 2006 MN AR MAP | | | | RA(AR->All_nodes) | | |<-----------------------| | | NS(CGA_*->AR) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| route(CGA_LL->AR) | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR) | NA(AR->CGA_*) | CGA_1,CGA_2) | route(CGA_2->AR) |<-----------------------|<----------------------| | | | Figure 11: AR getting handover hint of MN whose IP address is unknown As shown in Figure 11, if the AR 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 AR and confirm its reachability by initiating an NS message to the AR. The AR can then send an UPDATE message to the MAP based on the public key in the NS message. 2.4. MN configuring additional CGAs/prefixes If the MN chooses to configure new global addresses/prefixes at any point in time, it will contact the AR to configure the new addresses/ prefixes as specified in Section 2.1. 2.5. MN configuring CGA that is in use by another MN in the NetLMM domain 2.5.1. MN using SLAAC configuring colliding CGA MN1 AR1 MAP AR2 MN2 | | | | | | NS(DAD) |UPDATE(MNID,CGA,NS)| | | |-------->|------------------>| collision(MNID) | | | | | | | | | | QUERY[DAD](NS) | NS(DAD) | | | |---------------->|-------->| | | | REPLY[DAD](NA) | NA | | | |<----------------|<--------| | NA |REPLY[COLLIDE](NA) | |<--------|<------------------| | | | Figure 12: MN using SLAAC configuring a colliding CGA Laganier, et al. Expires December 28, 2006 [Page 16] Internet-Draft NetLMM MN-AR Interface June 2006 As shown in Figure 12, AR1 learns about new global addresses configured by an MN MN1 from the NS(DAD) message sent by MN1. When AR1 sends an UPDATE to the MAP based on this NS(DAD), it also includes the entire NS in the message, and waits for a positive acknowledgment from the MAP. If the MAP has an entry for the same CGA with a different MNID, it will proxy this NS(DAD) up to the AR where the duplicate occurs (AR2). AR2 will then proxy the NS(DAD) by sending it to the solicited-node multicast address of the colliding MN MN2, and will receive back a signed NA from MN2. AR2 will then forward this signed NA to AR1 via the MAP. At that point, AR1 can securely defend the duplicate address on behalf of MN2 by sending to MN1 the signed NA. 2.5.2. MN using DHCP configuring colliding global CGA MN AR MAP | | | | DHCP SOLICIT(CGA_*) | UPDATE(MNID,CGA_*) | |----------------------->|---------------------->| collision(CGA_*) | DHCP REPLY(status) | REPLY[COLLIDE](CGA_*) | |<-----------------------|<----------------------| | | | Figure 13: MN using DHCP configuring a colliding global CGA As shown in Figure 13, when a MN using DHCP configures one or more global CGAs, the MAP sends a REPLY to the AR with an indication for each global CGA that collided. The AR then sends a DHCP REPLY message to the MN with the appropriate status code for each colliding CGA. 2.6. MN unconfigures CGAs, powers off, crashes or leaves the domain The AR SHOULD do periodic reachability testing with the MN using 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. Laganier, et al. Expires December 28, 2006 [Page 17] Internet-Draft NetLMM MN-AR Interface June 2006 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 14: MN unconfigures a CGA As shown in Figure 14, the MN stops using the address CGA_1 and when the AR tries NUD for each of these addresses, it doesn't receive a response for CGA_1, resulting in an UPDATE message to the MAP to remove the mapping between MNID and CGA_1. 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) Figure 15: MN crashes, powers off or leaves the domain Laganier, et al. Expires December 28, 2006 [Page 18] Internet-Draft NetLMM MN-AR Interface June 2006 As shown in Figure 15, if the MN crashes, powers off or leaves the domain, the NUD will fail for all the associated addresses. In this case, the AR can remove the entry for the MN from the MAP by initiating an UPDATE message. Laganier, et al. Expires December 28, 2006 [Page 19] Internet-Draft NetLMM MN-AR Interface June 2006 3. MN Specification NetLMM place few specific requirements on an MN 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] Also, for MNs attached to networks that use DHCP, the MN MUST support the DHCP client message exchanges specified in: o Dynamic Host Configuration Protocol for IPv6 [RFC3315] The MN MUST use a single public key to generate all of its 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 update routing for all MN CGAs even if the MN is currently using only one of those (e.g. its link-local CGA) to send an RS. 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 SEND avoids complication with the "DAD once per IID" optimization of [RFC2462]. This is because IIDs of CGAs with different subnet prefixes are different (subnet prefix is used as an Laganier, et al. Expires December 28, 2006 [Page 20] Internet-Draft NetLMM MN-AR Interface June 2006 input parameter to the CGA generation algorithm.) For NBMA links, links over which multicast is not well supported or for selection of specific neighbors, MNs and ARs can send packets addressed to the pre-defined multicast addresses specified in ([RFC4291], Section 2.7.1) to the Layer-2 unicast address(es) of one or more neighbors. Laganier, et al. Expires December 28, 2006 [Page 21] Internet-Draft NetLMM MN-AR Interface June 2006 4. AR 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] Also, ARs MUST respond to DHCP client messages in a manner that is consistent with the DHCP relay/server messaging specified in: o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] In addition, the AR MUST conform to the supplementary NetLMM specific requirements which follow in this section. 4.1. Promiscuous and all-multicast modes The AR SHOULD put its access 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 insures that the AR can receive NSs so that it can proxy solicited NAs when the target MN is off-link. Laganier, et al. Expires December 28, 2006 [Page 22] Internet-Draft NetLMM MN-AR Interface June 2006 4.2. Receiving ND Messages from MN The NetLMM specific processing of received ND Messages depends on whether a packet is an NS part of the DAD procedure, or any other ND message. Section 4.2.1 defines the processing rules for NSs sent as part of the DAD procedure. Section 4.2.2 defines the processing rules for all others ND messages. 4.2.1. Receiving DAD NSs If the AR receives a DAD NS which is secure according to [RFC3971], it MUST try 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 NA as described in Section 4.3.2. 4.2.2. Receiving All Others ND Messages If the AR receives any other ND message than those enumerated above, the message is secure according to [RFC3971], and the source address of the packet is not the unspecified address, it MUST try to register its source address with the MAP. 4.3. Sending ND Messages to MN 4.3.1. Sending NSs An AR sends an NS to a MN in the following cases: o The AR receives from the MN a SEND-protected ND message which does not allow the AR to verify the MN CGA ownership. This can occur if the MN includes a Nonce parameter which does not correspond to the Nonce sent by the AR to the MN, or if the MN includes a Timestamp parameter which fails because the MN and AR clocks are desynchronized. o The AR receives from the MN an IP packet which is not a ND or DHCP Message before the MN registers the IP packet's source address. 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. In all the cases described above, the AR MUST verify MN CGA ownership by sending to the MN CGA an NS message including the MN CGA as a target address and a fresh Nonce. Laganier, et al. Expires December 28, 2006 [Page 23] Internet-Draft NetLMM MN-AR Interface June 2006 4.3.2. Sending Proxy NAs An AR SHOULD send a proxy NA 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]. To allow SEND MNs to accept proxy NS sent by the AR, the AR should follow the procedure described in Figure 12. 4.3.3. Sending RAs All Prefix Information options included in RAs sent by an AR SHOULD have the "on-link" flag (L) set to 0 (zero.) This ensures that all packets sent by a MN are sent via the AR. When the RAs contain no Prefix Information options, or when the MN wishes to procure additional prefixes, the MN can use DHCP prefix delegation mechanisms per [RFC3633]. 4.3.4. Sending Redirects An AR SHOULD NOT send a redirect message ([I-D.ietf-ipv6-2461bis], Section 8.2) unless it can determine that the sending node and better first-hop node reside on the same link and will remain on the same link. 4.4. Receiving All Other 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 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. 4.4.2. Unauthenticated Packets Unauthenticated IPv6 packets MUST NOT trigger any action in the NetLMM Domain. Laganier, et al. Expires December 28, 2006 [Page 24] Internet-Draft NetLMM MN-AR Interface June 2006 4.4.3. Forwarding Packets [RFC4291] states that: ARs MUST NOT forward any packets with Link-Local source or destination addresses to other links. Link-Local multicast scope spans the same topological region as the corresponding unicast scope. This specification does not modify that behavior, i.e. an AR MUST NOT forward packets sent by a MN from or to a link-local address (unicast or multicast). 4.5. MN Identifier and IP addresses All NLMP messages generated by an AR upon reception of triggers described in this document SHOULD use the SEND public key in the MNID field of NLMP 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. This public key MNID is hence securely bound to the set of IP addresses used by the MN, therefore preventing different redirection attacks. In some deployments where MNs do not use ND and SEND (e.g. some cellular systems [RFC3316]), ARs and MAPs in the NetLMM domain SHOULD enforce the binding between an authenticated MN identity and the set of IP addresses used by the MN. In other words the network keeps track of IP addresses allocated to a specific MN identity. In the case of DHCP address allocation, DHCP requests and replies should be protected by a link-layer security context indexed by the authenticated MN identity. Laganier, et al. Expires December 28, 2006 [Page 25] Internet-Draft NetLMM MN-AR Interface June 2006 5. Multilink Subnet Considerations Multilink subnet issues are analyzed in [I-D.thaler-intarea- multilink-subnet-issues]. When each MN assigns addresses from separate IP prefixes, (e.g., per [I-D.thaler-autoconf-multisubnet-manets]) there are no multilink subnet issues. When multiple MNs assign addresses from a shared IP prefix, multilink subnet issues can be avoided if ARs and MAPs act as neighbor discovery proxies as described in Figure 12, and ARs do not advertize subnet prefixes as "on-link" as described in Section 4.3.3. Laganier, et al. Expires December 28, 2006 [Page 26] Internet-Draft NetLMM MN-AR Interface June 2006 6. IANA Considerations There are no IANA considerations. Laganier, et al. Expires December 28, 2006 [Page 27] Internet-Draft NetLMM MN-AR Interface June 2006 7. Acknowledgments As usual in the IETF, this document is the result of a collaboration between many people. The authors would like to thanks (in alphabetical order) James Kempf, Alexandru Petrescu and Christian Vogt for discussion and/or comments that helped with first version of this document. Ian Chakeres contributed the reference network diagram. Portions of this work were supported by the Boeing IRAD program and Boeing colleagues. Julien Laganier is partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. Laganier, et al. Expires December 28, 2006 [Page 28] Internet-Draft NetLMM MN-AR Interface June 2006 8. References 8.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-07 (work in progress), May 2006. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [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. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Laganier, et al. Expires December 28, 2006 [Page 29] Internet-Draft NetLMM MN-AR Interface June 2006 [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), December 2005. [I-D.ietf-dna-hosts] Narayanan, S., "Detecting Network Attachment in IPv6 - Best Current Practices for hosts.", draft-ietf-dna-hosts-03 (work in progress), May 2006. [I-D.ietf-dna-routers] Narayanan, S., "Detecting Network Attachment in IPv6 - Best Current Practices for Routers", draft-ietf-dna-routers-02 (work in progress), March 2006. [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. [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. 8.2. Informative references [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003. [I-D.ietf-netlmm-nohost-ps] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work in progress), June 2006. Laganier, et al. Expires December 28, 2006 [Page 30] Internet-Draft NetLMM MN-AR Interface June 2006 [I-D.ietf-netlmm-nohost-req] Kempf, J., "Goals for Network-based Localized Mobility Management (NETLMM)", draft-ietf-netlmm-nohost-req-01 (work in progress), April 2006. [I-D.ietf-netlmm-threats] Kempf, J. and C. Vogt, "Security Threats to Network-based Localized Mobility Management", draft-ietf-netlmm-threats-00 (work in progress), April 2006. [I-D.thaler-intarea-multilink-subnet-issues] Thaler, D., "Issues With Protocols Proposing Multilink Subnets", draft-thaler-intarea-multilink-subnet-issues-00 (work in progress), March 2006. [I-D.thaler-autoconf-multisubnet-manets] Thaler, D., "Multi-Subnet MANETs", draft-thaler-autoconf-multisubnet-manets-00 (work in progress), February 2006. Laganier, et al. Expires December 28, 2006 [Page 31] Internet-Draft NetLMM MN-AR Interface June 2006 Appendix A. Version history A.1. -00 to -01 o added DHCP access method including DHCP prefix delegation. o added new network reference diagram. o added definitions for NetLMM domain and NLMP. o updated NA proxying method for colliding CGAs. o added text on sending IP multicast messages to a Layer-2 unicast address. o added new Section 4.5 text on MNID/IP address binding. o added new Section 5. on multilink subnet issues. o various editorial changes." Laganier, et al. Expires December 28, 2006 [Page 32] Internet-Draft NetLMM MN-AR Interface June 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 Fred L. Templin Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: fred.l.templin@boeing.com Laganier, et al. Expires December 28, 2006 [Page 33] Internet-Draft NetLMM MN-AR Interface June 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, et al. Expires December 28, 2006 [Page 34]