Mobility Extensions for IPv6                                    R. Droms
(MEXT)                                                        P. Thubert
Internet-Draft                                                     Cisco
Intended status: Standards Track                               F. Dupont
Expires: February June 23, 2011                                               ISC
                                                               W. Haddad
                                                                Ericsson
                                                           CJ. Bernardos
                                                                    UC3M
                                                         August 22,
                                                       December 20, 2010

                   DHCPv6 Prefix Delegation for NEMO
                       draft-ietf-mext-nemo-pd-06
                       draft-ietf-mext-nemo-pd-07

Abstract

   One aspect of network mobility support is the assignment of a prefix
   or prefixes to a Mobile Router (MR) mobile router for use on the links in the NEMO. 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 on February June 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 the MR mobile router is
           not at home  . . . . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  Relay agent configuration  . . . . . . . . . . . . . .  6  7
       3.1.2.  Transmission of DHCPv6 messages  . . . . . . . . . . .  7  8
       3.1.3.  Receipt of DHCPv6 messages . . . . . . . . . . . . . .  7  8
     3.2.  Exchanging DHCPv6 messages when MR the 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 . . . . . . . . . . . . . . .  9 10
     3.5.  Other DHCPv6 functions . . . . . . . . . . . . . . . . . .  9 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11 12
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11 12
   7.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12
     7.1.  Revision -00 . . . . . . . . . . . . . . . . . . . . . . . 11 12
     7.2.  Revision -01 . . . . . . . . . . . . . . . . . . . . . . . 11 12
     7.3.  Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 11 13
     7.4.  Revision -04 . . . . . . . . . . . . . . . . . . . . . . . 12 13
     7.5.  Revision -05 . . . . . . . . . . . . . . . . . . . . . . . 12 13
     7.6.  Revision -06 . . . . . . . . . . . . . . . . . . . . . . . 12 14
     7.7.  Revision -07 . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12 14
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 15

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.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are model of operation of DHCPv6PD for prefix delegation is as
   follows [RFC3633].  A delegating router is provided IPv6 prefixes to
   be interpreted as described in RFC2119 [RFC2119]. delegated to requesting routers.  A requesting router requests
   prefix(es) from the delegating router.  The following terms used in this document are defined in delegating router chooses
   prefix(es) for delegation, and responds with prefix(es) to the IPv6
   Addressing Architecture document [RFC4291]:

      Link-Local Unicast address

      Link-Local Scope Multicast address
   requesting router.  The following terms used in this document are defined in requesting router is then responsible for the Mobile
   IPv6
   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 uses  With
   the NEMO Basic Support protocol a mobile router uses Mobile IPv6 protocol to
   establish and maintain a session with its HA, home agent, and uses
   bidirectional tunneling between the MR mobile router and HA the home agent
   to provide a path through which nodes attached to links in the NEMO mobile
   network can maintain connectivity with nodes not in the NEMO.

   The requirements for NEMO Network Mobility [RFC4885] include the ability
   of the MR mobile router to receive delegated prefixes that can then be
   assigned to links in the
   NEMO. mobile network.  DHCPv6PD can be used to
   meet this requirement for prefix delegation.

   To use DHCPv6PD for NEMOs, mobile networks, when the HA mobile router is
   located at home the home agent assumes the role of the DR, delegating
   router and the
   MR mobile router assumes the role of the RR requesting
   router.  However, when the mobile router is away from home, in
   addition to the roles when the mobile router is located at home, and the
   mobile router also assumes the role of a
   DRA co-located DHCPv6 relay agent co-
   located with the RR function, when the MR is away from home. requesting router function.

   When the MR mobile router is not at home, the HA home agent and MR the mobile
   router exchange DHCPv6PD protocol messages as specified in RFC3775bis.
   [I-D.ietf-mext-rfc3775bis].  This means that the messages sent by the MR
   mobile router MUST include the Home Address destination option and
   messages sent by the HA 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.

                  ------                ------
                  | 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 MNPs 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 HA 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 MR
   mobile router to which the prefix was delegated.

3.1.  Exchanging DHCPv6 messages when the MR mobile router is not at home

   The case when the MR mobile router is away from home is described in
   this section.  Section 3.2 describes the protocol operation for the
   case when the MR mobile router is attached to its home link.

   The MR mobile router MUST register at the HA (i.e. home agent (i.e., by sending a
   Binding Update to the HA) home agent) before initiating a DHCPv6 message
   exchange for prefix delegation.  Since  The mobile router MUST use implicit
   BU signaling, since the MR mobile router may not have yet requested any prefixes,
   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 the MR mobile router does not have any active delegated prefixes
   (with unexpired leases), the MR initiates mobile router MUST initiate a DHCPv6
   message exchange with a DHCPv6 Solicit message as described in
   section 17 of RFC 3315 [RFC3315] and section 11.1 of RFC 3633. [RFC3633].  The Delegating Router
   delegating router at the HA home agent responds with an Advertise
   message.  Then, the MR requests mobile router MUST request a set of prefixes by
   sending a Request message.  The DR delegating router includes the
   delegated prefixes in a Reply message.  Note that in this case, the MR
   mobile router has previously sent a BU Binding Update to the HA home agent
   without knowing yet the set of prefixes that it can use as MNPs. mobile
   network prefixes.  The HA, home agent, upon reception of the implicit BU
   Binding Update from the MR,
   selects mobile router, MUST select (in case this was
   not pre-configured already) the prefixes that would then be delegated
   to the MR mobile router via DHCPv6PD.  The HA, home agent, once the DHCPv6
   signaling has been completed, adds MUST add an entry in its binding cache
   including the delegated prefixes.

   In case the MR mobile router has one or more active delegated prefixes
   -- as for example if the MR mobile router reboots or the MNP(s) mobile network
   prefix(es) currently used by the mobile router is about to expire --
   the MR initiates mobile router MUST initiate a DHCPv6 message exchange with a
   DHCPv6 Rebind message as described in section 18.1.2 of RFC 3315 [RFC3315] and
   section 12.1 of RFC 3633. [RFC3633].

   A DHPCv6 relay agent function [RFC3315] is MUST be used at the MR. mobile
   router.  This relay agent function is co-located in the MR mobile router
   with the DHCPv6 client function (see Figure 2).  The DHCPv6 signaling
   between the MR mobile router and the
   HA are home agent is exchanged between the
   DHCPv6 relay agent in the MR mobile router and the DHCPv6 server on the HA.
   home agent.  DHCPv6 messages from the MR mobile router to the HA home agent
   are unicast packets sent from the unicast HoA home address of the MR mobile
   router to the global unicast address of the HA, home agent, and therefore
   the Home Address destination option is MUST be used.  DHCPv6 replies
   from the HA home agent to the MR are mobile router MUST be sent using the
   Routing Header type 2, as specified in RFC3775bis. [I-D.ietf-mext-rfc3775bis].
   The DHCPv6 client in the MR hands 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 MR, mobile
   router, which extracts MUST extract the encapsulated message and delivers deliver it to
   the DHCPv6 client in the MR. 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 the MR mobile router is not at home

   Note that an MR a mobile router using DHCPv6PD to obtain the set of
   prefixes to be used as MNPs mobile network prefixes cannot derive its HoA home
   address from an MNP one of its mobile network prefix(es) (as the MR mobile
   router does not know them before registering to the HA). home agent).
   Therefore, the MR is
   assigned mobile router MUST assign its HoA home address from the
   prefix on its Home Link.

3.1.1.  Relay agent configuration

   The use of the relay agent function in the MR mobile router allows the MR
   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 NEMO, this specification, the relay agent assumes that
   the HA home agent for the MR mobile router hosts the DHCPv6 server.
   Therefore, the MR mobile router MUST configure the DHCPv6 relay agent to
   forward DHCPv6 messages to the HA. 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 the MR mobile router sends a message, it hands MUST
   hand the message to the DHCPv6 relay agent in the MR. 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 RFC 3315 [RFC3315] in a Relay-forward message and
   sends the resulting DHCPv6 message to the HA. 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 MR mobile router

   peer-address   A non-link-local address from the MR egress interface
                  (e.g.,   The home address) used to send packets between the
                  HA and address of the MR 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 extracts MUST extract the message for the client from the Relay
   Message option and hands hand the message to the DHCPv6 client in the MR.
   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 MR the mobile router is at home

   When the MR mobile router is on its home link, the HA uses home agent MUST use
   the home link to exchange DHCPv6PD messages with the MR mobile router
   (Figure 3).  In this case, the DHCPv6 co-located relay function is MUST
   be disabled.  It is the responsibility of the implementation to
   determine when the MR mobile router is on its home link.  The Home Link
   Detection mechanism is described in the section 11.5.2 of RFC3775bis.
   [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 the HA home agent is at home

3.3.  Selecting an HA a home agent that provides DHCPv6PD

   Not all nodes that are willing to act as an HA a home agent are required to
   provide DHCPv6PD.  Therefore, when selecting an HA, an MR a home agent, a mobile
   router that requires DHCPv6PD service must MUST identify an HA a home agent that
   will provide the service.  The MR mobile router can determine if an HA a home
   agent provides DHCPv6PD by initiating a DHCPv6 message exchange (i.e.
   (i.e., sending a Solicit message) in which the MR mobile router requests
   delegated prefix(es).  If the HA home agent does not respond or responds
   but does not delegate any prefix(es) in its response, the MR mobile
   router assumes that the HA home agent does not provide DHCPv6PD service.
   The MR mobile router continues to query all candidate HAs home agents until
   it finds
   an HA one that provides DHCPv6PD.  Note that in this particular
   case and if the MR mobile router is away from home, the MR mobile router
   has to have already performed an
   MIPv6 a Mobile IPv6 registration with the HA
   home agent it queries.

   Querying an HA a home agent to determine if it provides DHCPv6PD requires a small
   modification to
   different operational variables than those recommended by the operation of DHCPv6 as described in RFC 3315.
   Under
   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 RFC
   3315). [RFC3315]), i.e., the Maximum
   Retransmission Duration (MRD) and Maximum Retransmission Count (MRC)
   are both set to zero.  However, an HA a home agent may choose not to respond to the
   Solicit messages from the MR mobile router because the HA home agent does
   not provide DHCPv6. support DHCPv6 prefix delegation.  Therefore, when querying an HA a
   home agent to determine if the HA home agent provides DHCPv6PD service,
   it is RECOMMENDED that MRD and MRC be set to non-zero values so that
   the MR SHOULD discontinue mobile router discontinues sending Solicit messages to the HA home
   agent after sending 6 Solicit messages, and conclude that the HA 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 BU Binding Update
   message.

   It is recommended RECOMMENDED that the MR mobile router uses a sequential probing of
   the HAs home agents for DHCPv6PD service.

3.4.  Minimizing DHCPv6PD messages

   The use DHCPv6PD in a NEMO 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 DR.
   delegating router.

3.5.  Other DHCPv6 functions

   The DHCPv6 messages exchanged between the MR mobile router and the HA home
   agent MAY also be used for other DHCPv6 functions in addition to
   DHCPv6PD.  For example, the HA home agent MAY assign global addresses to
   the MR mobile router and MAY pass other configuration information such
   as a list of available DNS recursive name servers [RFC3646] to the MR
   mobile router using the same DHCPv6 messages as used for DHCPV6PD. DHCPv6PD.

   The HA home agent MAY act as a DHCPv6 relay agent for Mobile Nodes mobile nodes while
   it acts as a DR delegating router for MRs. mobile routers.

4.  Security Considerations

   This document describes the use of DHCPv6 for prefix delegation in
   NEMO.
   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 HA home agent
   to prevent an MR a mobile router from claiming MNPs mobile network prefixes
   belonging to another MR. mobile router.  Upon reception of an implicit BU
   Binding Update from an MR, a mobile router, the HA home agent MUST only add
   prefixes into the MR's mobile router's Binding Cache Entry if the MR mobile
   router has a valid DHCPv6 Prefix Delegation lease for said prefixes.
   If the MR mobile router does not have a valid DHCPv6 Prefix Delegation
   lease, the HA home agent MUST NOT add any prefixes into the MR's mobile
   router's Binding Cache Entry.  Upon the MR mobile router obtaining a
   valid DHCPv6 Prefix Delegation lease for a given set of prefixes, the HA
   home agent MUST add these prefixes to the MR's mobile router's Binding
   Cache Entry.  This avoids the HA home agent forwarding traffic addressed
   to prefixes that have not been yet delegated to the MR. mobile router.

   The use of DHCPv6, as described in this document, requires message
   integrity protection and source authentication.  When the MR mobile
   router is at home, normal DHCPv6 operation is used between MR the mobile
   router and HA the home agent and therefore this specification does not
   add any new security issue.  While the MR mobile router is away from
   home, the IPsec security mechanism mandated by MIPv6 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 than that used by of [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 in
   NEMOs.
   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.

   Since RFC3775bis [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/