Internet DRAFT - draft-gundavelli-mext-dsmip-ipv4-overlap
draft-gundavelli-mext-dsmip-ipv4-overlap
MEXT WG S. Gundavelli
Internet-Draft Cisco
Intended status: Standards Track J. Laganier
Expires: April 24, 2012 Qualcomm
H. Yokota
KDDI Lab
C. Williams
Consultant
October 22, 2011
Overlapping IPv4 Address Assignment Support for Dual-stack Mobile IPv6
draft-gundavelli-mext-dsmip-ipv4-overlap-03
Abstract
There are number of deployment scenarios where there is a need for a
home agent to allocate the same private IPv4 address to multiple
mobile nodes that it is serving. A service provider hosting home
agent service for enterprises, or for supporting some of the IPv6
transitioning solutions related to IPv4 address exhaust problem, a
home agent may have to allocate the same private IPv4 address to
multiple mobile nodes. The Dual-stack Mobile IPv6 does not have such
support. This document specifies extensions to Dual-stack Mobile
IPv6 for supporting overlapping private IPv4 address assignment
support.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 24, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gundavelli, et al. Expires April 24, 2012 [Page 1]
Internet-Draft Overlapping IPv4 Address Support October 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Usecase Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6
3.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7
4.1. Home Agent Considerations . . . . . . . . . . . . . . . . 7
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 7
4.1.2. Signaling Considerations . . . . . . . . . . . . . . . 7
4.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 8
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Gundavelli, et al. Expires April 24, 2012 [Page 2]
Internet-Draft Overlapping IPv4 Address Support October 2011
1. Introduction
IPv4 support for Mobile IPv6 [RFC6275] is specified in Dual-stack
Mobile IPv6 [RFC5555]. However, it does not have explicit support
for allocating overlapping IPv4 addresses to the mobile nodes that it
is serving.
There are number deployment scenarios where there is a need for a
home agent to allocate the same private IPv4 address to multiple
mobile nodes. For example, in service provider hosted home agent
deployment models, two mobile nodes from different enterprises may
have to be assigned IPv4 addresses from the same overlapping address
space. Another example is found in the 3GPP system architecture when
a single home agent serves two packet data networks that uses
overlapping private address space. In this case, two mobile nodes
attached to each of these packet data networks may have to be
assigned IPv4 addresses from the same overlapping address space.
Additionally, the IPv6 transitioning solutions such as Per-Interface
Bindings [I-D.draft-arkko-dual-stack-extra-lite] and Gateway
Initiated Dual-stack Lite [I-D.draft-softwire-gateway-init-ds-lite],
both the solutions require support for overlapping private IPv4
addressing support.
This document specifies extensions to Dual-stack Mobile IPv6 for
supporting overlapping private IPv4 address assignment support.
Gundavelli, et al. Expires April 24, 2012 [Page 3]
Internet-Draft Overlapping IPv4 Address Support October 2011
2. Usecase Scenarios
This section identifies the use case scenarios where an home agent is
required to assign IPv4 addresses to mobile nodes from an overlapping
IPv4 private address space.
203.0.113.0/24
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
_----_ . _-----_ .
_( )_ . _( )_ +----+ .
( ENT-A )-===-. .=====( DSMIP6 )=======|MN-A| .
(_ _) . \ +----------+ / (_ Tunnel_) +----+ .
'----' . \| | / '-----' 203.0.113.9 .
. |Home Agent|-- (MN-A@ENT-A.COM) .
_----_ . /| | \ _-----_ .
_( )_ . / +----------+ \ _( )_ +----+ .
( ENT-B )-==.-. .=====( DSMIP6 )=======|MN-B| .
(_ _) . (_ Tunnel_) +----+ .
'----' . '-----' 203.0.113.9 .
. (MN-B@ENT-B.COM).
203.0.113.0/24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(Home Agent Service Provider)
Figure 1: Hosted Home Agent Service for enterprises
Figure 1, illustrates the scenario where an home agent in a service
provider network is supporting hosted home agent service model. The
home agent has a direct forwarding path to each of the enterprises,
which allows the home agent to receive from/forward to the mobile
node.
_-----_
_( )_ +----+
.=====( DSMIP6 )=============|MN-A|
_----_ +----------+ / (_ Tunnel_) Tunnel-0 +----+
_( )_ | . | / '-----' 203.0.113.9
-( Internet )---| CGN . HA |--
(_ _) | . | \ _-----_
'----' +----------+ \ _( )_ +----+
.=====( DSMIP6 )============|MN-B|
(_ Tunnel_) Tunnel-1 +----+
'-----' 203.0.113.9
Gundavelli, et al. Expires April 24, 2012 [Page 4]
Internet-Draft Overlapping IPv4 Address Support October 2011
Figure 2: Support for Per-Interface Bindings Specification
Figure 2, illustrates the scenario where an home agent supports Per-
Interface Bindings solution, specified in
[I-D.draft-arkko-dual-stack-extra-lite]. In this scenario, the CGN
is collocated with the home agent, and each the mobile node NAT
binding entries have the interface identifier of the DSMIPv6 tunnel,
established between the mobile node and the home agent. The home
agent uses the interface identifier for making the packet forwarding
decision.
_-----_
_( )_ +----+
.=====( DSMIP6 )=======|MN-A|
_----_ +-----+ +----+ / (_ Tunnel_) +----+
_( )_ | | | | / '-----' 203.0.113.9
-( Internet )--| CGN |===| HA |--
(_ _) | | | | \ _-----_
'----' +-----+ +----+ \ _( )_ +----+
.=====( DSMIP6 )=======|MN-B|
(_ Tunnel_) +----+
'-----' 203.0.113.9
Figure 3: Support for Gateway Initiated Dual-stack Lite
Figure 3, illustrates the scenario where an home agent has support
for the IPv6 transitioning solution, Gateway Initiated Dual-stack
lite solution, specified in
[I-D.draft-softwire-gateway-init-ds-lite]. In this scenario, there
is typically a GRE tunnel between the CGN gateway and the home agent.
Every IPv4 packet tunneled between the CGN and the home agent carries
a context identifier in the GRE Key header unique to a mobile node,
which allows the home agent to forward the packet to the correct
mobile node.
Gundavelli, et al. Expires April 24, 2012 [Page 5]
Internet-Draft Overlapping IPv4 Address Support October 2011
3. Conventions & Terminology
3.1. Conventions
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 RFC 2119 [RFC2119].
3.2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in the Mobile IPv6 specification [RFC6275].
Additionally, this document uses the following abbreviations:
o CGN - Carrier Grade NAT
o Overlapping Address Space - Private IPv4 Address Space [RFC6275]
that is reused across different networks.
Gundavelli, et al. Expires April 24, 2012 [Page 6]
Internet-Draft Overlapping IPv4 Address Support October 2011
4. Protocol Considerations
4.1. Home Agent Considerations
4.1.1. Extensions to Binding Cache Entry
To support this feature, the conceptual Binding Cache entry data
structure maintained by the home agent needs to be extended to
include the following new parameter.
o IPv4-overlap-ctx-id: A 4-byte field used for storing the context
identifier field. The home agent uses this value in this field
for making the forwarding decision.
4.1.2. Signaling Considerations
The following considerations MUST be applied by the home agent when
allocating overlapping private IPv4 address to a mobile node from an
overlapping IPv4 private address space.
o On receiving a Binding Update message [RFC6275] from a mobile node
with the home address option [RFC5555], the home agent MUST
process the request as specified in [RFC5555].
o If the home agent based on the policy considerations determines
that the mobile node MUST be assigned an IPv4 address from a non-
overlapping IPv4 address space, no additional considerations from
this specification need to be applied.
o If the Mobile Node Identifier option [RFC4283] is not present in
the received Binding Update message, but if the protocol
configuration variable
EnableOverlappingIPv4SupportWithRealmUniqueness is set to a value
of (1), and the value of the configuration variable
EnableOverlappingIPv4SupportWithAPNUniqueness is set to value of
(0), the home agent MUST reject the request and send a Binding
Acknowledgement message with Status field set to
MISSING_MN_IDENTIFIER_OPTION (160) [RFC5213].
o If the Mobile Node Identifier option [RFC4283] is present in the
received Binding Update message, but if the protocol configuration
variable EnableOverlappingIPv4SupportWithRealmUniqueness is set to
value of (1), the home agent MUST assign a private IPv4 address
from the overlapping address space from the realm associated with
the mobile node identifier.
Gundavelli, et al. Expires April 24, 2012 [Page 7]
Internet-Draft Overlapping IPv4 Address Support October 2011
o If the protocol configuration variable
EnableOverlappingIPv4Support is set to a value of (1), the home
agent MUST assign a private IPv4 address from the configured
overlapping address space. This configured overlapping address
space is not associated with any realm.
o When the home agent assigns an IPv4 private address from an
overlapping address space, the home agent MUST NOT set up an IPv4
host route over the tunnel to the mobile node, as that IPv4
address is not uniquely assigned to a single mobile node. The
home agent MUST make the forwarding decision based on the context
identifier that is associated with the received packet and the
context identifier in the Binding Cache entry.
o In deployments where the home agent is supporting hosted home
agent service model, the context identifier field of the Binding
Cache entry MUST be set to the identifier of the tunnel
established between the home agent and the enterprise gateway.
Any IPv4 packets recieved from the mobile node over the DSMIPv6
tunnel, after removing the outer header, MUST be forwarded to the
enterprise to which the mobile node belongs. The home agent MUST
use the context identifier field of the mobile node Binding Cache
entry for performing the correlation. Similarly, any IPv4 packets
received for the mobile node from the enterprise gateway, MUST be
tunneled to the mobile node.
o In deployments related to supporting Per-Interface Binding
Support, where the home agent is collocated with the CGN, the NAT
binding entries created for that mobile node for any IPv4 flows
MUST be associated with the tunnel identifier established between
the home agent and the mobile node. Considerations from
[I-D.draft-arkko-dual-stack-extra-lite] MUST be applied for making
IPv4 packet forwarding decisions.
o In deployments related to supporting Gateway Initiated Dual-stack
lite, considerations from
[I-D.draft-softwire-gateway-init-ds-lite] MUST be applied with
respect to IPv4 packet forwarding decisions and on the use of the
context identifier.
4.2. Mobile Node Considerations
This specification does not introduce any new considerations for the
mobile node implementation. The IPv4 private address assigned from
an overlapping address space, when used as the source address in any
IP sessions will get NAT translated at the CGN and is not exposed to
the session peers, or any other network elements.
Gundavelli, et al. Expires April 24, 2012 [Page 8]
Internet-Draft Overlapping IPv4 Address Support October 2011
5. Protocol Configuration Variables
A home agent when supporting this specification MUST allow the
following variables to be configured by the system management. The
configured values for these protocol variables MUST survive server
reboots and service restarts.
EnableOverlappingIPv4SupportWithRealmUniqueness
This flag indicates whether or not the home agent should be
allowed to assign overlapping IPv4 addresses to mobile nodes.
However, the assigned addresses MUST be unique within a realm
scope (Ex: @cisco.com). The default value for this flag is set to
(0), indicating this feature is not enabled.
The value of the flag MUST be set to (0), when the value of any of
the flags, EnableOverlappingIPv4Support or
EnableOverlappingIPv4SupportWithAPNUniqueness is set to (1).
EnableOverlappingIPv4SupportWithAPNUniqueness
This flag indicates whether or not the home agent should be
allowed to assign overlapping IPv4 addresses to mobile nodes.
However, the assigned addresses MUST be unique within the 3GPP APN
scope (Ex: @internetsvcs.cisco.com). The default value for this
flag is set to (0), indicating that this feature is not enabled.
The value of the flag MUST be set to (0), when the value of any of
the flags, EnableOverlappingIPv4Support or
EnableOverlappingIPv4SupportWithRealmUniqueness is set to (1).
EnableOverlappingIPv4Support
This flag indicates whether or not the home agent should be
allowed to assign overlapping IPv4 addresses to mobile nodes. The
assigned addresses MAY be overlapping within a realm. The default
value for this flag is set to (0), indicating that this feature is
not enabled.
The value of the flag MUST be set to (0), when the value of any of
the flags, EnableOverlappingIPv4SupportWithRealmUniqueness, or
EnableOverlappingIPv4SupportWithRealmUniqueness is set to (1).
Gundavelli, et al. Expires April 24, 2012 [Page 9]
Internet-Draft Overlapping IPv4 Address Support October 2011
6. IANA Considerations
This specification does not require any IANA actions.
Gundavelli, et al. Expires April 24, 2012 [Page 10]
Internet-Draft Overlapping IPv4 Address Support October 2011
7. Security Considerations
This document specifies extensions to Dual-stack Mobile IPv6 for
supporting overlapping private IPv4 address assignment support.
These protocol extensions do not introduce any new security
vulnerabilities for the following reasons:
Any IPv4 packets sent (or received) by a mobile node using an IPv4
address from an overlapping IPv4 private address space, or from a
non-overlapping address space are tunneled between the mobile node
and the home agent. These addresses are hidden from the routing
topology and from on-path network devices and hence will not
introduce any new security vulnerabilities.
Gundavelli, et al. Expires April 24, 2012 [Page 11]
Internet-Draft Overlapping IPv4 Address Support October 2011
8. Acknowledgements
The authors would like to acknowledge number of folks for all the
discussions related to hosted home agent deployment models for
enterprises.
The authors would also like to acknowledge all the discussions
related to solutions for IPv4 address exhaust problem in the 3GPP-
IETF IPv6 Migration Workshops held in Shanghai and in San Francisco.
Additionally, the authors would like to thank Vojislav Vucetic, Frank
Brockners, Kent Leung, Flemming Andreasen and Eric Voit for the
general discussions related to IPv6 transitioning solutions.
Gundavelli, et al. Expires April 24, 2012 [Page 12]
Internet-Draft Overlapping IPv4 Address Support October 2011
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
9.2. Informative References
[I-D.draft-arkko-dual-stack-extra-lite]
Arkko, J. and L. Eggert, "Scalable Operation of Address
Translators with Per-Interface Bindings, draft (work in
progress)", February 2011.
[I-D.draft-softwire-gateway-init-ds-lite]
Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
"Gateway Initiated Dual-Stack Lite Deployment,
draft-ietf-softwire-gateway-init-ds-lite (work in
progress)", October 2011.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Gundavelli, et al. Expires April 24, 2012 [Page 13]
Internet-Draft Overlapping IPv4 Address Support October 2011
Authors' Addresses
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Julien Laganier
Qualcomm
5775 Morehouse Drive
San Diego, CA 92121
USA
Email: julienl@qualcomm.com
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama, 356-8502
JP
Email: yokota@kddilabs.jp
Carl Williams
San Jose, CA
USA
Email: carlw@mcsr-labs.org
Gundavelli, et al. Expires April 24, 2012 [Page 14]
