One document matched: draft-tsirtsis-l2gre-pmipv4-00.txt
Network Working Group G. Tsirtsis
Internet-Draft V. Park
Intended status: Standards Track Qualcomm
Expires: November 5, 2007 May 4, 2007
GRE-based L2 Tunneling with PMIPv4
draft-tsirtsis-l2gre-pmipv4-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 November 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Tsirtsis & Park Expires November 5, 2007 [Page 1]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
Abstract
This specification introduces mechanisms for creating a GRE-based L2
Tunnel with PMIPv4.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Flag definition for GRE key Extension . . . . . . . . . . . . 6
5. Initial Registration . . . . . . . . . . . . . . . . . . . . . 7
5.1. Sending the Registration Request . . . . . . . . . . . . . 7
5.2. Receiving the Registration Request . . . . . . . . . . . . 7
5.3. Sending the Registration Reply . . . . . . . . . . . . . . 8
5.4. Receiving the Registration Reply . . . . . . . . . . . . . 8
5.5. Registration Tables . . . . . . . . . . . . . . . . . . . 9
5.5.1. Home Agent . . . . . . . . . . . . . . . . . . . . . . 9
5.5.2. Mobility Proxy Agent . . . . . . . . . . . . . . . . . 9
6. Reregistrations . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Registration Request . . . . . . . . . . . . . . . . . . . 10
6.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 10
7. L2 Tunneling and Address Allocation . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Tsirtsis & Park Expires November 5, 2007 [Page 2]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
1. Requirements notation
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].
Tsirtsis & Park Expires November 5, 2007 [Page 3]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
2. Introduction
The Mobile IPv4 (MIPv4) specification [RFC3344] defines optional
support for GRE tunneling [RFC2784]. Additionally, there is work in
progress on defining extensions that enable signaling of GRE keys
[RFC2890] to be used when MIPv4 uses GRE tunneling
[draft-yegani-gre-key-extension-02.txt], and also work in progress on
defining mobility management based on Proxy Mobile IPv4 (PMIPv4)
[draft-leung-mip4-proxy-mode-02.txt].
The primary use case for [draft-yegani-gre-key-extension-02.txt] is
the use of GRE keys to support overlapping IPv4 address spaces on the
same HA. The mechanisms defined by
[draft-yegani-gre-key-extension-02.txt] anticipate the use of
unidirectional GRE keys under the control of the sender i.e., the FA
(or equivalently the MPA in the case of PMIPv4) indicates (in a
Registration Request message) the GRE key to be used for reverse
tunneling, and the HA indicates (in the corresponding Registration
Reply message) the GRE key to be used for forward tunneling.
In this document, the mechanisms defined in
[draft-yegani-gre-key-extension-02.txt] are extended to support the
use of bidirectional GRE keys under the control of the HA that can be
MN specific, realm specific, or otherwise.
Also, the mechanisms defined in this specification allow a GRE-based
L2 tunnel to be created without necessarily allocating an address to
the MN. This allows MNs to use any address configuration mechanism
they want directly with the HA including, DHCPv4, DHCPv6, Stateless
Address Autoconfiguration etc.
Tsirtsis & Park Expires November 5, 2007 [Page 4]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
3. Overview
In this specification, we define that when the Key Identifier field
in a GRE Key extension [draft-yegani-gre-key-extension-02.txt]
included in a Registration Request message is set to a predefined
known value (i.e., "0"), the MPA requests that the HA assign a
bidirectional GRE key for the given registration. The HA allocates a
bidirectional GRE key and returns it in the Key Identifier field of a
GRE Key extension in the Registration Reply message. Thus, the value
of the Key Identifier field returned by the HA is used as the GRE key
for both forward and reverse tunneled packets.
The mechanisms defined herein, also allow a GRE-based L2 tunnel to be
established via PMIPv4. The MN can then run any address allocation
procedure, including DHCPv4 and stateless address autoconfiguration
for IPv6 etc, directly with the HA on which the L2 tunnel terminates.
To enable this capability, a new flag is defined in the GRE Key
extension [draft-yegani-gre-key-extension-02.txt], requesting the
establishment of an GRE-based L2 tunnel. In that case, the binding
created in the HA is between a GRE key and a CoA. This requires the
use of unidirectional or bidirectional GRE keys that are unique per
MN.
Tsirtsis & Park Expires November 5, 2007 [Page 5]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
4. Flag definition for GRE key Extension
The following extension is based on the GRE Key extension defined in
[draft-yegani-gre-key-extension-02.txt]. This specification defines
the "A" flag shown below, from within the field previously defined as
Reserved.
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 |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
See [draft-yegani-gre-key-extension-02.txt]
Length
See [draft-yegani-gre-key-extension-02.txt]
A
Requests GRE-based L2 Tunneling Mode
Reserved
See [draft-yegani-gre-key-extension-02.txt]
Key Identifier
See [draft-yegani-gre-key-extension-02.txt]
Tsirtsis & Park Expires November 5, 2007 [Page 6]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
5. Initial Registration
5.1. Sending the Registration Request
According to [draft-yegani-gre-key-extension-02.txt], an FA (or
presumably MPA) can send a Registration Request message with a GRE
Key extension to request use of GRE keys as part of GRE tunneling.
This specification allows the sender of a Registration Request
message with a GRE Key extension to further request the use a GRE-
based L2 tunnel by setting the "A" flag as follows:
"0" Indicates normal GRE Tunneling Mode.
"1" Indicates GRE-based L2 Tunneling Mode. In this case the Key
Identifier(s) corresponding to the registration MUST be unique per
MN.
In accordance with this specification, the MPA can also request the
use of a bidirectional key according to value of the Key Identifier
field of the GRE Key extension in the Registration Request message:
When the Key Identifier field is set to "0" the sender requests a
bidirectional GRE key to be defined by the HA.
When the Key Identifier field is set to any other value, it
indicates the value of the GRE key to be used for tunneling from
the MPA to the HA.
5.2. Receiving the Registration Request
The following defines GRE Key extension processing to be performed by
the HA in addition to that described in
[draft-yegani-gre-key-extension-02.txt].
If in a Registration Request message with a GRE Key extension, the
Key Identifier field is set to "0" and the A flag is set to "0", then
the HA MUST allocate a bidirectional GRE key, which need not be
unique per MN. The allocated bidirectional GRE key MAY be realm
specific or otherwise based on HA policy.
If in a Registration Request message with a GRE Key extension, the
Key Identifier is set to a value other than "0" and A flag is set to
"0", then the HA SHOULD accept the value of the Key Identifier field
as the GRE key to be used for reverse tunneling from the MPA to the
HA and allocate a unidirectional GRE key, which need not be unique
per MN, to be used for forward tunneling. The allocated
unidirectional GRE key MAY be realm specific or otherwise based on HA
policy.
Tsirtsis & Park Expires November 5, 2007 [Page 7]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
If in a Registration Request message with a GRE Key extension, the
Key Identifier is set to "0" and the A flag is set to "1", then the
HA MUST allocate a bidirectional GRE key, which MUST be unique per
MN. In this case the HA, creates an L2 tunnel for the MN and
maintains a binding between the bidirectional GRE key and the CoA of
the MN.
If in a Registration Request message with a GRE Key extension, the
Key Identifier is set to a value other than "0" and the A flag is set
to "1", then the HA SHOULD accept the value of the Key Identifier
field as the GRE key to be used for reverse tunneling from the MPA to
the HA and allocate a unidirectional GRE key, which MUST be unique
per MN, to be used for forward tunneling. In this case the HA,
creates an L2 tunnel for the MN and maintains a binding between the
GRE keys for each direction and the CoA of the MN.
5.3. Sending the Registration Reply
Provided a Registration Request message with a GRE Key extension is
accepted, the HA MUST include a GRE Key extension in the
corresponding Registration Reply message. In all cases, the Key
Identifier field of the GRE Key extension included in the
Registration Reply message is set to the value of the GRE key
allocated by the HA in response to the corresponding Registration
Request message. The A flag of the GRE Key extension included in the
Registration Reply message is set to the same value as the A flag of
the corresponding Registration Request message.
If the GRE key extension is not accepted by the HA, the Registration
Request SHOULD be rejected with an appropriate rejection code e.g.,
Administratively Prohibited, as per [RFC3344].
5.4. Receiving the Registration Reply
Provided a Registration Request message with a GRE Key extension is
accepted, the Registration Reply message will also include a GRE key
extension.
If the GRE key extension in the Registration Request message included
a Key Identifier value of "0" then, the receiver of this message MUST
accept the value of the Key Identifier field in the GRE key extension
in the Registration Reply message as the bidirectional GRE key to be
used for this MN.
If the GRE key extension in the Registration Request message included
a Key Identifier value other than "0" then, the receiver of this
message MUST accept the value of the Key Identifier field in the GRE
key extension in the Registration Reply message as the GRE key to be
Tsirtsis & Park Expires November 5, 2007 [Page 8]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
used for this MN in the forward direction.
5.5. Registration Tables
5.5.1. Home Agent
In addition to what is defined in [RFC3344], Section 3.8.1., the
following information needs to be retained by the HA:
- the mobile node's GRE key in the reverse direction
- the mobile node's GRE key in the forward direction
Also note that unlike what is indicated in the same section of
[RFC3344], in some cases the HoA may not be known.
5.5.2. Mobility Proxy Agent
While not explicitly outlined in
[draft-leung-mip4-proxy-mode-02.txt], an MPA must maintain
information associated with registrations. In addition to what is
required in support of [draft-leung-mip4-proxy-mode-02.txt], the
following information needs to be retained by the MPA:
- the mobile node's GRE key in the reverse direction
- the mobile node's GRE key in the forward direction
Tsirtsis & Park Expires November 5, 2007 [Page 9]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
6. Reregistrations
6.1. Registration Request
The MPA SHOULD include the GRE Key extension in all reregistrations.
If the GRE key, set-up by an earlier MPA, is known, it SHOULD be
included in the Key Identifier field of the extension. If the GRE
key is not known or a different one needs to be negotiated, the
reregistration message has to follow the same rules with the initial
registration message defined in Section 5.1.
6.2. Registration Reply
Assuming the subsequent Registration Request message includes a GRE
key extension that reflects the negotiated GRE key, the HA simply
copies the extension to the Registration Reply.
If the GRE key extension included in the subsequent Registration
Request does not reflect the agreed key, the request will have the
same effect as the initial request and the HA MUST treat it as in
Section 5.2 and the reply MUST be formed as defined in Section 5.3.
Tsirtsis & Park Expires November 5, 2007 [Page 10]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
7. L2 Tunneling and Address Allocation
When a GRE-based L2 tunnel is requested (the A flag in the GRE key
extension is set to "1", see Section 5.1), the binding communicated
by the Registration Request message is between the GRE key(s) and the
CoA rather than an HoA and the CoA.
Unlike [RFC3344], in this case, if the HoA field of the Registration
Request message is set to "0", the HA is NOT REQUIRED to allocate an
IP Address in the Registration Reply message. Instead the HA MAY
also set the HoA field in the Registration Reply message to "0".
Also, when L2 Tunneling is used as defined in this specification, the
MN MAY use DHCPv4, DHCPv6, IPv6 Address Autoconfiguration or any
other mechanism directly with the HA, to configure its addresses.
After addresses have been allocated, the MN MAY register them with
the HA using appropriate MIPv4 mechanisms.
Tsirtsis & Park Expires November 5, 2007 [Page 11]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
8. Security Considerations
This specification operates in the security constraints and
requirements of the underlying protocols.
Tsirtsis & Park Expires November 5, 2007 [Page 12]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
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.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
Tsirtsis & Park Expires November 5, 2007 [Page 13]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
Authors' Addresses
George Tsirtsis
Qualcomm
Phone: +908-443-8174
Email: tsirtsis@qualcomm.com
Vincent Park
Qualcomm
Phone: +908-443-8141
Email: vpark@qualcomm.com
Tsirtsis & Park Expires November 5, 2007 [Page 14]
Internet-Draft GRE-based L2 Tunneling with PMIPv4 May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tsirtsis & Park Expires November 5, 2007 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 21:18:57 |