Internet DRAFT - draft-xia-netext-tunnel-negotiation

draft-xia-netext-tunnel-negotiation






Netext BOF                                                        F. Xia
Internet-Draft                                                    Huawei
Expires: September 6, 2009                                     H. Yokota
                                                                KDDI Lab
                                                             S. Krishnan
                                                                Ericsson
                                                           March 5, 2009


                Tunnel Negotiation for Proxy Mobile IPv6
                 draft-xia-netext-tunnel-negotiation-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 September 6, 2009.

Copyright Notice

   Copyright (c) 2009 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 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.






Xia, et al.             Expires September 6, 2009               [Page 1]

Internet-Draft        Tunnel Negotiation for PMIPv6           March 2009


Abstract

   Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic
   between a Local Mobility Anchor(LMA) and a Mobile Access Gateway
   (MAG) to be tunneled using IPv6, IPv4 ,IPv4-UDP, or GRE encapsulation
   headers.  In this document, a new mobility option is specified for
   tunnel negotiation between the LMA and MAG.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Tunnel Negotiation  . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Local Mobility Anchor Considerations  . . . . . . . . . . . 4
     3.2.  Mobile Access Gateway Considerations  . . . . . . . . . . . 4
   4.  Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Tunnel Type Option  . . . . . . . . . . . . . . . . . . . . 5
     4.2.  Status Codes  . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA consideration  . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative references  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

























Xia, et al.             Expires September 6, 2009               [Page 2]

Internet-Draft        Tunnel Negotiation for PMIPv6           March 2009


1.  Introduction

   Proxy Mobile IPv6 is a network-based mobility management protocol
   that enables mobility without the involvement of the host.  [RFC5213]
   specifies IPv6 address/prefix mobility with the transport network
   being IPv6.  IPsec ESP in tunnel mode MAY be used to protect the
   mobile node's tunneled data traffic.  The support for IPv4 addressing
   or an IPv4 transport network is described in the companion document
   [I-D.ietf-netlmm-pmip6-ipv4-support].  This document supports several
   tunnel encapsulation modes like IPv6 in IPv4, IPv4 in IPv4, IPv6/IPv4
   in IPv4-UDP, or IPv6/IPv4 in IPv4-UDP-ESP.  Furthermore,
   [I-D.ietf-netlmm-grekey-option] defines a new Mobility Option for
   allowing a LMA and MAG to negotiate GRE (Generic Routing
   Encapsulation) encapsulation and exchange downlink and uplink GRE
   keys.

   It is possible that the LMA and MAG have different tunneling
   capability and preference, such as

   o  The LMA and MAG belong to different administrative domains.  The
      LMA may prefer IPSec to IP-in-IP encapsulation based on some
      policy between the MAG's domain and the LMA's.

   o  Network transition from IPv4 to IPv6.  GRE is required for
      supporting mobile nodes with overlapping private IPv4 addresses;
      IPv6-in-IPv4 encapsulation is used when core networks are IPv4
      dominant, while IPv4-in-IPv6 when transport networks are IPv6
      enabled.

   o  QoS control.  GRE key can be exploited when service providers need
      to differentiate flows and provide QoS capabilities for mobile
      nodes.

   o  ...

   In this document, a new mobility option is defined to allow the LMA
   and MAG to negotiate tunnel types.  This option is carried in Proxy
   Binding Update (PBU) and Proxy Binding Acknowledgement(PBA) messages.


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

   The terminology in this document is based on the definitions in
   [RFC5213].



Xia, et al.             Expires September 6, 2009               [Page 3]

Internet-Draft        Tunnel Negotiation for PMIPv6           March 2009


3.  Tunnel Negotiation

   Using the Tunnel Type option defined in Section 4.1 , the MAG and the
   LMA can negotiate encapsulation modes.

   When the mobile access gateway determines, based on, e.g., the MAG
   local policy, the MAG-LMA peer agreement, or loading status, that
   some type of tunnel encapsulation is needed, the mobile access
   gateway MUST include the Tunnel Type option in the Proxy Binding
   Update message sent to the local mobility anchor.  After successfully
   processing the Proxy Binding Update and accepting the tunnel type
   requested from the mobile access gateway, the LMA MUST send a
   successful Proxy Binding Acknowledgement to the MAG including a
   Tunnel Type option.

   If the requested tunnel type is not acceptable, the local mobility
   anchor MUST reject the request and send a Proxy Binding
   Acknowledgement message with Status field set to
   TUNNEL_NEGOTIATION_FAILURE (TBD by IANA), and a Tunnel Type option
   MUST be included in this message to show the LMA's preference of
   encapsulation.  Then the MAG SHOULD initiate a new cycle PBU/PBA
   message exchange.

3.1.  Local Mobility Anchor Considerations

   When the local mobility anchor and the mobile access gateway
   successfully negotiates tunnel type, the local mobility anchor SHOULD
   maintain this as a part of the mobile node Binding Cache Entry(BCE )
   .  This requires that the BCE described in the Proxy Mobile IPv6 base
   specification [RFC5213] be extended.  To support the mechanism
   specified in this document, the BCE must be extended with the
   following additional field.

   o  A tunnel type indicating what kind of encapsulation is used for
      the mobile node's traffic.

3.2.  Mobile Access Gateway Considerations

   Every mobile access gateway maintains a Binding Update List entry for
   each currently attached mobile node, as described in [RFC5213].  To
   support the mechanism specified in this document, the conceptual
   Binding Update List entry data structure must be extended with the
   following new additional field.

   o  A tunnel type indicating what kind of encapsulation is used for
      the mobile node's traffic.





Xia, et al.             Expires September 6, 2009               [Page 4]

Internet-Draft        Tunnel Negotiation for PMIPv6           March 2009


4.  Message Formats

4.1.  Tunnel Type Option

   A new mobility option, the Tunnel Type option, is defined for use in
   Proxy Binding Update and Proxy Binding Acknowledgment messages
   exchanged between the mobile access gateway and the local mobility
   anchor.  This option is used for negotiating tunnel encapsulation
   mode.


        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      |  Reserved     |  Tunnel Type  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type

           <IANA>

       Length

           8-bit unsigned integer indicating the length in octets of
           the option, excluding the type and length fields.

       Reserved
           These fields are unused.  They MUST be initialized to zero
           by the sender and MUST be ignored by the receiver.

       Tunnel Type
            0x01: IPv6/IPv4 in IPv6
            0x02: IPv6/IPv4 in IPv4
            0x03: GRE
            0x04: IPsec ESP
            0x05: IPv6/IPv4 in IPv4-UDP
            0x06: IPv6/IPv4 in IPv4-UDP-TLV
            0x07: IPv6/IPv4 in IPv4-UDP-ESP




                       Figure 1: Tunnel Type Option








Xia, et al.             Expires September 6, 2009               [Page 5]

Internet-Draft        Tunnel Negotiation for PMIPv6           March 2009


4.2.  Status Codes

   The following status code values are defined for use in the Binding
   Acknowledgment message when using Proxy Mobile IPv6.


   TUNNEL_NEGOTIATION_FAILURE (TBD less than 128)

     When the local mobility anchor receives a Proxy Binding Update
     with a Tunnel Type option while the tunnel encapsulation is
     not supported, the LMA uses this code to indicate to the mobile
     access gateway the failure of tunnel negotiation. The mobile
     access gateway then either initiates another PBU/BPA message
     exchange or terminates the registration.



5.  IANA consideration

   This document defines a new Option, the Tunnel Type Option, described
   in Section 4.1.  This option is carried in the Mobility Header.  The
   type value for this option needs to be assigned from the same
   numbering space as allocated for the other mobility options defined
   in the Mobile IPv6 specification [RFC3775].  Status code is also
   needed to be allocated


6.  Security Considerations

   In this document, the PBU and the PBA are piggybacked with tunnel
   type negotiation .  IPsec is mandatory to be used between the LMA and
   the MAG for confidentiality protection on the PBU and PBA messages.


7.  Acknowledgements

   The authors would like to thank Basavaraj Patil and Zoltan Turanyi
   for their valuable reviews and suggested changes to improve this
   document.


8.  References

8.1.  Normative References

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




Xia, et al.             Expires September 6, 2009               [Page 6]

Internet-Draft        Tunnel Negotiation for PMIPv6           March 2009


   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

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

8.2.  Informative references

   [I-D.ietf-netlmm-grekey-option]
              Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
              "GRE Key Option for Proxy Mobile IPv6",
              draft-ietf-netlmm-grekey-option-06 (work in progress),
              February 2009.

   [I-D.ietf-netlmm-pmip6-ipv4-support]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
              (work in progress), January 2009.

































Xia, et al.             Expires September 6, 2009               [Page 7]

Internet-Draft        Tunnel Negotiation for PMIPv6           March 2009


Authors' Addresses

   Frank Xia
   Huawei
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara
   Fujimino, Saitama JP  356-8502

   Phone:
   Email: yokota@kddilabs.jp


   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com























Xia, et al.             Expires September 6, 2009               [Page 8]