NETLMM Working Group(NetEXT) R. Wakikawa Internet-Draft Toyota ITC Intended status: Standards Track S. Gundavelli Expires: October 8, 2009 Cisco Y. Zhao Huawei Tech. April 6, 2009 NEtwork MObility (NEMO) Support for Proxy Mobile IPv6 draft-wakikawa-netext-pmip6-nemo-support-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or 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 October 8, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the Wakikawa, et al. Expires October 8, 2009 [Page 1] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Wakikawa, et al. Expires October 8, 2009 [Page 2] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 Abstract This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility. The solution leverages the extensions defined in [RFC3963], [ID-DHCPPD-NEMO] and [RFC3633] specification for achieving this. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 3. Network Mobility Support . . . . . . . . . . . . . . . . . . . 6 3.1. Mobile Network Prefix Option . . . . . . . . . . . . . . . 6 3.2. Mobile Network Prefix Delegation . . . . . . . . . . . . . 7 3.3. Mobile Access Gateway Considerations . . . . . . . . . . . 9 3.3.1. Extensions to Binding Update List Entry . . . . . . . 9 3.3.2. Signaling Considerations . . . . . . . . . . . . . . . 9 3.4. Local Mobility Anchor Considerations . . . . . . . . . . . 12 3.4.1. Extensions to Binding Cache Entry . . . . . . . . . . 12 3.4.2. Prefix Management . . . . . . . . . . . . . . . . . . 12 3.4.3. Signaling Considerations . . . . . . . . . . . . . . . 13 3.4.4. Routing Considerations . . . . . . . . . . . . . . . . 14 3.5. Mobile Router Considerations . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 6.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Wakikawa, et al. Expires October 8, 2009 [Page 3] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 1. Overview Figure 1 illustrates a Proxy Mobile IPv6 domain supporting network mobility features. The mobile routers, MR1 and MR2 can obtain a mobile network prefix(es) in addition to a home address (i.e. Home Network Prefix in Proxy Mobile IPv6) from the network. +----+ +----+ |LMA1| |LMA2| +----+ +----+ LMAA1 -> | | <-- LMAA2 | | \\ //\\ \\ // \\ +---\\------------- //------\\----+ ( \\ // \\ ) ( \\ Network // \\ ) +------\\--------//------------\\-+ \\ // \\ \\ // \\ \\ // \\ Proxy-CoA1--> | | <-- Proxy-CoA2 +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | HoA --> | | <-- HoA {MR1} {MR2} IPv6 MNP --> ____|____ ____|____ <-- IPv6 MNP | | | | MNN MNN MNN MNN Figure 1: Network Mobility support for Proxy Mobile IPv6 Wakikawa, et al. Expires October 8, 2009 [Page 4] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 2. Conventions & 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 RFC 2119 [RFC-2119]. All the mobility related terms used in this document are to be interpreted as defined in Mobile IPv6 [RFC-3775], Network Mobility Basic Support protocol [RFC-3963], Proxy Mobile IPv6 specification [RFC-5213], DHCPv6 Prefix Delegation for NEMO [ID-DHCPPD-NEMO], DHCP Prefix Delegation [RFC3633] and Mobility Related Terminology [RFC- 3753]. This document does not define any new terms. Wakikawa, et al. Expires October 8, 2009 [Page 5] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 3. Network Mobility Support The NEMO Basic protocol [RFC3963] extends Mobile IPv6 [RFC3775] to enable network mobility. This specification extends Proxy Mobile IPv6 to assign not only a home address but also a mobile network prefix(es) to a mobile router with mobility support. This specification assumes that a mobile router is a regular IPv6 router and is not extensible for mobility managements. The modifications introduced in this specification are limited only to the operations of the mobile access gateway and the local mobility anchor. This specification does not require any dynamic routing protocols' interaction between a mobile router and the Proxy Mobile IPv6 domain. The mobile router transmits the packets from its mobile network to the attached mobile access gateway and the mobile access gateway delivers the packets to the mobile network via the mobile router. When a mobile router first connects to a Proxy Mobile IPv6 domain, it runs DHCP Prefix Delegation [RFC3633] to get a mobile network prefix. This mobile network prefix is different from the Mobile Node's home network prefix assigned by local mobility anchor. After getting the mobile network prefix from a designated router, the mobile router assigns the prefix to its mobile network. The attached mobile access gateway becomes a default router of the mobile router. Meanwhile, the mobile access gateway detects the attachment of the mobile router and sends a proxy binding update to the local mobility anchor. The mobile access gateway, then, tunnels the packets to the local mobility anchor and the local mobility anchor routes the packets to the destination. In order to setup a tunnel between the local mobility anchor and the mobile access gateway for the mobile network prefix, the mobile network prefix mobility option [RFC3963] is carried in a proxy binding update message. This specification does not support the nested configuration of mobile routers operated by this specification, because a mobile router attached to another mobile router cannot obtain its home address. The Proxy Mobile IPv6 specification requires the direct connectivity (point-to-point link) between a mobile router and a mobile access gateway. The RFC3963-compliant mobile router can attach to mobile networks operated by this specification, but no special operation for the RFC3963-compliant mobile router is introduced in this specification. 3.1. Mobile Network Prefix Option The Mobile Network Prefix Option is defined in [RFC-3963]. This specification adds a new bit for the purpose of the prefix delegation Wakikawa, et al. Expires October 8, 2009 [Page 6] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |R| Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Mobile Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Modified Mobile Network Prefix Option Requesing (R) flag A flag indicating that the mobile access gateway requests a mobile network prefix for the a mobile router. When this flag is set, the mobile network prefix stored in the Mobile Network Prefix field is ignored and overwritten by the newly assigned prefix by the local mobility anchor. This flag can be set for new request and binding refreshes, too. If a mobile router changes the attached mobile access gateway, the new mobile access gateway can retrieve the mobile network prefix previously assigned to the mobile router. Reserved 7 bits reserved field 3.2. Mobile Network Prefix Delegation A mobile router SHOULD dynamically obtain a mobile network prefix by DHCP Prefix Delegation [RFC3633] or MAY be statically configured with the assigned prefix. When DHCP Prefix Delegation is used, a mobile router MUST act as a requesting router [RFC3633] and a mobile access gateway MUST be a DHCP relay agent. The delegating router [RFC3633] can be located either at a local mobility anchor or some other device in a Proxy Mobile IPv6 domain. In Proxy Mobile IPv6, a mobile access gateway can intercept all the DHCP related packets from a mobile router as a Wakikawa, et al. Expires October 8, 2009 [Page 7] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 DHCP relay. MR(RR) MAG(DHCP-R) LMA DR |------>| | | 1. DHCP solicit | |------->| | 2. Proxy Binding Update | |<-------| | 3. Proxy Binding Acknowledgement (MNP) | |========| | 4. Tunnel/Route Setup* | |---------------->| 5. DHCP (including IA_PD) |<------|<----------------| 6. DHCP advertise | | | | * DHCP solicit (1) and PBU (2) are operated in parallel. * Tunnel/Route setup(4) and DHCP message exchange (5 and 6) are processed in parallel. Figure 3: Prefix Delegation After attaching to the Proxy Mobile IPv6 domain, if a mobile router does not have any active delegated prefix for its mobile network, it sends a DHCPv6 Solicit message as shown in Figure 3-1). The message is intercepted by the DHCPv6 relay agent located at the mobile access gateway. Before relaying this message, the mobile access gateway should obtain a mobile network prefix delegated for the mobile router by using the proxy binding registration. It sends a Proxy Binding Update with a Mobile Network Prefix option [RFC-3963] with the requesting bit set (Figure 3-2)). The local mobility anchor returns the assigned prefix in the Mobile Network Prefix option carried by a Proxy Binding Acknowledgment (Figure 3-3)). This proxy binding registration is to guarantee that the local mobility anchor controls the prefix assignment on behalf of the DHCP Prefix Delegation protocol. This document recommends that Proxy Mobile IPv6 controls the prefix management and DHCP Prefix Delegation is used to deliver the assigned prefix to a requesting router (i.e. mobile router). Otherwise, the Proxy Mobile IPv6 requires certain interactions with the DHCP Prefix Delegation protocol to verify whether the prefix notified by a Proxy Binding Update is surely assigned to the requesting mobile router or not. This protocol interface has not been standardized at IETF yet and is out of scope in this document. If the mobile access gateway obtains the assigned prefix for the mobile router by receiving the Mobile Network Prefix option in the Proxy Binding Acknowledgement, it contains the assigned prefix in the IA_PD Prefix option [RFC3633] encapsulated in the IA_PD-options as a hint and sends the DHCPv6 message to the delegating router (Figure 3-4)). The delegating router MUST choose to use the information in that hint to select the prefix(es) or prefix size to be delegated to the requesting router. The delegating router, then, Wakikawa, et al. Expires October 8, 2009 [Page 8] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 sends an Advertise message to the requesting router as described in [RFC3315] and [RFC3633] (Figure 3-5) and 6)). On the other hand, if the mobile access gateway fails to have the mobile network prefix from its local mobility anchor, it MUST discard any DHCPv6 messages of the requesting mobile router. If the mobile router has already had one or more active delegated prefixes, it sends DHCPv6 Renew messages to extend the lifetimes of a delegated prefix. The messages are also intercepted by the mobile access gateway and relayed to the delegating router. The delegating router replies with DHCPv6 reply message to the requesting router. The mobile access gateway acting as a DHCP relay SHOULD check all the DHCPv6 reply message. If zero is set to the lifetime of a mobile network prefix stored in the IA_PD Prefix option carried by a DHCPv6 reply message, the mobile access gateway SHOULD triggers a Proxy Binding Update to remove the binding for that mobile network prefix. If the mobile router has multiple network interfaces attached to the same Proxy Mobile IPv6 domain, it should be able to use all the active interfaces to transmit the packets from its mobile network. To do so, the local mobility anchor MUST always return the mobile network prefix assigned to the mobile router by the Mobile Network Prefix option in the Proxy Binding Acknowledgement if the mobile network prefix is already assigned to that mobile router. Even though a mobile router does not initiate the prefix delegation procedure from the newly attached interface, the mobile access gateway can learn the assigned prefix. The local mobility anchor and the mobile access gateways can setup a route of the mobile network prefix for all the active interfaces of the mobile router in the Proxy Mobile IPv6 domain. A mobile router can utilize all the active interfaces as an exit interface of the mobile network. 3.3. Mobile Access Gateway Considerations 3.3.1. Extensions to Binding Update List Entry This document introduces a new Prefix Information field in the Binding Update list structure as [RFC3963] does. This field is used to store the mobile network prefix information that the local mobility anchor notified during the proxy binding registration. 3.3.2. Signaling Considerations The detail operation of prefix delegation is described in Section 3.2 Mobile Router Initial Attachment Wakikawa, et al. Expires October 8, 2009 [Page 9] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 o After detecting a new mobile router on its access link, the mobile access gateway MUST identify the mobile router and acquire the MN- Identifier of the mobile router as [RFC-5213]. It SHOULD determine whether the network mobility service needs to be offered to the mobile node or not by checking the policy profile. Proxy Binding Registration: o The mobile access gateway triggers a Proxy Binding Update with a Mobile Network Prefix mobility option defined in [RFC3963]. It MUST uses the Mobile Network Prefix option in the following cases: 1. A mobile access gateway requests a mobile network prefix assigned to the mobile router. (i.e. the mobile router does not have any prefix yet) 2. A mobile access gateway asks the assigned mobile network prefix to the mobile router. (i.e. the mobile router has already had the mobile network prefix) 3. A mobile access gateway renews the binding cache for the home network prefix and the mobile network prefix. o The proxy binding registration process is same as [RFC-5213] except that the Mobile Network Prefix mobility option MUST be presented. o The Mobile Router flag (R) defined in [RFC3963] MUST be set in the Proxy Binding Update for a mobile router o For the scenarios-1) and -2), the mobile access gateway MUST set the requesting bit in the Mobile Network Prefix option. o For the scenario-3), the mobile access gateway SHOULD NOT set the requesting flag and MUST set the mobile network prefix to the mobile router in the Mobile Network Prefix option. o The mobile access gateway can use both implicit or explicit the mobile network prefix registration as [RFC3963] defined. The implicit registration MUST NOT be used if the mobile access gateway does not know the mobile network prefix assigned to the mobile router o When the requesting bit is set in the Mobile Network Prefix option, the local mobility anchor will return the assigned prefix by the Mobile Network Prefix option stored in the Proxy Binding Acknowledgement. If the Mobile Network Prefix option does not Wakikawa, et al. Expires October 8, 2009 [Page 10] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 present or does not have a valid IPv6 prefix, the mobile access gateway MUST NOT enable Network Mobility support for the mobile router. DHCPv6 Prefix Management o The mobile access gateway MUST intercept all the DHCPv6 related messages and SHOULD verify all the DHCPv6 messages before relaying to either a requesting router or a delegating router. o If the mobile access gateway detects a DHCPv6 solicit message from the mobile router, it should intercept it and caches it until it learns an assigned mobile network prefix from local mobility anchor. o If network mobility service is not enabled for the mobile router in the policy profile, the mobile access gateway MUST ignores the DHCPv6 solicit message. o After the mobile access gateway obtains an assigned mobile network prefix(es), it includes the information in an IA_PD Prefix option of DHCPv6 messages initiated by the requesting router (mobile router) and relays the messages to the delegating router. o The delegating router MUST return a DHCPv6 reply message including the assigned prefix to the mobile router via the mobile access gateway (DHCP relay agent). However, if the different prefix from the one in the hint is assigned by the delegating router, the mobile access gateway MUST discard the message and SHOULD re-relay the DHCPv6 message to the delegating router. After a few retries, it SHOULD give up replaying the messages. o If the lifetime of the assigned prefix is set to zero, the mobile access gateway MUST sends a de-registration Proxy Binding Update to the local mobility anchor. Mobile Router's Handover: o As the mobile router moves from one mobile access gateway to another, the new mobile access gateway MAY know the assigned prefix to the mobile router by mechanisms such as context transfer between the mobile access gateways. However, such mechanisms are not defined in this specification. o If no context transfer mechanism is available, the mobile access gateway sends a Proxy Binding Update message with a Mobile Network Wakikawa, et al. Expires October 8, 2009 [Page 11] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 Prefix option with the requesting bit set. The local mobility anchor MUST return the same assigned prefix by the Mobile Network Prefix option stored in a Proxy Binding Acknowledgement so that the new mobile access gateway can obtain the assigned prefix. o After the mobile router's first attachment to a Proxy Mobile IPv6 domain, the DHCP Prefix Delegation protocol might not always run as a mobile router changes its attached mobile access gateway. Mobile Router's Multihoming Support: o Even if the mobile router attaches to the Proxy Mobile IPv6 domain by multiple interfaces, it SHOULD be capable of using all the interfaces as external paths for the mobile network. o A home network prefix is assigned per interface in Proxy Mobile IPv6, but a mobile network prefix is assigned per a mobile router. Therefore, all the mobile access gateway to which a mobile router is attached can get the same prefix from the local mobility anchor. o The mobile access gateways setup a route for the mobile network prefix as soon as it receives the proxy binding Acknowledgement. 3.4. Local Mobility Anchor Considerations 3.4.1. Extensions to Binding Cache Entry This document introduces a new Prefix Information field in the Binding Cache structure as [RFC3963] does. This field is used to store any prefix information that the mobile access gateway includes in the Binding Update. In the multihoming scenario, the local mobility anchor may have two different binding cache entries per mobile node's identifier. The mobile network prefix information of two binding caches must be same, because the prefix is assigned per a mobile router. 3.4.2. Prefix Management A local mobility anchor manages the prefix pool for mobile network prefixes assigned to a mobile router. Assigned prefix is tied to a mobile router. The local mobility anchor should manage the mobile network prefix with the mobile node identifier. If the requesting router has the same mobile node identifier and a prefix is already assigned to that router, the local mobility anchor MUST return the same assigned prefix to the requesting router. Wakikawa, et al. Expires October 8, 2009 [Page 12] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 3.4.3. Signaling Considerations All the considerations explained in Section 5.3 [RFC-5213] apply here. For supporting network mobility feature, the following additional considerations MUST be applied. Processing Binding Registrations: o If there is a Mobile Network Prefix option in a Proxy Binding Update message, the local mobility anchor MUST proceed the following instructions. o If the requesting bit is set in the Mobile Network Prefix option, the local mobility anchor SHOULD look for the prefix assigned to the mobile router. If there is no previously assigned prefix, the local mobility anchor MUST allocate a new mobile network prefix to the mobile router. Otherwise, it SHOULD continue using the same assigned prefix for the mobile router. o The assigned prefix MUST be returned with the Mobile Network Prefix option in a Proxy Binding Acknowledgement message. o If the local mobility anchor is unable to allocate a Mobile Network Prefix for the mobile router, it MUST reject the Proxy Binding Update and send a Proxy Binding Acknowledgement message with Status field set to 130 (Insufficient resources). o Upon accepting the request, the local mobility anchor MUST create a Binding Cache entry for the mobile router. It must set the fields in the Binding Cache entry to the accepted values for that binding. The assigned prefix is also stored as the mobile network prefix in the binding cache entry of the mobile router. o It MUST also establish a bi-directional tunnel to the mobile access gateway, as described in [RFC-2473]. Considerations from Section 5.6 [RFC-5213] MUST be applied. The local mobility anchor MUST add a network route for that allocated mobile network prefix over the tunnel to the mobile access gateway. o The local mobility anchor MUST use the identifier from the Mobile Node Identifier Option [RFC-4283] present in the Proxy Binding Update request and MUST apply multihoming considerations specified in Section 5.4 [RFC-5213] and from this section for performing the Binding Cache entry existence test. Wakikawa, et al. Expires October 8, 2009 [Page 13] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 3.4.4. Routing Considerations Forwarding Considerations for the mobile router's mobile network prefix traffic. Intercepting Packets Sent to the mobile network: o When the local mobility anchor is serving a mobile router, it MUST be able to receive packets that are sent to the mobile router's mobile network. In order for it to receive those packets, it MUST advertise a connected route in to the Routing Infrastructure for the mobile router's mobile network prefix or for an aggregated prefix with a larger scope. Forwarding Packets to the Mobile Router: o On receiving a packet from a correspondent node with the destination address matching a mobile router's mobile network prefix, the local mobility anchor MUST forward the packet through the bi- directional tunnel setup for that mobile router. The format of the tunneled packet is the same as [RFC-5213] except that the destination address of the inner packet header is the IPv6 address of the mobile network node attached to the mobile network. Forwarding Packets Sent by the Mobile Router: o All the reverse tunneled packets that the local mobility anchor receives from the mobile access gateway, after removing the tunnel header MUST be routed to the destination specified in the inner IPv6 packet header. 3.5. Mobile Router Considerations A mobile router has two interfaces such as an ingress interface and an egress interface according to [RFC3963]. The prefix assigned by the DHCP prefix delegation protocol is configured to the mobile network (i.e. ingress interface). The mobile router configures its home address to the egress interface. The default route of the mobile router SHOULD be the attached mobile access gateway. The mobile router also has the connected route to the mobile network. These routes can be statically configured at the mobile router. On the other hand, if the mobile router needs to run any dynamic routing protocols [RFC3963], it runs a routing protocol by sending routing updates through its egress interface. The mobile Wakikawa, et al. Expires October 8, 2009 [Page 14] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 router is always attached to the home network in the Proxy Mobile IPv6 specification, all the routing updates are sent to the attached mobile access gateway. However, most routing protocols use link- local addresses as source addresses for the routing information messages. The mobile access gateway MUST intercept these link-local packets and tunneled to the local mobility anchor. Since the Proxy Mobile IPv6 [RFC-5213] prohibits routing the packets sent with the link-local source address over the tunnel. we need to relax this limitation for routing updates messages. This specification does not recommend to run routing protocols on a mobile router. Wakikawa, et al. Expires October 8, 2009 [Page 15] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 4. IANA Considerations This document requires to allocate the new requesting (R) flag in the Mobile Network Prefix option from IANA. Wakikawa, et al. Expires October 8, 2009 [Page 16] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 5. Security Considerations The security mechanisms specified for Proxy Mobile IPv6 protocol are used when using the extensions defined in this document. When supporting mobile network prefix assignment from a DHCP-PD server, all the mobile network prefixes managed in the DHCP-PD server must be reachable via local mobility anchor so that local mobility anchor intercepts packets meant for a mobile network prefix and tunnels them to the mobile router via corresponding mobile access gateway. Moreover, all the DHCPv6 messages between a DHCP relay and the DHCP-PD server SHOULD be securely exchanged. Wakikawa, et al. Expires October 8, 2009 [Page 17] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 6. References 6.1. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, November 2005. [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, August 2008. [ID-DHCPPD-NEMO] R. Droms and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", draft-ietf-nemo-dhcpv6-pd-03, December 2007. 6.2. Informative References [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. Wakikawa, et al. Expires October 8, 2009 [Page 18] Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009 Authors' Addresses Ryuji Wakikawa Toyota ITC/KEIO U. 6-6-20 Akasaka, Minato-ku Tokyo 107-0052 Japan Phone: +81-3-5561-8276 Fax: +81-3-5561-8292 Email: ryuji.wakikawa@gmail.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Yuankui zhao Huawei Technologies Co.,LTD Email: john.zhao@huawei.com Wakikawa, et al. Expires October 8, 2009 [Page 19]