Skip to main content

Prefix Delegation for Proxy Mobile IPv6
draft-ietf-netext-pd-pmip-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7148.
Authors Xingyue Zhou , Jouni Korhonen , Carl Williams , Sri Gundavelli , Carlos J. Bernardos
Last updated 2013-02-25
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Basavaraj Patil
IESG IESG state Became RFC 7148 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-netext-pd-pmip-06

   8.   The mobile access gateway relays the DHCPv6 ADVERTISE message to
        the mobile router.

   9.   The mobile router sends the DHCPv6 REQUEST message with the
        IA_PD option(s) received from previous message to the mobile
        access gateway (which is acting as "DHCPv6 Relay Agent").

   10.  The DRA function on the mobile access gateway relays the DHCPv6
        REQUEST message to the DR.

   11.  The DR function on the local mobility anchor responds to the
        REQUEST from the mobile access gateway with a DHCPv6 REPLY
        message.

   12.  The RR function on the mobile router receives one or more IA_PD
        prefix(es) in the DHCPv6 REPLY message sent by the mobile access
        gateway.  The MAG sets up the forwarding for the delegated
        prefixes.  The delegated prefixes are reachable over the MN-MAG
        interface with the MR's link-local address, or home address as
        the next-hop destination.

4.4.2.  Refreshing the Delegated Prefix in Proxy Mobile IPv6

   When the mobile router sends DHCPv6 Renew messages to extend the
   lifetime of the delegated prefix, these messages are also intercepted
   by the mobile access gateway (acting as "DHCPv6 Relay Agent") and are
   relayed to the local mobility anchor (which is acting as "Delegating
   Router").

4.4.3.  Deletion of the Delegated Prefix in Proxy Mobile IPv6

   If the lifetime of the delegated prefix (included in the IA_PD Prefix
   Option carried by the DHCPv6 Reply message) is set to zero, the
   mobile access gateway (which is acting as "DHCPv6 Relay Agent") MUST
   send a proxy binding update message to remove the selective binding
   for that delegated mobile network prefix.  If the request is for
   remove the delegeted mobile network prefix only, the proxy binding
   update message with the lifetime value of (0) MUST NOT include either
   IPv6 Home Network Prefix option [RFC5213] or IPv4 Home Address
   Request option [RFC5844].

Zhou, et al.             Expires August 29, 2013               [Page 13]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

5.  Mobile Access Gateway Operation

5.1.  Extension to Binding Update List Entry Data Structure

   In order to support this specification, the conceptual Binding Update
   List Entry (BULE) data structure needs to be extended with a new
   prefix information field.  This field is used to store the delegated
   IPv4/IPv6 mobile network prefix assigned to the mobile router, which
   is included in the proxy binding acknowledgment.

5.2.  Forwarding

   Forwarding packets sent to the MR's delegated mobile network prefix:

   o  On receiving a packet from the bi-directional tunnel established
      with the local mobility anchor, the mobile access gateway MUST
      first decapsulate the packet (removing the outer header) and then
      use the destination address of the (inner) packet to forward it on
      the interface through which the destination delegated mobile
      network prefix is reachable.

   Forwarding packets sent by the mobile router:

   o  On receiving packets from a mobile router connected to one access
      link, the mobile access gateway MUST ensure that there is an
      established binding for the mobile router and the local mobility
      anchor for the source delegated mobile network prefix before
      tunneling the packet to the MR's local mobility anchor.

   Other considerations from Section 6.10.5 of [RFC5213] also apply
   here.

5.3.  Handover

   When the mobile router moves from the previously attached mobile
   access gateway to the target MAG, the newly attached mobile access
   gateway MAY know the delegated mobile network prefix(es) which were
   assigned to the mobile router during the previous attachment.  It is
   out of scope of this specification how the new mobile access gateway
   could obtain the previously assigned delegated mobile network
   prefix(es) (e.g., from some network element such as the previous
   MAG).  After moving to the new MAG, a proxy binding update message
   including the assigned delegated mobile network prefix(es) (if
   available) MUST be sent by the MAG to the LMA.  The local mobility
   anchor MUST check the delegated mobile network prefix(es) included in
   the PBU message and return the same assigned delegated mobile network
   prefix(es) in the proxy binding acknowledgment message.  If the
   previously assigned mobile network prefix(es) are not known by new

Zhou, et al.             Expires August 29, 2013               [Page 14]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

   MAG, the mobile network prefix(es) MUST be set to unspecified address
   "::" and the prefix length MUST be set to 0 in the proxy binding
   update message sent by the new mobile access gateway to the local
   mobility anchor.  In this case, the local mobility anchor MUST return
   the same previously assigned mobile network prefix(es) in proxy
   binding acknowledgment message.

Zhou, et al.             Expires August 29, 2013               [Page 15]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

6.  Local Mobility Anchor Operation

6.1.  Extension to Binding Cache Entry Data Structure

   In order to support this specification, the conceptual Binding Cache
   Entry (BCE) data structure needs to be extended with a new prefix
   information field.  This field is used to store the IPv4/IPv6
   delegated mobile network prefix(es) assigned to the mobile router and
   included in the proxy binding update (as described in Section 4.2).

6.2.  Forwarding

   Intercepting packets sent to the MR's delegated mobile network
   prefix:

   o  When the local mobility anchor is serving the mobile router, it
      MUST be able to receive/intercept packets destined to the network
      behind the mobile router.  In order to receive these packets, the
      local mobility anchor MUST be the topological anchor of the MR's
      delegated mobile network prefix(es).

   Forwarding packets to the mobile router:

   o  On receiving a packet from a correspondent node with the
      destination address matching the MR's delegated mobile network
      prefix(es), the local mobility anchor MUST forward the packet
      through the bi-directional tunnel set up with the mobile router.

   Other considerations from Section 5.6.2 of [RFC5213] also apply here.

Zhou, et al.             Expires August 29, 2013               [Page 16]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

7.  Security Considerations

   This document describes extensions to the Proxy Mobile IPv6 protocol
   for supporting network mobility using DHCPv6-based Prefix Delegation.
   The security considerations for DHCPv6 described in the "Security
   Considerations" section of the DHCPv6 base specification [RFC3315],
   the "Security Considerations" of the DHCPv6 Prefix Delegation
   specification [RFC3633], and the security considerations from the
   base Proxy Mobile IPv6 [RFC5213] apply when using the extensions
   defined in this document.

   The use of DHCPv6, as described in this document, requires message
   integrity protection and source authentication.  The IPsec security
   mechanism mandated by Proxy Mobile IPv6 [RFC5213] MUST be used to
   secure the DHCPv6 signaling between the mobile access gateway and the
   local mobility anchor.  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 access gateway implementation
   and a local mobility anchor 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 access gateway
   with address "mag_address_1", and a local mobility anchor with
   address "lma_address_1" are assumed.

      mobile access gateway SPD-S:
        - IF local_address = mag_address_1 &
             remote_address = lma_address_1 & proto = UDP &
             local_port = any & remote_port = DHCP
          Then use SA1 (OUT) and SA2 (IN)

      mobile access gateway SAD:
        - SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT):
              local_address = mag_address_1 &
              remote_address = lma_address_1 &
              proto = UDP & remote_port = DHCP
        - SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT):
              local_address = lma_address_1 &
              remote_address = mag_address_1 &
              proto = UDP & local_port = DHCP

      local mobility anchor SPD-S:
        - IF local_address = lma_address_1 &
             remote_address = mag_address_1 & proto = UDP &
             local_port = DHCP & remote_port = any

Zhou, et al.             Expires August 29, 2013               [Page 17]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

          Then use SA2 (OUT) and SA1 (IN)

      local mobility anchor SAD:
        - SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT):
              local_address = lma_address_1 &
              remote_address = mag_address_1 &
              proto = UDP & local_port = DHCP
        - SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT):
              local_address = mag_address_1 &
              remote_address = lma_address_1 &
              proto = UDP & remote_port = DHCP

Zhou, et al.             Expires August 29, 2013               [Page 18]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

8.  IANA Considerations

   This document requires the following IANA action.

   o  Action-1: This specification defines a new Mobility Header option,
      Delegated Mobile Network Prefix option.  This mobility option is
      described in Section 3.1.  The Type value for this option needs to
      be assigned from the same numbering space as allocated for the
      other mobility options, as defined in [RFC6275].

Zhou, et al.             Expires August 29, 2013               [Page 19]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

9.  Acknowledgments

   The work of Carlos J. Bernardos has also been partially supported by
   the European Community's Seventh Framework Programme (FP7-ICT-2009-5)
   under grant agreement n. 258053 (MEDIEVAL project) and by the
   Ministry of Science and Innovation of Spain under the QUARTET project
   (TIN2009-13992-C02-01).

Zhou, et al.             Expires August 29, 2013               [Page 20]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.

   [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.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC4877]  Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
              IKEv2 and the Revised IPsec Architecture", RFC 4877,
              April 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6276]  Droms, R., Thubert, P., Dupont, F., Haddad, W., and C.
              Bernardos, "DHCPv6 Prefix Delegation for Network Mobility
              (NEMO)", RFC 6276, July 2011.

   [RFC6603]  Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
              "Prefix Exclude Option for DHCPv6-based Prefix
              Delegation", RFC 6603, May 2012.

10.2.  Informative References

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

Zhou, et al.             Expires August 29, 2013               [Page 21]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

   [RFC6656]  Johnson, R., Kinnear, K., and M. Stapp, "Description of
              Cisco Systems' Subnet Allocation Option for DHCPv4",
              RFC 6656, July 2012.

Zhou, et al.             Expires August 29, 2013               [Page 22]
Internet-Draft    Prefix Delegation Support for PMIPv6     February 2013

Authors' Addresses

   Xingyue Zhou
   ZTE Corporation
   No.50 Software Avenue, Yuhuatai District
   Nanjing
   China

   Phone: +86-25-8801-4634
   Email: zhou.xingyue@zte.com.cn

   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  FIN-02600
   Finland

   Email: jouni.nospam@gmail.com

   Carl Williams
   Consultant
   San Jose, CA
   USA

   Email: carlw@mcsr-labs.org

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.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/

Zhou, et al.             Expires August 29, 2013               [Page 23]