Mobility Extensions for IPv6 R. Droms (MEXT) P. Thubert Internet-Draft Cisco Intended status: Standards Track F. Dupont Expires:FebruaryJune 23, 2011 ISC W. Haddad Ericsson CJ. Bernardos UC3MAugust 22,December 20, 2010 DHCPv6 Prefix Delegation for NEMOdraft-ietf-mext-nemo-pd-06draft-ietf-mext-nemo-pd-07 Abstract One aspect of network mobility support is the assignment of a prefix or prefixes to aMobile Router (MR)mobile router for use on the links in theNEMO.mobile network. This document specifies how DHCPv6 prefix delegation can be used for this configuration task. The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router. When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire onFebruaryJune 23, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DHCPv6 Prefix Delegation of Mobile Network Prefixes . . . . . 4 3.1. Exchanging DHCPv6 messages when theMRmobile router is not at home . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Relay agent configuration . . . . . . . . . . . . . .67 3.1.2. Transmission of DHCPv6 messages . . . . . . . . . . .78 3.1.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . .78 3.2. Exchanging DHCPv6 messages whenMRthe mobile router is at home . . . . . .7 3.3. Selecting an HA that provides DHCPv6PD. . . . . . . . . . . . . . . . . . . 8 3.3. Selecting a home agent that provides DHCPv6PD . . . . . . 9 3.4. Minimizing DHCPv6PD messages . . . . . . . . . . . . . . .910 3.5. Other DHCPv6 functions . . . . . . . . . . . . . . . . . .910 4. Security Considerations . . . . . . . . . . . . . . . . . . .910 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .1112 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .1112 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . .1112 7.1. Revision -00 . . . . . . . . . . . . . . . . . . . . . . .1112 7.2. Revision -01 . . . . . . . . . . . . . . . . . . . . . . .1112 7.3. Revision -02 . . . . . . . . . . . . . . . . . . . . . . .1113 7.4. Revision -04 . . . . . . . . . . . . . . . . . . . . . . .1213 7.5. Revision -05 . . . . . . . . . . . . . . . . . . . . . . .1213 7.6. Revision -06 . . . . . . . . . . . . . . . . . . . . . . .1214 7.7. Revision -07 . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .1214 8.1. Normative References . . . . . . . . . . . . . . . . . . .1214 8.2. Informative References . . . . . . . . . . . . . . . . . .1315 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .1315 1. Introduction One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router for use on the links in the NEMO. DHCPv6 prefix delegation[RFC3633](DHCPv6PD) [RFC3633] can be used for this configuration task. The model of operation of DHCPv6PD for prefix delegation is as follows [RFC3633]. A delegating router is provided IPv6 prefixes to be delegated to requesting routers. A requesting router requests prefix(es) from the delegating router. The delegating router chooses prefix(es) for delegation, and responds with prefix(es) to the requesting router. The requesting router is then responsible for the delegated prefix(es). Note that DHCPv6 options for prefix delegation defined in [RFC3633] have been defined for general use across routers, and not only for mobile routers running the NEMO Basic Support protocol [RFC3963]. To use DHCPv6PD as prefix assignment mechanism in mobile networks, when the mobile router is located at home the home agent assumes the role of the delegating router and the mobile router assumes the role of the requesting router. However, when the mobile router is away from home, in addition to the roles when the mobile router is located at home, the mobile router also assumes the role of a DHCPv6 relay agent co-located with the requesting router function. The DHCPv6PD server running at the home agent is provisioned with prefixes to be assigned using any of the prefix assignment mechanisms described in the DHCPv6PD specification [RFC3633]. 2. 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 [RFC2119]. The following terms used in this document are defined in the IPv6 Addressing Architecture document [RFC4291]: Link-Local Unicast address Link-Local Scope Multicast address The following terms used in this document are defined in the Mobile IPv6 specification [I-D.ietf-mext-rfc3775bis]: Home Agent (HA) Home Link Home Address (HoA) Care-of Address (CoA) Binding Update (BU) Binding Acknowledgement (BA) The following terms used in this document are defined in the Mobile Network terminology document [RFC4885]: Mobile Router (MR) Mobile Network (NEMO) Mobile Network Prefix (MNP) The following terms used in this document are defined in the DHCPv6 [RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications: Delegating Router (DR; acts as a DHCPv6 server) Requesting Router (RR; acts as a DHCPv6 client) DHCPv6 Relay Agent (DRA) The following acronym is used in this document: DHCPv6PD: DHCPv6 Prefix Delegation 3. DHCPv6 Prefix Delegation of Mobile Network Prefixes The NEMO Basic Support protocol [RFC3963] extends the Mobile IPv6 protocol [I-D.ietf-mext-rfc3775bis] to enable network mobility.In this extension, an MR usesWith the NEMO Basic Support protocol a mobile router uses Mobile IPv6protocolto establish and maintain a session with itsHA,home agent, and uses bidirectional tunneling between theMRmobile router andHAthe home agent to provide a path through which nodes attached to links in theNEMOmobile network can maintain connectivity with nodes not in the NEMO. The requirements forNEMONetwork Mobility [RFC4885] include the ability of theMRmobile router to receive delegated prefixes that can then be assigned to links in theNEMO.mobile network. DHCPv6PD can be used to meet this requirement for prefix delegation. To use DHCPv6PD forNEMOs,mobile networks, when theHAmobile router is located at home the home agent assumes the role of theDR,delegating router and theMRmobile router assumes the role of theRRrequesting router. However, when the mobile router is away from home, in addition to the roles when the mobile router is located at home,andthe mobile router also assumes the role of aDRA co-locatedDHCPv6 relay agent co- located with theRR function, when the MR is away from home.requesting router function. When theMRmobile router is not at home, theHAhome agent andMRthe mobile router exchange DHCPv6PD protocol messages as specified inRFC3775bis.[I-D.ietf-mext-rfc3775bis]. This means that the messages sent by theMRmobile router MUST include the Home Address destination option and messages sent by theHAhome agent MUST make use of a Routing Header type 2. See Figure 1 for the deployment topologies when the MR is at home and when it is visiting a foreign network. ------ ------ | MR |----------------| HA | |(RR)| (home network) |(DR)| ------ ------ ------- /-----------\ ------ | MR |----| Internet |-----| HA | |(RR) | \-----------/ |(DR)| |(DRA)| ------ ------- (visited network) Figure 1: Deployment topologies of the use of DHCPv6PD for delegation ofMNPsMobile Network Prefixes The DHCPv6PD server is provisioned with prefixes to be assigned using any of the prefix assignment mechanisms described in the DHCPv6PD specifications. Other updates to theHAhome agent data structures required as a side effect of prefix delegation are specified by the particular network mobility protocol. For example, in the case of NEMO Basic Network Mobility Support [RFC3963], the HA would add an entry in its binding cache registering the delegated prefix to theMRmobile router to which the prefix was delegated. 3.1. Exchanging DHCPv6 messages when theMRmobile router is not at home The case when theMRmobile router is away from home is described in this section. Section 3.2 describes the protocol operation for the case when theMRmobile router is attached to its home link. TheMRmobile router MUST register at theHA (i.e.home agent (i.e., by sending a Binding Update to theHA)home agent) before initiating a DHCPv6 message exchange for prefix delegation.SinceThe mobile router MUST use implicit BU signaling, since theMRmobile router may not have yet requested anyprefixes, implicit BU signaling MUST be used. While using the NEMO Basic Support protocol with DHCPv6PD, implicit BU signaling is the default mode of operation.prefixes. If theMRmobile router does not have any active delegated prefixes (with unexpired leases), theMR initiatesmobile router MUST initiate a DHCPv6 message exchange with a DHCPv6 Solicit message as described in section 17 ofRFC 3315[RFC3315] and section 11.1 ofRFC 3633.[RFC3633]. TheDelegating Routerdelegating router at theHAhome agent responds with an Advertise message. Then, theMR requestsmobile router MUST request a set of prefixes by sending a Request message. TheDRdelegating router includes the delegated prefixes in a Reply message. Note that in this case, theMRmobile router has previously sent aBUBinding Update to theHAhome agent without knowing yet the set of prefixes that it can use asMNPs.mobile network prefixes. TheHA,home agent, upon reception of the implicitBUBinding Update from theMR, selectsmobile router, MUST select (in case this was not pre-configured already) the prefixes that would then be delegated to theMRmobile router via DHCPv6PD. TheHA,home agent, once the DHCPv6 signaling has been completed,addsMUST add an entry in its binding cache including the delegated prefixes. In case theMRmobile router has one or more active delegated prefixes -- as for example if theMRmobile router reboots or theMNP(s)mobile network prefix(es) currently used by the mobile router is about to expire -- theMR initiatesmobile router MUST initiate a DHCPv6 message exchange with a DHCPv6 Rebind message as described in section 18.1.2 ofRFC 3315[RFC3315] and section 12.1 ofRFC 3633.[RFC3633]. A DHPCv6 relay agent function [RFC3315]isMUST be used at theMR.mobile router. This relay agent function is co-located in theMRmobile router with the DHCPv6 client function (see Figure 2). The DHCPv6 signaling between theMRmobile router and theHA arehome agent is exchanged between the DHCPv6 relay agent in theMRmobile router and the DHCPv6 server on theHA.home agent. DHCPv6 messages from theMRmobile router to theHAhome agent are unicast packets sent from the unicastHoAhome address of theMRmobile router to the global unicast address of theHA,home agent, and therefore the Home Address destination optionisMUST be used. DHCPv6 replies from theHAhome agent to theMR aremobile router MUST be sent using the Routing Header type 2, as specified inRFC3775bis.[I-D.ietf-mext-rfc3775bis]. The DHCPv6 client in theMR handsmobile router MUST hand any outbound DHCPv6 messages to the co-located relay agent. Responses from the DHCPv6 server are delivered to the relay agent function in theMR,mobile router, whichextractsMUST extract the encapsulated message anddeliversdeliver it to the DHCPv6 client in theMR.mobile router. ----------------------------- -------- | MR | | HA | | (RR) (DRA) | | (DR) | ---------------------------- -------- | | Binding Update | | |------------------------>| | | (HoA, CoA) | | | | | | Binding Ack | | |<------------------------| | | | | DHCPv6 Solicit | DHCPv6 Solicit | |..................>|--=====================->| | | | | DHCPv6 Advertise | DHCPv6 Advertise | |<..................|<-=====================--| | | | | DHCPv6 Request | DHCPv6 Request | |..................>|--=====================->| | | | | DHCPv6 Reply | DHCPv6 Reply | |<..................|<-=====================--| | | (Mobile Network Prefix) | | | | Figure 2: Signaling sequence when theMRmobile router is not at home Note thatan MRa mobile router using DHCPv6PD to obtain the set of prefixes to be used asMNPsmobile network prefixes cannot derive itsHoAhome address froman MNPone of its mobile network prefix(es) (as theMRmobile router does not know them before registering to theHA).home agent). Therefore, theMR is assignedmobile router MUST assign itsHoAhome address from the prefix on its Home Link. 3.1.1. Relay agent configuration The use of the relay agent function in theMRmobile router allows theMRmobile router to unicast DHCPv6 messages to the DHCPv6 server. The relay agent MUST be configured with the address of the DHCPv6 server. For the purposes ofNEMO,this specification, the relay agent assumes that theHAhome agent for theMRmobile router hosts the DHCPv6 server. Therefore, theMRmobile router MUST configure the DHCPv6 relay agent to forward DHCPv6 messages to theHA.home agent. The DHCPv6 specification supports in certain scenarios the use of unicast between the client and the server. However its use presents some difficulties, as the client has to first receive a Server Unicast option (section 22.12 of [RFC3315]) from the server, which means that a Solicit/Advertise message exchange is required in advance. That signaling exchange would require the presence of a relay agent on the mobile router, and therefore little gain would be achieved in this case from the use of the Server Unicast option. 3.1.2. Transmission of DHCPv6 messages When the DHCPv6 client in theMRmobile router sends a message, ithandsMUST hand the message to the DHCPv6 relay agent in theMR.mobile router. The way in which the message is passed to the DHCP relay agent is beyond the scope of this document. The relay agent encapsulates the message from the client according toRFC 3315[RFC3315] in a Relay-forward message and sends the resulting DHCPv6 message to theHA.home agent. The relay agent sets the fields in the Relay-forward message as follows: msg-type RELAY-FORW hop-count 1 link-address The home address of theMRmobile router peer-addressA non-link-local address from the MR egress interface (e.g.,The homeaddress) used to send packets between the HA andaddress of theMRmobile router options MUST include a "Relay Message option" [RFC3315]; MAY include other options added by the relay agent. 3.1.3. Receipt of DHCPv6 messages Messages from the DHCPv6 server will be returned to the DHCPv6 relay agent, with the message for the DHCPv6 client encapsulated in the Relay Message option [RFC3315] in a Relay-reply message. The relay agent functionextractsMUST extract the message for the client from the Relay Message option andhandshand the message to the DHCPv6 client in theMR.mobile router. The way in which the message is passed to the client is beyond the scope of this document. 3.2. Exchanging DHCPv6 messages whenMRthe mobile router is at home When theMRmobile router is on its home link, theHA useshome agent MUST use the home link to exchange DHCPv6PD messages with theMRmobile router (Figure 3). In this case, the DHCPv6 co-located relay functionisMUST be disabled. It is the responsibility of the implementation to determine when theMRmobile router is on its home link. The Home Link Detection mechanism is described in the section 11.5.2 ofRFC3775bis.[I-D.ietf-mext-rfc3775bis]. -------- -------- | MR | | HA | | (RR) | | (DR) | -------- -------- | | | DHCPv6 Solicit | |------------------------>| | | | DHCPv6 Advertise | |<------------------------| | | | DHCPv6 Request | |------------------------>| | | | DHCPv6 Reply | |<------------------------| | (Mobile Network Prefix) | | | Figure 3: Signaling sequence for the case theHAhome agent is at home 3.3. Selectingan HAa home agent that provides DHCPv6PD Not all nodes that are willing to act asan HAa home agent are required to provide DHCPv6PD. Therefore, when selectingan HA, an MRa home agent, a mobile router that requires DHCPv6PD servicemustMUST identifyan HAa home agent that will provide the service. TheMRmobile router can determine ifan HAa home agent provides DHCPv6PD by initiating a DHCPv6 message exchange(i.e.(i.e., sending a Solicit message) in which theMRmobile router requests delegated prefix(es). If theHAhome agent does not respond or responds but does not delegate any prefix(es) in its response, theMRmobile router assumes that theHAhome agent does not provide DHCPv6PD service. TheMRmobile router continues to query all candidateHAshome agents until it findsan HAone that provides DHCPv6PD. Note that in this particular case and if theMRmobile router is away from home, theMRmobile router has to have already performedan MIPv6a Mobile IPv6 registration with theHAhome agent it queries. Queryingan HAa home agent to determine if it provides DHCPv6PD requiresa small modification todifferent operational variables than those recommended by theoperation ofDHCPv6as described in RFC 3315. Underspecification. [RFC3315] recommends that under normal circumstances, a host will continue to send DHCPv6 Solicit messages until it receives a response (see Section 17 ofRFC 3315).[RFC3315]), i.e., the Maximum Retransmission Duration (MRD) and Maximum Retransmission Count (MRC) are both set to zero. However,an HAa home agent maychoosenottorespond to the Solicit messages from theMRmobile router because theHAhome agent does notprovide DHCPv6.support DHCPv6 prefix delegation. Therefore, when queryingan HAa home agent to determine if theHAhome agent provides DHCPv6PD service, it is RECOMMENDED that MRD and MRC be set to non-zero values so that theMR SHOULD discontinuemobile router discontinues sending Solicit messages to theHAhome agent after sending 6 Solicit messages, and conclude that theHAhome agent will not provide DHCPv6PD service. Sending 6 queries provides enough reliability for scenarios in which the wireless connectivity is lost for a short period after sending the firstBUBinding Update message. It isrecommendedRECOMMENDED that theMRmobile router uses a sequential probing of theHAshome agents for DHCPv6PD service. 3.4. Minimizing DHCPv6PD messages The use DHCPv6PD in aNEMOmobile network can be combined with the Rapid Commit option [RFC3315] to provide DHCPv6 prefix delegation with a two message exchange between the mobile router and the DHCPv6PDDR.delegating router. 3.5. Other DHCPv6 functions The DHCPv6 messages exchanged between theMRmobile router and theHAhome agent MAY also be used for other DHCPv6 functions in addition to DHCPv6PD. For example, theHAhome agent MAY assign global addresses to theMRmobile router and MAY pass other configuration information such as a list of available DNS recursive name servers [RFC3646] to theMRmobile router using the same DHCPv6 messages as used forDHCPV6PD.DHCPv6PD. TheHAhome agent MAY act as a DHCPv6 relay agent forMobile Nodesmobile nodes while it acts as aDRdelegating router forMRs.mobile routers. 4. Security Considerations This document describes the use of DHCPv6 for prefix delegation inNEMO.mobile networks. In addition to the security considerations for DHCPv6 described in the "Security Considerations" section of the DHCPv6 base specification [RFC3315] and the "Security Considerations" of the DHCPv6 Prefix Delegation specification [RFC3633], there are two aspects that need to be considered. First, the NEMO Basic Support specification requires theHAhome agent to preventan MRa mobile router from claimingMNPsmobile network prefixes belonging to anotherMR.mobile router. Upon reception of an implicitBUBinding Update froman MR,a mobile router, theHAhome agent MUST only add prefixes into theMR'smobile router's Binding Cache Entry if theMRmobile router has a valid DHCPv6 Prefix Delegation lease for said prefixes. If theMRmobile router does not have a valid DHCPv6 Prefix Delegation lease, theHAhome agent MUST NOT add any prefixes into theMR'smobile router's Binding Cache Entry. Upon theMRmobile router obtaining a valid DHCPv6 Prefix Delegation lease for a given set of prefixes, theHAhome agent MUST add these prefixes to theMR'smobile router's Binding Cache Entry. This avoids theHAhome agent forwarding traffic addressed to prefixes that have not been yet delegated to theMR.mobile router. The use of DHCPv6, as described in this document, requires message integrity protection and source authentication. When theMRmobile router is at home, normal DHCPv6 operation is used betweenMRthe mobile router andHAthe home agent and therefore this specification does not add any new security issue. While theMRmobile router is away from home, the IPsec security mechanism mandated byMIPv6Mobile IPv6 [RFC3776] MUST be used to secure the DHCPv6 signaling. In the following, we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries necessary to protect the DHCPv6 signaling. We use the same formatthan thatused byof[RFC4877]. The SPD and SAD entries are only example configurations. A particular mobile router implementation and a home agent implementation could configure different SPD and SAD entries as long as they provide the required security of the DHCPv6 signaling messages. For the examples described in this document, a mobile router with home address "home_address_1", and a home agent with address "home_agent_1" are assumed. If the home address of the mobile router changes, the SPD and SAD entries need to be re-created or updated for the new home address. mobile router SPD-S: - IF local_address = home_address_1 & remote_address = home_agent_1 & proto = UDP & local_port = any & remote_port = DHCP Then use SA1 (OUT) and SA2 (IN) mobile router SAD: - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = UDP & remote_port = DHCP - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = UDP & local_port = DHCP home agent SPD-S: - IF local_address = home_agent_1 & remote_address = homa_address_1 & proto = UDP & local_port = DHCP & remote_port = any Then use SA2 (OUT) and SA1 (IN) home agent SAD: - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): local_address = home_agent_1 & remote_address = home_address_1 & proto = UDP & local_port = DHCP - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): local_address = home_address_1 & remote_address = home_agent_1 & proto = UDP & remote_port = DHCP 5. IANA Considerations This document describes the use of DHCPv6 for prefix delegation inNEMOs.mobile networks. It does not introduce any additional IANA considerations. 6. Acknowledgments The authors would like to thank people who have given valuable comments on the mailing list. Specific suggestions from Ryuji Wakikawa, George Tsirtsis, Alexandru Petrescu, Vijay Devarapalli and Marcelo Bagnulo were incorporated into this document. The authors would like to thank Julien Laganier, Michaela Vanderveen and Jean-Michel Combes for their review of previous versions of this document. 7. Change Log This section MUST be removed before this document is published as an RFC. 7.1. Revision -00 This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes the use of the DHCPv6 relay agent in the MR from draft-dupont-mext-dhcrelay-00. 7.2. Revision -01 Added detail in Section 4, "Security Considerations", describing protection required for DHCPv6 and a mechanism for protecting traffic between the DHCPv6 relay agent and server. Corrected minor typos. 7.3. Revision -02 Removed text describing extensions to DHAAD for discovery of HA that will provide PD. Added Section 3.3, "Selecting an HA that provides DHCPv6PD," which describes how an MR can discover DHCPv6PD service through polling of multiple HAs. Added text to Section 4, "Security Considerations", giving detail about the use of IPsec. 7.4. Revision -04 Added some figures to better explaining considered topologies and message exchanges. Credits to Alex Petrescu. Added some text to clarify that two BUs are required, one to set up the tunnel to the HA so the DHCPv6 signaling can be sent, and one to register the delegated prefixes as MNPs at the HA. This updates RFC 3963 behavior (note added). Text added to address some comments received on the MEXT mailing list Corrected minor typos. Enlisted Carlos J. Bernardos as co-author 7.5. Revision -05 Only implicit BU mode supported. Only DHCPv6 relay agent in the MR co-located with the DHCPv6 client function is supported as mode of operation when the MR is away from home. Security considerations include now the issue of the HA enforcing that the MR registers the prefixes that were delegated to it via DHCPv6PD. SinceRFC3775bis[I-D.ietf-mext-rfc3775bis] specifies that MR and HA operate in RO mode when sending traffic between them, the term tunnel has been removed. Some typos detected and corrected. 7.6. Revision -06 Some nits fixed. 7.7. Revision -07 Fixes and clarifying text as suggested during IESG review. 8. References 8.1. Normative References [I-D.ietf-mext-rfc3775bis] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", draft-ietf-mext-rfc3775bis-10 (work in progress), October 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. 8.2. Informative References[I-D.ietf-mext-rfc3775bis] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", draft-ietf-mext-rfc3775bis-06 (work in progress), July 2010.[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. Authors' Addresses Ralph Droms Cisco 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978.936.1674 Email: rdroms@cisco.com Pascal Thubert Cisco Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 FRANCE Email: pthubert@cisco.com Francis Dupont ISC Email: Francis.Dupont@fdupont.fr Wassim Haddad Ericsson 6210 Spine Road Boulder, CO 80301 USA Phone: +1 303.473.6963 Email: Wassim.Haddad@ericsson.com Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/