GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6245

Internet Engineering Task Force (IETF) P. Yegani Request for Comments: 6245 Juniper Networks Category: Standards Track K. Leung ISSN: 2070-1721 Cisco Systems

                                                               A. Lior
                                                   Bridgewater Systems
                                                          K. Chowdhury
                                                             J. Navali
                                                         Cisco Systems
                                                              May 2011
 Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4

Abstract

 The Generic Routing Encapsulation (GRE) specification contains a Key
 field, which MAY contain a value that is used to identify a
 particular GRE data stream.  This specification defines a new Mobile
 IP extension that is used to exchange the value to be used in the GRE
 Key field.  This extension further allows the Mobility Agents to set
 up the necessary protocol interfaces prior to receiving the mobile
 node traffic.  The new extension allows a Foreign Agent to request
 GRE tunneling without disturbing the Home Agent behavior specified
 for Mobile IPv4.  GRE tunneling with the Key field allows the
 operators to have home networks that consist of multiple Virtual
 Private Networks (VPNs), which may have overlapping home addresses.
 When the tuple <Care of Address, Home Address, and Home Agent
 Address> is the same across multiple subscriber sessions, GRE
 tunneling will provide a means for the Foreign Agent and Home Agent
 to identify data streams for the individual sessions based on the GRE
 key.  In the absence of this key identifier, the data streams cannot
 be distinguished from each other -- a significant drawback when using
 IP-in-IP tunneling.

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/rfc6245.

Yegani, et al. Standards Track [Page 1] RFC 6245 GRE Key Ext. for MIP4 May 2011

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
 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. GRE Key Extension ...............................................3
 4. Operation and Use of the GRE Key Extension ......................3
    4.1. Foreign Agent Requirements for GRE Tunneling Support .......3
    4.2. Home Agent Requirements for GRE Tunneling Support ..........4
    4.3. Mobile Node Requirements for GRE Tunneling Support .........5
 5. GRE Key Extension and Tunneling Procedures ......................5
 6. IANA Considerations .............................................6
 7. Security Considerations .........................................6
 8. Acknowledgements ................................................7
 9. Normative References ............................................7

1. Introduction

 This document specifies a new extension for use by a Foreign Agent
 (FA) operating Mobile IP for IPv4.  The new extension allows a
 Foreign Agent to request Generic Routing Encapsulation (GRE)
 [RFC2784] tunneling without disturbing the Home Agent (HA) behavior
 specified for Mobile IPv4 [RFC5944].  This extension contains the GRE
 key [RFC2890] required for establishing a GRE tunnel between the FA
 and the HA.
 GRE tunneling with the Key field allows the operators to have home
 networks that consist of multiple Virtual Private Networks (VPNs),
 which may have overlapping home addresses.  When the tuple <Care of
 Address, Home Address, and Home Agent Address> is the same across

Yegani, et al. Standards Track [Page 2] RFC 6245 GRE Key Ext. for MIP4 May 2011

 multiple subscriber sessions, GRE tunneling will provide a means for
 the FA and the HA to identify data streams for the individual
 sessions based on the GRE key.  In the absence of this key
 identifier, the data streams cannot be distinguished from each other
 -- a significant drawback when using IP-in-IP tunneling.

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].  Other
 terminology is used as already defined in [RFC5944].

3. GRE Key Extension

 The format of the GRE Key Extension conforms to the extension format
 specified for Mobile IPv4 [RFC5944].  This extension option is used
 by the Foreign Agent to supply GRE key and other necessary
 information to the Home Agent to establish a GRE tunnel between the
 FA and the HA.

4. Operation and Use of the GRE Key Extension

4.1. Foreign Agent Requirements for GRE Tunneling Support

 The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4
 [RFC5944].  The FA may support GRE tunneling that can be used, for
 example, to allow for overlapping private home IP addresses
 (Section 4.2.2.5 of [X.S0011-E]).  If the FA is capable of supporting
 GRE encapsulation, it should set the 'G' (GRE encapsulation) bit in
 the Flags field in the Agent Advertisement message sent to the Mobile
 Node (MN) during the Mobile IP session establishment.
 If the MN does not set the 'G' bit, the FA MAY fall back to using
 IP-in-IP encapsulation for the session per [RFC5944].
 If the MN does not set the 'G' bit and does not set the 'D'
 (Decapsulation by mobile node) bit (i.e., the mobile node does not
 request GRE tunneling and is not using a co-located care-of address),
 and the local policy allows the FA to override the 'G' bit setting
 received from the MN, the FA MUST include the GRE Key Extension as
 defined in this memo in the Registration Request (RRQ) that it
 propagates to the HA.  The presence of this extension is a request
 for GRE encapsulation that takes precedence over the setting of the
 'G' bit in the Registration Request.  The FA MUST NOT modify the 'G'
 bit in the Registration Request because it is protected by the
 Mobile-Home Authentication extension.

Yegani, et al. Standards Track [Page 3] RFC 6245 GRE Key Ext. for MIP4 May 2011

 If the FA does not support GRE encapsulation, the FA MUST reset the
 'G' bit in the Agent Advertisement message.  In this case, if the MN
 sets the 'G' bit in the Registration Request message, the FA returns
 a Registration Reply (RRP) message to the MN with code 'requested
 encapsulation unavailable' (72) per [RFC5944].
 If the FA allows GRE encapsulation, and either the MN requested GRE
 encapsulation or local policy dictates using GRE encapsulation for
 the session, and the 'D' bit is not set (i.e., the mobile node is not
 using a co-located care-of address), the FA MUST include the GRE Key
 in the GRE Key Extension in all Mobile IP Registration Requests
 (including initial, renewal, and de-registration requests) before
 forwarding the request to the HA.  The FA may include a GRE key of
 value zero in the GRE Key Extension to signal that the HA assigns GRE
 keys in both directions.  The GRE key assignment in the FA and the HA
 is outside the scope of this memo.
 The GRE Key Extension SHALL follow the format defined in [RFC5944].
 This extension SHALL be added after the MN-HA and MN-FA Challenge and
 MN-AAA (Mobile Node - Authentication, Authorization, and Accounting)
 extensions (if any) and before the FA-HA Auth extension (if any).

4.2. Home Agent Requirements for GRE Tunneling Support

 The HA MUST follow the procedures specified in [RFC5944] in
 processing this extension in Registration Request messages.
 If the HA receives the GRE Key Extension in a Registration Request
 and does not recognize this non-skippable extension, it MUST silently
 discard the message.  The HA MUST use other alternative forms of
 encapsulation (e.g., IP-in-IP tunneling), when requested by the
 mobile node per [RFC5944].
 If the HA receives the GRE Key Extension in a Registration Request
 and recognizes the GRE Key Extension but is not configured to support
 GRE encapsulation, it MUST send an RRP with code 'requested
 encapsulation unavailable (139)' [RFC3024].
 If the HA receives a Registration Request with a GRE Key Extension
 but without the 'G' bit set, the HA SHOULD treat this as if the 'G'
 bit is set in the Registration Request; i.e., the presence of a GRE
 Key Extension indicates a request for GRE encapsulation.
 If the HA receives the GRE Key Extension in a Registration Request,
 and it recognizes the GRE Key Extension as well as supports GRE
 encapsulation, the following procedures should apply:

Yegani, et al. Standards Track [Page 4] RFC 6245 GRE Key Ext. for MIP4 May 2011

 o  The HA SHOULD accept the RRQ and send an RRP with code
    'registration accepted (0)'.
 o  The HA MUST assign a GRE key and include the GRE Key Extension in
    the RRP before sending it to the FA.
 o  The HA MUST include the GRE Key Extension in all RRPs in response
    to any RRQ that included the GRE Key Extension, when a GRE key is
    available for the registration.
 If the HA receives the GRE Key Extension in the initial Registration
 Request and recognizes the GRE Key Extension carrying a GRE key value
 of zero, it SHOULD accept the RRQ and send an RRP with code
 'registration accepted (0)', and the following procedures apply:
 o  The HA MUST assign GRE keys for both directions and include these
    keys in the GRE Key Extension in the RRP before sending it to
    the FA.
 o  The HA MUST include the GRE Key Extension in the RRP in response
    to the initial RRQ that included the GRE Key Extension, when a GRE
    key is available for the registration.

4.3. Mobile Node Requirements for GRE Tunneling Support

 If the MN is capable of supporting GRE encapsulation, it SHOULD set
 the 'G' bit in the Flags field in the Registration Request per
 [RFC5944].

5. GRE Key Extension and Tunneling Procedures

 GRE tunneling support for Mobile IP will permit asymmetric GRE
 keying; i.e., the FA assigns a GRE key for use in encapsulated
 traffic, and the HA can assign its own GRE key.  Once the GRE keys
 have been exchanged, the FA uses the HA-assigned key in the
 encapsulating GRE header for reverse tunneling, and the HA uses the
 FA-assigned key in the encapsulating GRE header.
 The format of the GRE Key Extension is as shown below.
 The GRE Key Extension MAY be included in Registration Requests or
 Registration Replies [RFC5944].  The GRE Key Extension is used to
 inform the recipient of the Mobile IP request of the value to be used
 in the GRE Key field.

Yegani, et al. Standards Track [Page 5] RFC 6245 GRE Key Ext. for MIP4 May 2011

    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      |   Sub-Type    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Key Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 1: GRE Key Extension
 Type
    48 - An 8-bit identifier of the GRE Key Extension type
    (non-skippable)
 Sub-Type
 Length
    4
 Key Identifier
    This is a four-octet value assigned during registration and
    inserted in every GRE packet of the user traffic.

6. IANA Considerations

 The GRE Key Extension defined in this memo is a Mobile IP extension
 as defined in [RFC5944].  IANA has assigned a Type value (48) for
 this extension from the non-skippable range (0-127).
 The GRE Key Extension introduces a new sub-type numbering space,
 where the value 0 has been assigned from the range 0 to 255.
 Approval of new GRE Key Extension sub-type values is to be made
 through Expert Review with Specification Required.

7. Security Considerations

 This specification does not introduce any new security
 considerations, beyond those described in [RFC5944].

Yegani, et al. Standards Track [Page 6] RFC 6245 GRE Key Ext. for MIP4 May 2011

 Despite its name, the GRE Key Extension has little to do with
 security.  The word "Key" here is not used in the cryptographic sense
 of a shared secret that must be protected but rather in the sense of
 an "index" or demultiplexing value that can be used to distinguish
 packets belonging to a given flow within a GRE tunnel.

8. Acknowledgements

 Thanks to Jun Wang, Gopal Dommety, and Sri Gundavelli for their
 helpful comments, offline discussions, and review of the initial
 draft version of this document.  Also, Pete McCann and Simon
 Mizikovsky provided valuable review comments.

9. Normative References

 [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2784]    Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.
 [RFC2890]    Dommety, G., "Key and Sequence Number Extensions to
              GRE", RFC 2890, September 2000.
 [RFC3024]    Montenegro, G., Ed., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, January 2001.
 [RFC5944]    Perkins, C., Ed., "IP Mobility Support for IPv4,
              Revised", RFC 5944, November 2010.
 [X.S0011-E]  3rd Generation Partnership Project 2, "cdma2000 Wireless
              IP Network Standard: Simple IP and Mobile IP Access
              Services", 3GPP2 X.S0011-002-E Version 1.0,
              November 2009, <http://www.3gpp2.org/Public_html/specs/
              X.S0011-002-E_v1.0_091116.pdf>.

Yegani, et al. Standards Track [Page 7] RFC 6245 GRE Key Ext. for MIP4 May 2011

Authors' Addresses

 Parviz Yegani
 Juniper Networks
 1194 North Mathilda Ave.
 Sunnyvale, California  94089
 USA
 Phone: +1 408-759-1973
 EMail: pyegani@juniper.net
 Kent Leung
 Cisco Systems Incorporated
 170 West Tasman Drive
 San Jose, California  95134
 USA
 Phone: +1 408 526 5030
 EMail: kleung@cisco.com
 Avi Lior
 Bridgewater Systems Corporation
 303 Terry Fox Drive
 Ottawa, Ontario  K2K 3J1
 Canada
 Phone: +1 613-591-6655
 EMail: avi@bridgewatersystems.com
 Kuntal Chowdhury
 Cisco Systems Incorporated
 170 West Tasman Drive
 San Jose, California  95134
 USA
 EMail: kchowdhu@cisco.com
 Jay Navali
 Cisco Systems Incorporated
 170 West Tasman Drive
 San Jose, California  95134
 USA
 EMail: jnavali@cisco.com

Yegani, et al. Standards Track [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6245.txt · Last modified: 2011/05/28 00:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki