diff options
Diffstat (limited to 'doc/rfc/rfc6276.txt')
| -rw-r--r-- | doc/rfc/rfc6276.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc6276.txt b/doc/rfc/rfc6276.txt new file mode 100644 index 0000000..a8e4b9f --- /dev/null +++ b/doc/rfc/rfc6276.txt @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Droms +Request for Comments: 6276 P. Thubert +Category: Standards Track Cisco +ISSN: 2070-1721 F. Dupont + Internet Systems Consortium + W. Haddad + Ericsson + C. Bernardos + UC3M + July 2011 + + + DHCPv6 Prefix Delegation for Network Mobility (NEMO) + +Abstract + + 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 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 is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6276. + +Copyright Notice + + Copyright (c) 2011 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 + + + +Droms, et al. Standards Track [Page 1] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. DHCPv6 Prefix Delegation of Mobile Network Prefixes . . . . . 4 + 3.1. Exchanging DHCPv6 Messages When the Mobile Router Is + Not at Home . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1.1. Relay Agent Configuration . . . . . . . . . . . . . . 7 + 3.1.2. Transmission of DHCPv6 Messages . . . . . . . . . . . 8 + 3.1.3. Receipt of DHCPv6 Messages . . . . . . . . . . . . . . 8 + 3.2. Exchanging DHCPv6 Messages When the Mobile Router Is + at Home . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Selecting a Home Agent That Provides DHCPv6PD . . . . . . 9 + 3.4. Minimizing DHCPv6PD Messages . . . . . . . . . . . . . . . 10 + 3.5. Other DHCPv6 Functions . . . . . . . . . . . . . . . . . . 10 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 + +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 Network + Mobility (NEMO). DHCPv6 prefix delegation (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 a 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 + + + +Droms, et al. Standards Track [Page 2] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + 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 RFC 2119 [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 [RFC6275]: + + 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) + + + + + + +Droms, et al. Standards Track [Page 3] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + 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 [RFC6275] to enable network mobility. With the NEMO Basic + Support protocol, a mobile router uses Mobile IPv6 to establish and + maintain a session with its home agent and uses bidirectional + tunneling between the mobile router and the home agent to provide a + path through which nodes attached to links in the mobile network can + maintain connectivity with nodes not in the NEMO. + + The requirements for Network Mobility [RFC4885] include the ability + of the mobile router to receive delegated prefixes that can then be + assigned to links in the mobile network. DHCPv6PD can be used to + meet this requirement for prefix delegation. + + To use DHCPv6PD for 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. + + When the mobile router is not at home, the home agent and the mobile + router exchange DHCPv6PD protocol messages as specified in [RFC6275]. + This means that the messages sent by the mobile router MUST include + the Home Address destination option and messages sent by the home + 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. + + + + + + + + +Droms, et al. Standards Track [Page 4] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + ------ ------ + | 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 + of Mobile 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 the home 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 the + mobile router to which the prefix was delegated. + +3.1. Exchanging DHCPv6 Messages When the Mobile Router Is Not at Home + + The case when the mobile router is away from home is described in + this section. Section 3.2 describes the protocol operation for the + case when the mobile router is attached to its home link. + + The mobile router MUST register at the home agent (i.e., by sending a + Binding Update to the home agent) before initiating a DHCPv6 message + exchange for prefix delegation. The mobile router MUST use implicit + BU signaling, since the mobile router may not have yet requested any + prefixes. + + If the mobile router does not have any active delegated prefixes + (with unexpired leases), the mobile router MUST initiate a DHCPv6 + message exchange with a DHCPv6 Solicit message as described in + Section 17 of [RFC3315] and Section 11.1 of [RFC3633]. The + delegating router at the home agent responds with an Advertise + message. Then, the mobile router MUST request a set of prefixes by + sending a Request message. The delegating router includes the + delegated prefixes in a Reply message. Note that in this case, the + mobile router has previously sent a Binding Update to the home agent + without knowing yet the set of prefixes that it can use as mobile + network prefixes. The home agent, upon reception of the implicit + Binding Update from the mobile router, MUST select (in case this was + + + +Droms, et al. Standards Track [Page 5] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + not pre-configured already) the prefixes that would then be delegated + to the mobile router via DHCPv6PD. The home agent, once the DHCPv6 + signaling has been completed, MUST add an entry in its binding cache + including the delegated prefixes. + + In case the mobile router has one or more active delegated prefixes + -- for example, as if the mobile router reboots or the mobile network + prefix(es) currently used by the mobile router is about to expire -- + the mobile router MUST initiate a DHCPv6 message exchange with a + DHCPv6 Rebind message as described in Section 18.1.2 of [RFC3315] and + Section 12.1 of [RFC3633]. + + A DHPCv6 relay agent function [RFC3315] MUST be used at the mobile + router. This relay agent function is co-located in the mobile router + with the DHCPv6 client function (see Figure 2). The DHCPv6 signaling + between the mobile router and the home agent is exchanged between the + DHCPv6 relay agent in the mobile router and the DHCPv6 server on the + home agent. DHCPv6 messages from the mobile router to the home agent + are unicast packets sent from the unicast home address of the mobile + router to the global unicast address of the home agent, and therefore + the Home Address destination option MUST be used. DHCPv6 replies + from the home agent to the mobile router MUST be sent using the + Routing Header type 2, as specified in [RFC6275]. The DHCPv6 client + in the mobile 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 the mobile router, which + MUST extract the encapsulated message and deliver it to the DHCPv6 + client in the mobile router. + + + + + + + + + + + + + + + + + + + + + + + +Droms, et al. Standards Track [Page 6] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + ----------------------------- -------- + | 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 the mobile router is not at home + + Note that a mobile router using DHCPv6PD to obtain the set of + prefixes to be used as mobile network prefixes cannot derive its home + address from one of its mobile network prefix(es) (as the mobile + router does not know them before registering to the home agent). + Therefore, the mobile router MUST assign its home address from the + prefix on its Home Link. + +3.1.1. Relay Agent Configuration + + The use of the relay agent function in the mobile router allows the + mobile 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 of this specification, the relay agent assumes that + the home agent for the mobile router hosts the DHCPv6 server. + Therefore, the mobile router MUST configure the DHCPv6 relay agent to + forward DHCPv6 messages to the 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 + + + +Droms, et al. Standards Track [Page 7] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + 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 the mobile router sends a message, it MUST + hand the message to the DHCPv6 relay agent in the 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 to [RFC3315] in a Relay-forward message and + sends the resulting DHCPv6 message to the 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 the mobile router + + peer-address The home address of the mobile 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 function MUST extract the message for the client from the Relay + Message option and hand the message to the DHCPv6 client in the + 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 When the Mobile Router Is at Home + + When the mobile router is on its home link, the home agent MUST use + the home link to exchange DHCPv6PD messages with the mobile router + (Figure 3). In this case, the DHCPv6 co-located relay function MUST + be disabled. It is the responsibility of the implementation to + determine when the mobile router is on its home link. The Home Link + Detection mechanism is described in Section 11.5.2 of [RFC6275]. + + + + + + + +Droms, et al. Standards Track [Page 8] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + -------- -------- + | MR | | HA | + | (RR) | | (DR) | + -------- -------- + | | + | DHCPv6 Solicit | + |------------------------>| + | | + | DHCPv6 Advertise | + |<------------------------| + | | + | DHCPv6 Request | + |------------------------>| + | | + | DHCPv6 Reply | + |<------------------------| + | (Mobile Network Prefix) | + | | + + Figure 3: Signaling sequence for the case the home agent is at home + +3.3. Selecting a Home Agent That Provides DHCPv6PD + + Not all nodes that are willing to act as a home agent are required to + provide DHCPv6PD. Therefore, when selecting a home agent, a mobile + router that requires DHCPv6PD service MUST identify a home agent that + will provide the service. The mobile router can determine if a home + agent provides DHCPv6PD by initiating a DHCPv6 message exchange + (i.e., sending a Solicit message) in which the mobile router requests + delegated prefix(es). If the home agent does not respond or responds + but does not delegate any prefix(es) in its response, the mobile + router assumes that the home agent does not provide DHCPv6PD service. + The mobile router continues to query all candidate home agents until + it finds one that provides DHCPv6PD. Note that in this particular + case and if the mobile router is away from home, the mobile router + has to have already performed a Mobile IPv6 registration with the + home agent it queries. + + Querying a home agent to determine if it provides DHCPv6PD requires + different operational variables than those recommended by the DHCPv6 + specification. [RFC3315] recommends that under normal circumstances, + a host will continue to send DHCPv6 Solicit messages until it + receives a response (see Section 17 of [RFC3315]), i.e., the Maximum + Retransmission Duration (MRD) and Maximum Retransmission Count (MRC) + are both set to zero. However, a home agent may not respond to the + Solicit messages from the mobile router because the home agent does + not support DHCPv6 prefix delegation. Therefore, when querying a + home agent to determine if the home agent provides DHCPv6PD service, + + + +Droms, et al. Standards Track [Page 9] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + it is RECOMMENDED that MRD and MRC be set to non-zero values so that + the mobile router discontinues sending Solicit messages to the home + agent after sending 6 Solicit messages, and conclude that the home + 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 first Binding Update + message. + + It is RECOMMENDED that the mobile router uses a sequential probing of + the home agents for DHCPv6PD service. + +3.4. Minimizing DHCPv6PD Messages + + The use DHCPv6PD in a mobile 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 DHCPv6PD + delegating router. + +3.5. Other DHCPv6 Functions + + The DHCPv6 messages exchanged between the mobile router and the home + agent MAY also be used for other DHCPv6 functions in addition to + DHCPv6PD. For example, the home agent MAY assign global addresses to + the mobile router and MAY pass other configuration information such + as a list of available DNS recursive name servers [RFC3646] to the + mobile router using the same DHCPv6 messages as used for DHCPv6PD. + + The home agent MAY act as a DHCPv6 relay agent for mobile nodes while + it acts as a delegating router for mobile routers. + +4. Security Considerations + + This document describes the use of DHCPv6 for prefix delegation in + 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 the home agent + to prevent a mobile router from claiming mobile network prefixes + belonging to another mobile router. Upon reception of an implicit + Binding Update from a mobile router, the home agent MUST only add + prefixes into the mobile router's Binding Cache Entry if the mobile + router has a valid DHCPv6 Prefix Delegation lease for said prefixes. + If the mobile router does not have a valid DHCPv6 Prefix Delegation + lease, the home agent MUST NOT add any prefixes into the mobile + router's Binding Cache Entry. Upon the mobile router obtaining a + + + +Droms, et al. Standards Track [Page 10] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + valid DHCPv6 Prefix Delegation lease for a given set of prefixes, the + home agent MUST add these prefixes to the mobile router's Binding + Cache Entry. This avoids the home agent forwarding traffic addressed + to prefixes that have not been yet delegated to the mobile router. + + The use of DHCPv6, as described in this document, requires message + integrity protection and source authentication. When the mobile + router is at home, normal DHCPv6 operation is used between the mobile + router and the home agent and therefore this specification does not + add any new security issue. While the mobile router is away from + home, the IPsec security mechanism mandated by Mobile 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 format used by [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) + + + + +Droms, et al. Standards Track [Page 11] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + 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. 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. + +6. References + +6.1. Normative References + + [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. + + + + +Droms, et al. Standards Track [Page 12] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + + [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. + + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support + in IPv6", RFC 6275, July 2011. + +6.2. Informative References + + [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support + Terminology", RFC 4885, July 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Droms, et al. Standards Track [Page 13] + +RFC 6276 DHCPv6 Prefix Delegation for NEMO July 2011 + + +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 + Internet Systems Consortium + + EMail: fdupont@isc.org + + + 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/ + + + + +Droms, et al. Standards Track [Page 14] + |