One document matched: draft-yegani-gre-key-extension-04.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- <?rfc editing="yes"?> -->
<?rfc compact="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="pre5378Trust200902" category="std" docName="draft-yegani-gre-key-extension-04.txt">

<front>

<title abbrev="GRE Key Ext. for MIP4">GRE Key Extension for Mobile IPv4</title>

<author initials="P" surname="Yegani" fullname="Parviz Yegani">
    <organization abbrev="Juniper Networks">Juniper Netowrks</organization>
    <address>
      <postal>
        <street>1194 North Mathilda Ave.</street>
        <city>Sunnyvale</city>
        <region>California</region>
        <code>94089</code>
        <country>U.S.A</country>
      </postal>
      <phone>+1 408-759-1973</phone>
      <email>pyegani@juniper.net</email>
    </address>
</author>

<author initials="G" surname="Dommety" fullname="Gopal Dommety">
    <organization abbrev="Cisco Systems">Cisco Systems Inc.</organization>
    <address>
      <postal>
        <street>170 West Tasman Dr.</street>
        <city>San Jose</city>
        <region>California</region>
        <code>95134</code>
        <country>U.S.A</country>
      </postal>
      <phone>+1 408 525 1404</phone>
      <email>gdommety@cisco.com</email>
    </address>
</author>
    
    
<author initials="A" surname="Lior" fullname="Avi Lior">
    <organization abbrev="Bridgewater Systems">Bridgewater Systems Corporation</organization>
    <address>
      <postal>
        <street>303 Terry Fox Drive</street>
        <city>Ottawa</city>
        <region>Ontario</region>
        <code>K2K 3J1</code>
        <country>Canada</country>
      </postal>
      <phone>+1 613-591-6655</phone>
      <email>avi@bridgewatersystems.com</email>
    </address>
    </author>

    <author initials="K.C" surname="Chowdhury" fullname="Kuntal Chowdhury">
      <organization abbrev="Starent Networks">Starent Networks</organization>
    <address>
      <postal>
        <street>30 International Place</street>
        <city>Tewksbury</city>
        <region>MA</region>
        <code>01876</code>
        <country>USA</country>
      </postal>
      <phone>+1 214 550 1416</phone>
      <email>kchowdhury@starentnetworks.com</email>
    </address>
    </author>

<author initials="J.N" surname="Navali" fullname="Jay Navali">
      <organization abbrev="Starent Networks">Starent Networks</organization>
    <address>
      <postal>
        <street>30 International Place</street>
        <city>Tewksbury</city>
        <region>MA</region>
        <code>01876</code>
        <country>USA</country>
      </postal>
      <phone>+1 978 851 1141</phone>
      <email>jnavali@starentnetworks.com</email>
    </address>
    </author>
    
<date month="July" year="2009"/>    

<abstract>

<t>The 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 setup the necessary protocol 
interfaces prior to receiving the mobile's traffic. The new extension 
option allows a foreign agent to request GRE tunneling without 
disturbing the Home Agent behavior specified for Mobile Ipv4. 
GRE tunneling provides an advantage that allows operator's private 
home networks to be overlaid and allows the HA to provide overlapping 
home addresses to different subscribers.  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 FA and 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.</t>
     
</abstract>

</front>

<middle>

<section title="Introduction">

<t>This document specifies a new extension for use by Foreign Agents 
operating Mobile IP for IPv4.  The new extension option allows a 
foreign agent to request GRE tunneling without disturbing the 
Home Agent behavior specified for Mobile IPv4 <xref target="RFC3344"/>. 
This extension contains the GRE key and other necessary information 
required for establishing a GRE tunnel between the FA and the HA.</t>

<t>GRE tunneling provides an advantage that allows operator's private 
home networks to be overlaid and it allows the HA to provide 
overlapping home addresses to different subscribers.  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 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.</t>

</section>

<section title="Terminology">

<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in <xref target="RFC2119"/>.  
Other terminology is used as already defined in 
<xref target="RFC3344"/>.</t>
</section>


<section title="GRE-Key Extension">

<t>The format of the GRE-Key Extension conforms to the Extension format 
specified for Mobile IPv4 [RFC3344].  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.</t>
</section>

<section title="Operation and Use of the GRE-Key Extension">

<section title="Foreign Agent Requirements for GRE Tunneling Support">

<t>The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4 
<xref target="RFC3344"/>.  The FA may support GRE tunneling that can be 
used, for example, to allow for overlapping private home IP addresses 
[X.S0011-D]. If the FA is capable of supporting GRE encapsulation, it 
should set the 'G' bit in the Flags field in the Agent Advertisement 
message sent to the MN during the Mobile IP session establishment.</t>

<t>If the MN does not set the 'G' bit, the FA MAY fall back to using 
IP-in-IP encapsulation for the session per <xref target="RFC3344"/>.</t>
<t>If the MN does not set the 'G' bit, and the local policy allows the 
FA to override the 'G' bit setting received from the MS, the FA MUST 
include the GRE-Key Extension as defined in this memo in the 
Registration Request message to request GRE encapsulation for the 
session. </t>

<t>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 message to the MN with code 'Requested Encapsulation 
Unavailable' (0x48) per <xref target="RFC3344"/>.</t>

<t>If  the FA allows GRE encapsulation, and either the MN requested GRE 
encapsulation or local policy dictates using GRE encapsulation for the 
session, 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 assign GRE keys in both directions.  The GRE key assignment 
in the FA and the HA is outside the scope of this memo.</t>

<t>The GRE Key Extension SHALL follow the format defined in 
<xref target="RFC3344"/>.  This extension SHALL be added after the 
MN-HA and MN-FA Challenge and MN-AAA extensions (if any) and before the 
FA-HA Auth extension (if any). </t>

</section>

<section title="Home Agent Requirements for GRE Tunneling Support">

<t>The HA MUST follow the procedures specified in RFC 3344 in 
processing this extension in Registration Request messages. If the HA 
receives the GRE Key Extension in a Registration Request and does not 
recognize GRE Key Extension, it MUST send an RRP with code 
'Unknown Extension (0xY1)' per <xref target="RFC3344"/>.</t>

<t>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 Encapsulati
on Unavailable (0xYY)'.</t>

<t>If the HA receives a Registration Request with the 'G' bit set but 
without the GRE Key Extension, it SHALL send an RRP with code 
'Poorly Formed Request (0xY2)'.</t>

<t>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 'G' bit is 
set in the Registration Request i.e., the presence of GRE Key Extension 
indicates a request for GRE encapsulation.</t>

<t>If the HA receives the GRE Key Extension in a Registration Request 
and recognizes the GRE Key Extension as well as supports GRE 
encapsulation, the following procedures should apply:</t>

<t>The HA SHOULD accept the RRQ and send a RRP with code 
'Accepted (0)'. The HA MUST assign a GRE key and include the GRE Key 
Extension in the RRP before sending it to the FA. The HA MUST include 
the GRE Key Extension in all RRPs in response to any RRQ that included 
GRE Key Extension, when a GRE key is available for the registration.</t>

<t>
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 a RRP with code 'Accepted (0)'.  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.  The HA MUST include 
the GRE Key Extension in the RRP in response to the initial RRQ that included 
GRE Key Extension, when a GRE key is available for the registration. </t>

</section>

<section title="Mobile Node Requirements for GRE Tunneling Support">

<t>If the MN is capable of supporting GRE encapsulation, it SHOULD set 
the 'G' bit in the Flags field in the Registration Request per 
<xref target="RFC3344"/>.</t>

</section>

</section>

<section title="GRE Key Extension and Tunneling Procedures">

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

<t>The format of the GRE Key Extension is as shown below. </t>

<t>The GRE Key extension MAY be included in Registration Requests 
<xref target="RFC3344"/>,
whose 'G' bit is enabled. The GRE Key extension is used to inform the 
recipient of the Mobile IP request of the value to be used in GRE's 
Key field. </t>

<figure anchor="Figure 1" title="GRE Key Extension">
<artwork><![CDATA[

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Key Identifier                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         TBD (non-skippable) [2]

      Length

         6

      Reserved

         This field MUST be set to zero (0).

      Key Identifier  

         This is a four octet value assigned in the Registration and 
         inserted in every GRE frame.

]]></artwork>
</figure>

</section>

<section title="IANA Considerations">

<t>The GRE Key extension defined in this memo is as defined in 
<xref target="RFC3344"/>. IANA should assign a value for this Extension.
</t>

</section>

<section title="Security Considerations">
<t>This specification does not introduce any new security 
considerations, beyond those described in <xref target="RFC3344"/></t>
</section>

<section title="Acknowledgements">

<t>Thanks to ...</t>

</section>

</middle>

<back>

<references title="Normative references"> 
<?rfc include='reference.RFC.2119.xml'?>
<?rfc include='reference.RFC.2890.xml'?>
<?rfc include='reference.RFC.3344.xml'?>
</references>

</back>
</rfc>