Network Working Group W. Dec
Internet-Draft R. Asati
Intended status: Informational Cisco
Expires: April 16, 2012 C. Congxiao
CERNET Center/Tsinghua
University
H. Deng
China Mobile
M. Boucadair
France Telecom
October 14, 2011
Stateless 4Via6 Address Sharing
draft-dec-stateless-4v6-04
Abstract
This document presents an overview of the characteristics of
stateless 4V6 solutions, alongside a assessment of the issues
attributes. The impact of translated or mapped tunnel transport
modes is also presented in the broader context of other industry
standard reference architectures and existing deployments.
Requirements Language
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].
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 16, 2012.
Copyright Notice
Dec, et al. Expires April 16, 2012 [Page 1]
Internet-Draft stateless 4V6 October 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Stateless 4V6 Technical and Architectual Overview . . . . . . 5
3.1. IPv4 address and algorithmic port indexing . . . . . . . . 7
3.2. 4V6 CE IPv6 Address and domain info . . . . . . . . . . . 7
3.3. IPv6 Adaptation Function . . . . . . . . . . . . . . . . . 8
3.3.1. 4V6 Stateless Tunneling Mode . . . . . . . . . . . . . 8
3.3.2. 4V6 Stateless Translation mode . . . . . . . . . . . . 9
4. Comparison of 4V6 transport modes . . . . . . . . . . . . . . 9
4.1. General Characteristics of 4V6 modes . . . . . . . . . . . 9
4.2. Mobile SP Architecture and 4V6 Applicability . . . . . . . 12
4.2.1. 3GPP overview . . . . . . . . . . . . . . . . . . . . 13
4.2.2. 3GPP and 4V6 modes . . . . . . . . . . . . . . . . . . 15
4.3. Cable SP Architectures & 4V6 Applicability . . . . . . . . 18
4.3.1. PacketCable Introduction . . . . . . . . . . . . . . . 18
4.3.2. PacketCable Construct - Classifier . . . . . . . . . . 20
4.3.3. 4V6 Modes Impact on PacketCable . . . . . . . . . . . 20
5. Overview of potential issues and discussion . . . . . . . . . 21
5.1. Notion of Unicast Address . . . . . . . . . . . . . . . . 21
5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Implementation on hosts . . . . . . . . . . . . . . . . . 22
5.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 23
5.3. 4V6 address and impact on other IPv6 hosts . . . . . . . . 23
5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 23
5.4. Impact on 4V6 CE based applications . . . . . . . . . . . 24
5.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 24
5.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 24
5.5. 4V6 interface . . . . . . . . . . . . . . . . . . . . . . 24
5.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 24
Dec, et al. Expires April 16, 2012 [Page 2]
Internet-Draft stateless 4V6 October 2011
5.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 24
5.6. Non TCP/UDP port based IP protocols - ICMP) . . . . . . . 25
5.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 25
5.6.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 25
5.7. Provisioning and Operational Systems . . . . . . . . . . . 25
5.7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 25
5.7.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 25
5.8. Training & Education . . . . . . . . . . . . . . . . . . . 27
5.8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 27
5.8.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 27
5.9. Security and Port Randomization . . . . . . . . . . . . . 28
5.9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 28
5.9.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 28
5.10. Unknown Failure Modes . . . . . . . . . . . . . . . . . . 28
5.10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 28
5.10.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 28
5.11. Possible Impact on NAT66 use & design . . . . . . . . . . 29
5.11.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 29
5.11.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 29
5.12. Port statistical multiplexing and monetization of port
space . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 29
5.12.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 29
5.13. Readdressing . . . . . . . . . . . . . . . . . . . . . . . 30
5.13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 30
5.13.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 30
5.14. Ambiguity about communication between devices sharing
an IP address. . . . . . . . . . . . . . . . . . . . . . . 31
5.14.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 31
5.14.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 31
5.15. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.15.1. Abuse Claims . . . . . . . . . . . . . . . . . . . . . 32
5.15.2. Fragmentation and Traffic Asymmetry . . . . . . . . . 32
5.15.3. Multicast Services . . . . . . . . . . . . . . . . . . 33
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. Contributors and Acknowledgements . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Dec, et al. Expires April 16, 2012 [Page 3]
Internet-Draft stateless 4V6 October 2011
1. Introduction
As network service providers move towards deploying IPv6 and IPv4
dual stack networks, and further on towards IPv6 only networks, a
problem arises in terms of supporting residual IPv4 services, over an
infrastructure geared for IPv6-only operations, and doing so in the
context of IPv4 address depletion. This class of problem is referred
to by the draft as the 4via6 problem, for which a stateless solution
is desired driven by motivation as documented in
[I-D.operators-softwire-stateless-4v6-motivation]. Solutions such as
a 4rd [I-D.despres-softwire-4rd],
[I-D.murakami-softwire-4v6-translation], and
[I-D.xli-behave-divi-pd], as well as dIVI [I-D.xli-behave-divi] offer
such stateless solutions, by using fully distributed NAPT44
functionality located on end user CPEs, which allows the network
operators' core to remain effectively stateless in terms of NAT44.
The solutions, collectively called Stateless4V6, rely on the same
IPv4 address being used by multiple CPEs, each with a different TCP/
UDP port range, and are derived from the Address+Port (A+P) solution
space [I-D.ymbk-aplusp]. Differences between the solutions come down
to the mode of transport (translation or mapped tunneling), and the
mapping algorithm used. This document looks at the issues that have
been claimed as applying to A+P technology, in the specific context
of the referenced solutions, and also analyzes the two modes of
transport.
2. Terminology
Stateless4V6 domain: A domain is composed out of an arbitrary number
of 4V6 CE and Gateway nodes that share a mapping relationship
between an operator assigned IPv6 prefix and one or more IPv4
subnets along with all the applicable TCP/UDP ports, all mapped
into the IPv6 address space. An 4V6 system can have multiple
domains.
Stateless4V6 CE: A CPE node that implements 4V6 functionality
including NAPT44 which is provisioned by means of 4V6. The device
interfaces to the SP network using native IPv6 and a IPv4-IPv6
adaptation service.
Stateless4V6 Gateway A Service Provider node that implements the
stateless 46 adaptation functionality for interfacing between the
SP's IPv6 domain and an IPv4 domain in delivering end user IPv4
connectivity beyond the domain.
Dec, et al. Expires April 16, 2012 [Page 4]
Internet-Draft stateless 4V6 October 2011
IPv4 Address sharing The notion of attributing the same IPv4 address
by multiple CEs in an 4V6 domain.
Port-set: A set composed of unique TCP/UDP ports (ranges) associated
to a IPv4 address. A single 4V6 CE is expected to have a single
port-set for each IPv4 address.
Port-set-id: A numeric identifier of a given port set that is unique
in a given 4V6 domain. A port-set-id is used to algorithmically
determine the port-set members. The port-set-id is conveyed to
CEs as part the CE's IPv6 addressing information, ie it is part of
IPv6 subnet or address of a given CE, and its format places no
restriction on the use of SLAAC or DHCP addressing.
CE-index: A numeric value, composed of a full or partial IPv4
address and optionally a port-set-id, which uniquely identifies a
given CE in an 4V6 domain.
3. Stateless 4V6 Technical and Architectual Overview
This section presents the architectural and technical overview of a
stateless 46 solution, and evidenced in whole or in part by various
stateless 4via6 solution proposals such as 4rd, dIVI. Figure 1
depicts the overall architecture with two IPv4 user networks
connected via 4via6 CPEs that share an IPv4 address. The goal of the
system is to allow IPv4 user connectivity to the Public IPv4 network,
across an operator's IPv6 network.
A key characteristic of the system, and a major differentiator with
respect to previous solutions, is that translation state is only
(ever) present on the CE, with the rest of the system performing
stateless transport. This stateless transport applies to both the
mapped-tunnel and translated modes, as described in the dedicated
sections.
Dec, et al. Expires April 16, 2012 [Page 5]
Internet-Draft stateless 4V6 October 2011
User 1
Private IPv4
| Network
|
O--+---------------O
| | 4V6 CE |
| +-----+--------+ |
| NAPT44| IPv6 | `-.
| +-----+ Adptn | | -._ ,-------. ------.
| +--------+ | ,-' `-. ,-' `-.
O------------------O / Routed \ O---------O / Public \
/ IPv6 \ |Stateless|/ IPv4 \
( Network --+ 6V4 +- Network )
\ / | Gateway |\ /
O------------------O \ / O---------O \ /
| 4V6 CE | ;". ,-' `-. ,-'
| +-----+--------+ | ," `-------' ------'
| NAPT44| IPv6 | ,"
| +-----+ Adptn | |
| | +--------+ |
O---.--------------O
|
User 2
Private IPv4
Network
Figure 1 - Generalized Stateless 4V6 system
On IPv4 network user side, the routed IPv6 service provider network
is demarcated with a 4V6 CE. The CPE externally has only a native
IPv6 interface to the SP network, and a native IPv4 interface towards
the end user network.
The IPv4 Internet is demarcated from the operator IPv6 network with
one or more operator managed stateless 6V4 gateways that contain an
IPv6 adaptation function (not detailed in the diagram) matching the
one in the CE. Note: The stateless 6v4 gateway can be integrated
into any existing network element (eg a core router, or an IP Edge).
Internally, the 4V6 CE is modelled as having a port restricted NAPT44
function coupled with a stateless IPv6 adaptation function that is
able to ferry the end-user's IPv4 traffic across the IPv6 network,
besides deriving 4V6 provisioning info from it. The NAPT44 function
derives its IPv4 address, which may be shared with that of other
users, and its unique Layer 4 (TCP/UDP) port range from the IPv6
address/prefix by means of an 4V6 algorithm and a port indexing
schema. Any IPv4 ALG functionality that the CPE may support, remain
unaffected. The CPE is expected to act as a DNS resolver proxy,
using native DNS over IPv6 to the SP network.
Dec, et al. Expires April 16, 2012 [Page 6]
Internet-Draft stateless 4V6 October 2011
Two forms of the IPv6 adapatation function are: i) 4v6 stateless
tunneling ii) 4v6 stateless translation, each described in further in
this document.
The service provider is assumed to be operating all the necessary
provisioning and accounting infrastructure to support a regular IPv6
deployment. Similarly, the network operator is assumed to have the
ability to assign an IPv6 prefix or IPv6 address to a CPE, and log
such an address assignment.
End user host's DO NOT implement any of the 4V6, or other address
sharing technologies, nor are they addressed directly with a shared
IPv4 address. End user IPv4 hosts connected to the CPE receive
unique private addresses assigned by the CPE, and it is the CPE that
is directly addressed by the shared IPv4 address.
Although tangential to the discussion of stateless 4V6, it is useful
to note that the CPE is expected to have a native IPv6 interface to
the end user network, with any of the end user IPv6 hosts (single or
dual stack) receiving IPv6 addresses from an IPv6 delegated prefix
issued to the CPE.
3.1. IPv4 address and algorithmic port indexing
At the heart of the 4V6 solution, irrespective of mode of transport,
lies the algorithm described in the specific solution drafts that
allows the mapping of a shared IPv4 address and a TCP/UDP given port-
set to a single IPv6 prefix or address. Notably, the 4V6 system
allows both the shared IPv4 address use, as well as full non-shared
IPv4 address use, all subject to the 4V6 domain configuration.
The S46 domain information required to compute the IPv4 address and
correct port set is retrieved from the 4V6 prefix advertised to the
CE, and pre-configured or statelessly acquired domain information.
3.2. 4V6 CE IPv6 Address and domain info
As presented in Section 2, IPv6 address of an 4V6 CE is composed out
of the SP advertised IPv6 4V6 prefix, containing the CE-index, and an
algorithmically computed appendix to complete the 128-bit address.
This IPv6 address is *in addition* to any other IPv6 interface
address that the CE configures or is configured with, including a
SLAAC address from the 4V6 prefix or any IPv6 address source. One
characteristics of the resulting IPv6 prefix or address is that it is
for all intents and purposes a regular IPv6 prefix address that can
be assigned to any regular IPv6 host.
The IPv6 4V6 interface is reserved for the 4V6 application and the
Dec, et al. Expires April 16, 2012 [Page 7]
Internet-Draft stateless 4V6 October 2011
4V6 IPv6 adaptation function will exclusively use this IPv6 address.
This is because the 4V6 system supports stateless communication
between the 4V6 CE and the 4V6 gateway only by means of packets sent
to/from this address.
3.3. IPv6 Adaptation Function
The IPv6 adaptation function plays a key role in the 4V6 system, in
statelessly allowing the IPv4 user payload to be transported across
an IPv6 (only) network. Two modes of such a function are currently
proposed and presented in the following subsections
3.3.1. 4V6 Stateless Tunneling Mode
This type of IPv6 adaptation function is adopted and described in
[I-D.despres-softwire-4rd].
The 4V6 gateway operates in the IPv4->IPv6 direction by mapping all
or part of the IPv4 destination address and the port Index derived
from the UDP/TCP payload into an IPv6 CE destination address. The
resulting packet is sent using IPv4inIPv6 encapsulation to the CE,
sourced from the 4V6's gateway IPv6 address, where the original IPv4
packet is extracted and passed to the stateful NAPT44 function.
The 4V6 CE operates in the IPv4->IPv6 direction, for traffic bound to
the IPv4 internet, by encapsulating the IPv4 packet in an IPv6 header
using IPv4inIPv6 encapsulation, and sending the resulting packet to
the (well known) unicast address of the 4V6 gateway. There the IPv4
packet is extracted and forwarded.
The the original IPv4 packet addressing information is only partially
visible on the IPv6 data plane, and the original Layer 4 information
is only visible as part of the encapsulated IPv4 payload packet.
The figure below illustrates the CE model of a 4v6 Mapped Tunnel
mode.
+......................+
: :
: stateful stateless :
[IPv4-LAN]-----:-[NAPT44]---[v4-v6]---:----<IPv6 Network>
: [ tunn] :
: :
: :
+......................+
Figure 2 - 4v6 CE model with Tunnel mode
Dec, et al. Expires April 16, 2012 [Page 8]
Internet-Draft stateless 4V6 October 2011
3.3.2. 4V6 Stateless Translation mode
This type of IPv6 adaptation function is adopted and described in
[I-D.murakami-softwire-4v6-translation], I-D.xli-behave-divi-pd,
and[I-D.xli-behave-divi] The 4V6 translation mode transport operates
by means of stateless NAT46 [RFC6145] extended to map the the TCP/UDP
port index algorithmically derived from received IPv4 packets into an
IPv6 address suffix, in the IPv6 header, besides the full IPv4 mapped
representation of the original IPv4 address information. The
resulting packet is then sent across the IPv6 domain as an IPv6
packet - this IPv6 packet, besides mapping the original original IPv4
address information into a determinate IPv6 format, also places the
Layer 4 and packet content directly after the IPv6 header, as any
regular IPv6 with TCP/UDP packet. This IPv6 packet is thus capable
of being processed by regular IPv6 network elements or servers in the
IPv6 domain. At either end of the IPv6 domain, the IPv4 packet
header is statelessly recreated, by the 4v6 CE or gateway, again
using exactly the same NAT64 process as in [RFC6145].
The figure below illustrates the IPv6 4v6 Stateless Translation model
of a 4v6 CE.
+......................+
: :
: stateful stateless :
[IPv4-LAN]-----:-[NAPT44]---[NAT46]---:----<IPv6 Network>
: :
: :
: :
+......................+
Figure 3 - 4v6 CE model with stateless NAT64
4. Comparison of 4V6 transport modes
This section presents the an overview of the similarities and
differences between an IPv4-IPv6 translation based 4V6 transport mode
and one that utilizes IPv4-in-IPv6 tunnelling. The comparison takes
into consideration a wider deployment view composed of functionality
that is known to be in common use today.
4.1. General Characteristics of 4V6 modes
The following table presents a comparison of the 4V6 transport modes,
in terms of the base technology, and constrains, including also IPv4.
Dec, et al. Expires April 16, 2012 [Page 9]
Internet-Draft stateless 4V6 October 2011
+------------------------+--------------------+---------------------+
| Item | 4V6 Translation | 4V6 Tunnel Mode |
| | mode | |
+------------------------+--------------------+---------------------+
| Base Technology | Port restricted | Port restricted |
| | NAPT44 with | NAPT44 with IPv4 in |
| | modified stateless | IPv6 mapped |
| | NAT64 on CPE and | tunneling on CPE |
| | Gateway | and Gateway |
| ------------------- | ------------------ | ------------------- |
| Location of stateful | CPE | CPE |
| NAPT44 function | | |
| ------------------- | ------------------ | ------------------- |
| IPv4 Forwarding | L3 + L4 lookup | L3 + L4 lookup |
| paradigm | | |
| ------------------- | ------------------ | ------------------- |
| IPv6 Addressing | CE uses 4V6 | CE uses 4V6 suffix. |
| Constraints | suffix. | |
| ------------------- | ------------------ | ------------------- |
| Type of IPv6 | ICMPv6 (SLAAC), | ICMPv6 (SLAAC), |
| prefix/address | DHCPv6 (both IA_NA | DHCPv6 (both IA_NA |
| announcement method | and IA_PD) | and IA_PD) |
| supported | | |
| ------------------ | ------------------ | ------------------ |
| Can the 4V6 IPv6 | Yes | Yes |
| prefix be used by non | | |
| 4V6 devices? | | |
| ------------------- | ------------------ | ------------------- |
| IPv4 addressing | Fixed sharing | Fixed sharing ratio |
| constraints | ratio per IPv4 | per IPv4 address. |
| | address. | |
| ------------------ | ------------------ | ------------------ |
| TCP/UDP Port range | Ports are | Ports are |
| constraint | statically | statically |
| | allocated | allocated |
| ------------------ | ------------------ | ------------------ |
| Requires ALG64 or | No | No |
| DNS64 | | |
| ------------------ | ------------------ | ------------------ |
| Requires IPv6 DNS on | Recommended | Recommended |
| CPE | | |
| ------------------ | ------------------ | ------------------ |
| 4V6 CE Parameter | ICMPv6, Stateless | ICMPv6, Stateless |
| provisioning methods | DHCPv6, TR69 | DHCPv6, TR69. |
| (assuming suitable | | |
| protocol extensions) | | |
| ------------------ | ------------------ | ------------------ |
Dec, et al. Expires April 16, 2012 [Page 10]
Internet-Draft stateless 4V6 October 2011
| IPv6 Domain Routing to | Regular closest IP | Regular closest IP |
| CE based on: | match to CE-IPv6 | match to CE-IPv6 |
| | subnet | subnet |
| ------------------ | ------------------ | ------------------ |
| IPv6 Domain Routing to | IPv6 4V6 domain | 4V6 Gateway |
| 4V6 Gateway based on | aggregate route | unicast/anycast |
| | | address |
| ------------------ | ------------------ | ------------------ |
| IPv4 Header Checksum | Yes | No |
| recalculation required | | |
| ------------------ | ------------------ | ------------------ |
| Supports non TCP/UDP | No* | No* |
| Protocols | | |
| ------------------ | ------------------ | ------------------ |
| ICMPv4 Limitations | No ICMPv4 from | No ICMPv4 from |
| | "outside the | "outside the |
| | domain". Internal | domain". |
| | ICMPv4-v6 | |
| | translation as per | |
| | [RFC6145] | |
| ------------------ | ------------------ | ------------------ |
| ICMPv5 identifier | Yes | Yes |
| NAT/Markup needed | | |
| ------------------ | ------------------ | ------------------ |
| Supports IPv4 | No | No |
| fragmentation (without | | |
| additional state) | | |
| ------------------ | ------------------ | ------------------ |
| Requires IPv6 PMTU | Yes | Yes |
| discovery/configuratio | | |
| n | | |
| ------------------ | ------------------ | ------------------ |
| Supports IPv4 Header | No - as per NAT64 | Yes (use of source |
| Options | [RFC6145] | route option is |
| | | constrained) |
| ------------------ | ------------------ | ------------------ |
| TCP/UDP Checksum | Yes - depending on | No |
| recalculation | suffix, as per | |
| | NAT64 [RFC6145] | |
| ------------------ | ------------------ | ------------------ |
| Supports UDP null | Yes/Configurable - | Yes |
| checksum | as per NAT64 | |
| | [RFC6145] | |
| ------------------ | ------------------ | ------------------ |
| Transparency to DF bit | Yes, configurable | Yes |
| | as per [RFC6145] | |
| ------------------ | ------------------ | ------------------ |
Dec, et al. Expires April 16, 2012 [Page 11]
Internet-Draft stateless 4V6 October 2011
| Supports IPv4 | Partial (no | Partial (no |
| Fragmentation | fragments from | fragments from |
| | outside the | outside the domain) |
| | domain) | |
| ------------------ | ------------------ | ------------------ |
| Transparency to IPv4 | Yes, configurable | Yes |
| TOS | as per [RFC6145] | |
| ------------------ | ------------------ | ------------------ |
| Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% |
| to original average | | |
| payload on IPv6 of a) | | |
| ~550 bytes b) 1400 | | |
| bytes). | | |
| ------------------ | ------------------ | ------------------ |
| Supports non-shared | Yes | Yes |
| IPv4 usage (ie whole | | |
| IPv4 address | | |
| assignment to a single | | |
| device) | | |
| ------------------ | ------------------ | ------------------ |
| Can support IPv4 to | Yes - As per | No |
| IPv6 host | [RFC6145] | |
| communication (for | stateless NAT64 | |
| traffic not requiring | specification | |
| ALGs) | | |
| ------------------ | ------------------ | ------------------ |
| Changes to network | Yes - Mapping IPv4 | Yes - Enabling |
| element provisioning | to IPv6 addresses | IPv4inIPv6 |
| tool(s)** | | functionality |
+------------------------+--------------------+---------------------+
* Without specific ALGs. Non UDP/TCP protocols, like ICMP, can be
supported with specific ALGs.
**Network (feature) provisioning tools/applications need to be 4V6
aware. With the translation technique, the tool needs to enable the
operator to map IPv4 addresses to IPv6 addresses as disctated by the
4V6 domain. With the tunneling technique, the tool needs to allow
the operator to enable IPv4 (inIPv6) functionality and modify its
characterstics.
4.2. Mobile SP Architecture and 4V6 Applicability
This section presents the applicability and comparison of the 4V6
modes to current 3GPP architectures used by Mobile SP for delivering
all sorts of mobile services.
Dec, et al. Expires April 16, 2012 [Page 12]
Internet-Draft stateless 4V6 October 2011
4.2.1. 3GPP overview
The 3rd Generation Partnership Project (3GPP) is a collaboration
between groups of telecommunications associations, whose scope is to
develop a globally applicable mobile phone systems and architectures
based on service requirements. 3GPP standards are structured as
Releases, each of which incorporates numerous individual standard
documents. Currently, 3GPP Release 7 is the latest release in common
practical deployment, with Release 8 being readied for deployment.
Releases 9 and 10 are finalized, and work is underway on Release 11.
One of the major service requirement drivers of recent and ongoing
3GPP releases is the realization of services that deliver specific
QoS, or user charging goals, all based on a policy system (eg tiered
data rate or volume plans). Technically this translates to the
Policy and Charging Control (PCC) framework, which in turn attributes
specific functionality to nodes in the 3GPP architecture, such as the
PDN-Gw and the PCRF. This functionality comprises both data-plane
features (eg IP flow classification) as well as the interfaces/
protocols between nodes (eg Diameter, and its specific 3GPP
applications).
The 3GPP specifications allow both IPv4 and IPv6 traffic to be
handled, and subject to operator defined handling and charging
polices by means of applying suitable user traffic filters. Such
filters are currently defined to be either IPv4 or IPv6, are
applicable to user plane traffic, and are used in a variety of
critical roles including the signalling of PDP contexts/EPC Bearers,
as well as PCC signalling and interaction with applications.
The following table illustrates the impact of the 4V6 translation and
tunnel transport modes respectively on the 3GPP architecture
including PCC interfaces. In assessing the impact of these 4V6
transport modes a number of additional assumptions are taken:
o The 3GPP system supports native IPv6 user traffic, as say per
either of the E-UTRAN Release 8 or 9 specifications, using the
relevant EPS bearer or PDP functionality.
o The 4V6 gateway functionality is not part of the 3GPP core
architecture (given that currently it is not scoped by a 3GPP
Release). Instead, the 4V6 gateway is taken to be a stand alone
component in the 3GPP network operator's core reachable via the
SGi interface.
The above system, in the context of 3GPPs E-UTRAN architecture as
defined in [E-UTRAN] is shown in Figure 2
Dec, et al. Expires April 16, 2012 [Page 13]
Internet-Draft stateless 4V6 October 2011
+----------+
| | ,---.
| AF | / \
| | / IPv4 \
+----+-----+ ( Internet)
| \ /
Rx | \ /
,---. | `-+-'
/ \ +----+-----+ |
/ \ | | +----+-----+
; User : +-------+ | PCRF | | |
| Home | | | | | | S64 |
: Network ; | MME | +----+-----+ | Gateway |
\ / | | Gx | +----+-----+
\ / +-+----++ | |
`-+-' S1-MME / \ S11 +----+-----+ ,--+--.
| ,-/ `. | | ,' `.
+---+---+ ,' `.S1-u +--+----+ | | / IP \
| UE +---- -----+ +------+ PDN-Gw +---- Transport )
| w/ 4V6| |E-UTRAN| | S-Gw | | | \ /
| CE | : ; | | S5 | | SGi `. ,'
+-------+ `. ,' +-------+ | | '-----'
LTE-Uu `-' +----------+
Figure 2 - 3GPP Architecture with 4V6
The main 3GPP system components, and terms are summarized as follows
(the reader is referred to [E-UTRAN for a more detailed definition]:
UE The User Equipment, typically a phone or a 3G/4G capable Home
Router (shown to incorporate 4V6 functionality)
E-UTRAN Evolved Universal Terrestrial Radio Access Network. The
Radio Access network, composed on E-NodeB elements.
MME Mobility Management Entity. Responsible for user
authentication, PDN/SGw selection. Does not interact with the
user data plane
S-Gw Serving Gateway (function). Responsible for handling local
mobility, (some) traffic accounting, traffic forwarding, bearer
establishment.
PDN-Gw Packet Data Network Gateway (function). Responsible for per
user IP traffic handling, incl. address assignment, filtering,
QoS, accounting.
Dec, et al. Expires April 16, 2012 [Page 14]
Internet-Draft stateless 4V6 October 2011
PCRF Policy And Charging Rules Function. Responsible for
authorizing and applying policy rules, as well as binding them to
user bearers.
Bearer The bearer represents a virtual connection, typically that
between a UE and a PDN-Gw. The bearer is specified as an IP
Fliter (in terms of IP address, port numbers) and is the object of
policy rules. 3GPP, depending on Release and document, defines
many terms that are used to refer to the same notion: PDP context,
EPS Bearer.
AF Application Function. A functional element offering (higher
level) applications that require dynamic policy and/or charging
control over the user plane (bearer) behaviour. The AF can be
seen as bridging the gap between applications and how they affect
the IP data plane of a user.
S5 It provides user plane tunnelling and tunnel management between
SGW and PDN-GW, using GTP or PMIPv6 as the network based mobility
management protocol.
S1-u Provides user plane tunnelling and inter eNodeB path switching
during handover between eNodeB and SGW, using the GTP-U protocol
SGi It is the interface between the PDN-GW and the packet data
network. Packet data network may be an operator external public
or private packet data network or an intra operator packet data
network.
Gx Bearer and flow control interface between the user data-plane
element (PDN-Gw) and the Policy System. A Diameter based
interface with a suite of 3GPP applications
4.2.2. 3GPP and 4V6 modes
4V6 translated traffic appears for all intents and purposes as
regular IPv6-user traffic to the 3GPP system and packet processing
functions (eg the PDN-Gw). Hence, and based on the stated
assumptions, any such 4V6 traffic can be handled using existing
native IPv6 functionality defined by the core 3GPP specifications.
In contrast, 4V6 tunneled traffic requires additional data plane
processing to get to the "real" user IPv4 payload and apply the
desired functions. Such additional processing is currently not part
of the functionality covered by the 3GPP specifications. In view of
this, and solely in relation to the 4V6 tunnel transport mode, two
alternative hypotheses need to be placed in order to complete the
comparison
Dec, et al. Expires April 16, 2012 [Page 15]
Internet-Draft stateless 4V6 October 2011
i) that such IPv4 in IPv6 processing functionality will be supported
as part of the existing EPS bearer functionality defined in E-UTRAN,
perhaps as a dedicated EPS bearer (ie an additional virtual interface
per subscriber). Or, that;
ii) a new 46 EPS bearer type (ie interface type) identification and
signalling will be defined by the 3GPP architecture, which formalizes
the v4inv6 relationship between the IPv4-user payload and the v6-user
layers.
An apparent benefit of approach (ii) would be in allowing the system
to clearly distinguish and expose to other systems v4-user traffic
versus v6-user traffic, which is composed of v4inv6 and regular v6
traffic that a UE may generate. The former approach (i) is more
convoluted given the ambiguity in distinguishing, and representing
such a combination of v6-user and v6-user-bearer and v4-user traffic,
all while keeping coherence in terms of the policy system. These two
options are designated with ** in the table below.
+--------------------+----------------+-----------------------------+
| Item | 4V6 | 4V6 Mapped Tunnel Mode |
| | Translation | |
| | Mode | |
+--------------------+----------------+-----------------------------+
| User Data Plane at | IPv6 over | IPv4 over IPv6 over GTP-U |
| the PDN-Gw (as per | GTP-U over UDP | over UDP over IP |
| section 5.1.2 in | over IP | |
| [EUTRAN]) | | |
| ------------------ | ----------- | ------------------ |
| Gx (Diameter) | No discernible | Impacted: no way to express |
| | impact | v4 over v6 in TFT Filter |
| | | and Flow Descriptors |
| ------------------ | ----------- | ------------------ |
| Rx (Diameter) | No discernible | Impacted: no way to express |
| | impact | v4 over v6 in |
| | | Media-Component-Description |
| | | and, Flow-Description-AVP |
| ------------------ | ----------- | ------------------ |
| S5 (GTP) | No impact | Impacted with new PDP/EPS |
| | | Bearer type* |
| ------------------ | ----------- | ------------------ |
| New 46 Bearer | Not required | Possibly required** |
| definition | | |
| ------------------ | ----------- | ------------------ |
Dec, et al. Expires April 16, 2012 [Page 16]
Internet-Draft stateless 4V6 October 2011
| Secondary | Not required | Possibly required** |
| interface | | |
| (dedicated bearer | | |
| or secondary PDP) | | |
| for 46 traffic | | |
| ------------------ | ----------- | ------------------ |
| PDN-Gw | No impact | New TFT capability, IP Gate |
| | | functionality, changes to |
| | | Gx, and likely changes to |
| | | S5/S7 related to signalling |
| | | the new bearer |
| ------------------ | ----------- | ------------------ |
| SGw | No Impact | No discernible impact |
| ------------------ | ----------- | ------------------ |
| PCRF | No impact for | Impacted for both IPv6 and |
| | IPv6. Feature | IPv4-only applications and |
| | to map | Gx applications utilizing |
| | IPv4-IPv6 | flow control/charging |
| | addresses | |
| | needed only in | |
| | case of | |
| | IPv4-only | |
| | applications. | |
| ------------------ | ----------- | ------------------ |
| AF Application | No discernible | Flow based application |
| Function | impact | control impacted |
| ------------------ | ----------- | ------------------ |
| UE | 4V6 | 4V6 application |
| | application | |
| ------------------ | ----------- | ------------------ |
| LTE-Uu | No discernible | Likely changes required to |
| | impact | support signalling of EPS |
| | | bearer or PDP type |
| ------------------ | ----------- | ------------------ |
| Lawful Intercept | No discernible | New rules for tunnel |
| | impact | support |
+--------------------+----------------+-----------------------------+
*A new PDP Type or EPS bearer signalling has a broader 3GPP system
wide impact not fully covered here.
As the table illustrates, the 4V6 tunnel transport model appears to
affect a significant number of 3GPP elements, when the intent if
realize a full suite of services. This observation appears to apply
to any other carrier inserted tunneling technology (eg DS-lite).
Hence, a substantial investment in 3GPP standard terms and in the
evolution of deployed systems appears to be required.
Dec, et al. Expires April 16, 2012 [Page 17]
Internet-Draft stateless 4V6 October 2011
In contrast the 4V6 translation mode bears none to no discernible
impact on existing 3GPP Release 8/9 specifications and their
deployments, while allowing the operator to realize the full set of
services on 4V6, alongside any native IPv6 traffic, allowed for by
these architecture. Hence, little beyond the addition of 4V6
components operating using translation mode appears to be required.
4.3. Cable SP Architectures & 4V6 Applicability
Cable SPs (commonly referred to as Multi System Operators (MSOs))
usually deliver video, data, and voice service over the cable and
fiber access to residential and commercial customers. Many MSOs
offer SLAs with various services by exploiting QoS not only in their
IP/MPLS network, but also their access network.
The cable access network (now synonymous with Hybrid Fiber Coax
(HFC)) is commonly enabled with Data Over Cable Service Interface
Specifications (DOCSIS, a CableLabs standard) to facilitate the
implementation of packet based services. In this paradigm, the HFC/
DOCSIS access bandwidth is typically shared among a number of
customers, hence, ensuring optimal service quality & experience per
customer becomes extremely important for MSOs' success.
Cable SPs/MSOs ensure the optimal service quality of various advanced
& real-time multimedia services (such as IP telephony, multimedia
conferencing, interactive gaming etc.) by utilizing "PacketCable"
framework to enforce QoS on the HFC/DOCSIS access.
The next sub-section 4.3.1 provides a brief introduction to
PacketCable, section 4.3.2 explains a key PacketCable construct -
Classifier, and section 4.3.3 tabulates the impact of 4V6 modes to
PacketCable enabled DOCSIS/IP services.
4.3.1. PacketCable Introduction
PacketCable,a CableLabs standard, defines a framework for ensuring
the Quality of Service (QoS) on the HFC/DOCSIS Access. PacketCable
specifications (e.g. PacketCable 1.0, PacketCable Multi Media
[PCMM], PacketCable Dynamic QoS [PC-DQOS], PacketCable 2.0) specify
interoperable interface specifications for executing QoS, Admission
Control, Accounting, Policy, and Security functions on Cable Modem
(CM) and Cable Modem Termination System (CMTS), as/when needed. They
all require DOCSIS 1.1 or later versions.
The PacketCable framework is also critically important for MSOs to
comply with government regulations for things such as E911 when they
offer voice/telephony services, Lawful Intercept (LI) etc.
Dec, et al. Expires April 16, 2012 [Page 18]
Internet-Draft stateless 4V6 October 2011
The figure below illustrates one of PacketCable variants i.e. PCMM
[PCMM] architecture, as an example, that defines a set of IP-based
interfaces (referred to as pkt-mm-1 through 12) pertaining to core
QoS and policy management capabilities.
+------------+ +---------------+
| Application+-----------+ Application |
| Server | pkt-mm-11 | Manager |
+-------+----+ +-+--------+----+
,------| | | pkt-mm-3
/,-------------------------+ |
// +--+---+ +-------+
pkt-mm-12 // pkt-mm-7 | | |Record |
// |Policy+----------+Keeping|
// |Server| pkt-mm-4 |Server |
// +--+---+ ++------+
// | |
// | ,------------+
// pkt-mm-2| / pkt-mm-5
// ||
// || ,--+--.
// +---++--+ +-------+ +--++--+ ,' `. +--------+
Clients } | CPE | | Cable | pkt-mm-1 | | / \ | 4V6 |
In User }--+ Router+---+ Modem +----DOCSIS------+ CMTS +-----( IP )--+ Gateway|
Network } | w/ 4V6| | | | | \ Network / |Boundary|
+-------+ +-------+ +------+ `. ,' | Router |
'-----' +--+-----+
\~~~~~~~~~~~~~~~~~~~~~/ |
A typical Residential |
Gateway includes both ,-+--.
CPE & CM functions / \
/ IPv4/6 \
( Internet )
\ /
\ /
* PCMM spec marks these out-of-scope: `----'
mm-7, mm-8, mm-9, mm-10, mm-12
* PCMM spec does not define/describe
4V6 Gateway/Boundary Router, or Internet
Figure 3 - PacketCable Multimedia Architecture (with 4V6)
Dec, et al. Expires April 16, 2012 [Page 19]
Internet-Draft stateless 4V6 October 2011
4.3.2. PacketCable Construct - Classifier
PacketCable framework fundamentally relies on Cable Modem (CM) and
Cable Modem Termination System (CMTS) to first qualify and then
classify the appropriate IP traffic between them, for effective QoS
enforcement. The framework requires the usage of "Classifier" for
both qualification (in control plane) and classification (in data
plane).
Taking PCMM specification [PCMM] again as an example, PCMM mandates
the usage of classifier in the control plane (i.e. 'Upstream Packet
Classification Encoding' in pkt-mm-1 interface (DOCSIS) , whereas
'Multimedia Classifier Object' in pkt-mm-2 and pkt-mm-3 interfaces
(COPS)) for conveying the attributes of an IP flow belonging to an
application (telephony, say), and subsequently its usage in the data
plane i.e. filter matching on the IP packets' layer2/3/4 headers
prior to QoS treatment.
The PCMM specification mandates the 'classifier' to include Source
and Destination IP addresses, DSCP/TOS, IP Protocol, Source and
Destination ports for an IPv4 traffic flow received by the CMTS, and
similarly, Source and Destination IP addresses, TC, Next Header,
Source and Destination ports for an IPv6 traffic flow received by the
CMTS.
Similar to PCMM, PacketCable DQOS specification [PC-DQOS] also
mandates the usage of classifier in the control plane (DSx
messaging). In particular, PC-DQOS mandates the classifier
definition to have 'protocol' (or next header) in IP header to be 17
(=UDP) along with specific Source and Destination ports (and Source
and Destination IP addresses, optionally) so as to accommodate voice
RTPoUDPoIP traffic.
In summary, the CMTS (and CM) construct their data-plane filter based
on the 'classifier' information.
4.3.3. 4V6 Modes Impact on PacketCable
In 4V6 Tunnel mode, the 4V6 tunneled traffic requires additional data
plane processing to get to the "real" user IPv4 payload and apply the
desired functions. Such additional processing is currently not part
of the functionality covered by the PacketCable specifications, nor
part of compliant implementations.
In 4V6 Translation Mode, the 4V6 translated traffic appears for all
intents and purposes as regular IPv6-user traffic to the PacketCable
framework (both control plane and data plane). Hence, it is likely
that any such 4V6 traffic can be handled using native IPv6
Dec, et al. Expires April 16, 2012 [Page 20]
Internet-Draft stateless 4V6 October 2011
functionality e.g. classifier as defined by the PacketCable
specifications and supported by CMTS and CM.
Taking PCMM specification as an example, it is worth noting that PCMM
already allows for (and mandates) a minimum of four classifiers to be
included in Gate-set. Hence, a Policy Server can communicate (via
pkt-mm-2) both IPv4 and IPv6 classifier to the CMTS, which can use
IPv6 classifier for constructing its data-plane filters (for
DownStream processing), and convey IPv4 classifier to the CM via
DOCSIS messages (pkt-mm-1) for any Upstream Processing. So, the 4V6
Translation Mode would work out in current implementations/deployment
reasonably well.
Separately, it is likely that the CPE Router would be engaged in
serving IPv4 multicast content to IPv6 receivers (and vice versa) in
future, requiring 'translation' function.
In summary, while 4V6 Translation mode can work with the existing
PacketCable framework, 4V6 Tunnel mode can not.
5. Overview of potential issues and discussion
This section summarizes the issues attributed to an A+P, or port
restricted scheme, along with a discussion of applicability to the
assumed system and possible resolutions. The summary of issues stem
from [I-D.thaler-port-restricted-ip-issues] and associated
discussions.
5.1. Notion of Unicast Address
5.1.1. Overview
The issue, referred to as the "definition of a unicast address",
relates to the notion that in a shared IPv4 address system, multiple
hosts will be visible as having a single IPv4 address outside of the
system. This issue is a general characteristic of any NAPT44 based
solution [I-D.ietf-intarea-shared-addressing-issues], including DS-
Lite. However, a more specific aspect of this issue in the context
of an address sharing system is the possibility that a single host
having multiple interfaces will be assigned the same IPv4 address
(with different port ranges) on each of its interfaces. It may also
be that multiple hosts sharing an address find themselves on the same
Layer 2 segment. Either would impede hosts from working within the
notion of known host IP stack and protocol implementations.
Dec, et al. Expires April 16, 2012 [Page 21]
Internet-Draft stateless 4V6 October 2011
5.1.2. Discussion
A number of the characteristics of the 4via6 solution architecture
cause the issues not to be applicable, key of which is that there is
no expectation for any kind of end hosts to be part of the shared
IPv4 address system.
In the stateless 4via6 system, CPE nodes are assigned with a shared
IPv4 address+port range by means of the unique IPv6 address,
containing the embedded IPv4 address + port index, of that CPE node.
The CPE node is in addition enabled to be running the port restricted
NAPT44 function from the IPv6 derived address, a key characteristic
of the solution. On the IPv6 plane, the IPv6 address of the CPE is
practically indistinguishable from any "regular" IPv6 address, and in
fact any host that is not aware of it conveying an embedded IPv4
address would be able to use this just like any other regular IPv6
address, ie the 4via6 solution uses standard IPv6 addressing. In
terms of the IPv4 dimension, since the shared address and port index
are never used to address native IPv4 nodes or hosts, but instead
uniquely assigned to a single NAPT44 function that is part of the
CPEs, all legacy or other IPv4 hosts are not exposed to the presented
issues.
Going beyond the ascribed issue however, it appears desirable to have
the 4via6 CPEs that are to be part of the shared system to be able to
provide a hint to the network operator in terms of their special
capability. Such a hint can be a DHCPv6 Option Request Option, which
would be useful to allow the DHCPv6 sub-system to also inform the CPE
of any other stateless 4via6 system parameters. A largely similar
ORO option is currently being defined as part of
[I-D.ietf-softwire-ds-lite-tunnel-option]
Recommendation: Define a suitable DHCPv6 ORO for conveying the 4via6
capability of a CPE.
5.2. Implementation on hosts
5.2.1. Overview
The issue, as presented, relates to the need for modifications on end
hosts or devices to support a port constrained mechanism and the
overall impossibility of realizing such modifications. Furthermore,
host applications that attempt to bind to specific ports that are not
part of the allowed port range will fail to do so and may also
require modifications.
Dec, et al. Expires April 16, 2012 [Page 22]
Internet-Draft stateless 4V6 October 2011
5.2.2. Discussion
As presented in Section 3 the solution assumes the use of a dedicated
CPE implementing the 4via6 functionality within a port constrained
mode and NAPT44. Granted, CPE nodes will require to implement new
functionality such as the IPv6 adaptation function, that is likely
alongside introducing native IPv6 support. However, any and all
existing end user IPv4 devices (eg PCs, etc) will not affected. Nor
are such devices expected to behave in any way different from that of
today, where they typically obtain a private rfc1918 address and
multiplexed by a CPE using a NAPT44 function.
In summary, the assumed 4via6 solution requires a specific 4via6 CPE
but does not require any IPv4 host stack changes.
5.3. 4V6 address and impact on other IPv6 hosts
5.3.1. Overview
The issue relates to the question of whether the operation of a
regular IPv6, non 4V6 capable, host would be adversely impacted
should it be assigned or auto-configured with an address from an S64
address or prefix pool.
5.3.2. Discussion
The 4V6 prefix is for all intents and purposes a regular IPv6 prefix,
and as such can be announced/assigned to any IPv6 host which in turn
can used derived addresses like any other IPv6 address. Thus, an 4V6
IPv6 domain can address non-4V6 devices, leaving such devices to
operate as native IPv6.
There is however a restriction on the 4V6 CE devices. As described
in Section 2, a 4V6 CE constructs itself the full 128 bit address
from the concatenation of the IPv6 prefix, 4V6 domain information
acquired statelessly, and a pre-determined or algorithmic
interface-id. By definition, only one 4V6 CE can use the same IPv4
address and port index. Hence, while there is no exact limitation on
the number of non 4V6 hosts that can be addressed from an 4V6 prefix,
there is a limit of one 4V6 CE per 4V6 prefix. Using a 4V6 prefix to
address network segments without 4V6 devices does diminish the
efficiency of the IPv4 address sharing mechanism, in terms of using
up port ranges onto segments that will not use them. This is
naturally a deployment consideration which an operator can optimize.
Dec, et al. Expires April 16, 2012 [Page 23]
Internet-Draft stateless 4V6 October 2011
5.4. Impact on 4V6 CE based applications
5.4.1. Overview
It has been claimed that applications implemented on the CE itself,
eg a DNS resolver-client, may be impacted by the 4V6 functionality.
In particular, a concern is that such applications would either need
to be specially engineered to issue socket calls or extensive IP
stack modifications made to support them.
5.4.2. Discussion
By definition the 4V6 CE is an IPv6 capable device, and any IPv6
capable applications will be able to use the native IPv6 stack (note:
IPv6 interface selection, is discussed in section 5.5). As such, the
concern raised does not apply to applications that can be expected to
support IPv6, and instead only to IPv4-only applications running on
the 4V6 CE.
The shared IPv4 address is intended to be used only by the 4V6 CE
function. This shared IPv4 address does not need to be assigned to
an interface on the 4V6 CE and thus a target for potential
applications. Any such applications running on the 4V6 will use any
of the other (likely private) IPv4 address on the CE, which then will
be routed to the 4V6 function this is applied post routing for the
packets generated by these applications.
5.5. 4V6 interface
5.5.1. Overview
A 4V6 CE will have a "self configured" 4V6 IPv6 interface address,
alongside any other SLAAC or DHCPv6 derived addresses, potentially
from the same prefix. This particular 4V6 address may be subject to
specific filtering rules or restrictions by the operator, besides
usage and filtering restrictions on the 4V6 CE. Also, for the 4V6
system to operate as intended, the 4V6 application on the CE must be
restricted to using the specific 4V6 address when sourcing 4V6
packets. Also, the 4V6 CE needs to be set-up to correctly forward
IPv4 traffic to the 4V6 application.
5.5.2. Discussion
While the method of creating the interface is implementation
specific, the generic operating model that is envisaged is for the
4V6 application to create the 4V6 interface as a virtual interface
with an IPv4 unnumbered address. The application would then install
a default IPv4 route pointing to this virtual interface, which would
Dec, et al. Expires April 16, 2012 [Page 24]
Internet-Draft stateless 4V6 October 2011
be effectively see the 4V6 application acting as a network appliance
on the forwarded traffic. In terms of IPv6 behaviour, the 4V6
application is expected to be set up to specify the use (binding) to
the 4v6 IPv6 virtual interface.
5.6. Non TCP/UDP port based IP protocols - ICMP)
5.6.1. Overview
This issue relates to the inability of using regular ICMP messages to
"ping" an end-host that has been addressed with a shared IPv4
address. The issue can be generalized one applicable to any IP
protocol that is not TCP/UDP port based, and also in terms of the
ability of using such protocols from end hosts that are assigned a
shared IPv4 address.
5.6.2. Discussion
The inability to ping a CPE from the IPv4 Internet is shared by other
IPv4 address sharing mechanisms such as DS-Lite. Thus, the issue is
no better or worse in the case of the stateless 4via6 solution. The
same can be said of end user hosts using other non UDP/TCP port based
protocols from behind a NAPT44 function, ie they will not function
irrespective of address sharing or not.
As discussed in [I-D.ietf-intarea-shared-addressing-issues], all IP
address sharing solutions break protocols which do not use transport
numbers. A mitigation solution is to utilize specific ALGs. For
ICMP in particular, a mitigation solution would be to rewrite the
"Identifier" and perhaps "Sequence Number" fields in the ICMP
request, treating them as if they were port numbers.
As a conclusion, this issue can be partially mitigated, likely at par
to centralized NAT solutions.
5.7. Provisioning and Operational Systems
5.7.1. Overview
The general claim of this issue is that a service providers'
provisioning and accounting systems would need to [radically] evolve
to deal with the notions of shared IPv4 addresses and port range
constrains.
5.7.2. Discussion
The stateless 4via6 solution relies on a fully operational IPv6
network, which on the IPv6 plane fundamentally does not differ from a
Dec, et al. Expires April 16, 2012 [Page 25]
Internet-Draft stateless 4V6 October 2011
regular IPv6 network, and the stateless 4via6 solution may be seen as
an IPv6 application - devices connecting to the network, need unique
IPv6 addresses which the network is able to provide. In the 4via6
solution it happens that these unique IPv6 addresses embed an IPv4
address. Hence, additional system enhancements that the stateless
4via6 solution requires, over and above those simply needed to deploy
and operate an IPv6 network, lie in the domain of supporting the
provisioning of the IPv6 adaptation functionality of the CPEs. This
may require the operator to use DHCPv6, or other provisioning methods
such as IPv6CP, TR-69, in order to configure any relevant 4via6
service parameters to a CPE.
From an IPv4 perspective, an operator will likely want to have a
management system capable of the assignment of IPv4 addresses to the
shared pool, and tuning the re-use factor. In this, the solution
exhibits no grossly different characteristics than those of any
system with an operator managed NAT44 function where similar
management capabilities need to be introduced.
One additional aspect of the stateless 4via6 solution needs to be
highlighted. On a par basis this solution requires less per
subscriber management, accounting and logging capabilities than
centralized NAPT44 alternatives such as DS-Lite, due to the
following:
o The assignment of an IPv6 address that embeds a deterministic IPv4
address and port range removes the need for the operator to
perform any NAPT44 binding logging, ie the task of determining
which user had a given IPv4 address and port at a given time is
simply a matter of determining who had the corresponding IPv6
address, rather than collecting large amounts of dynamic binding
data.
o There is no need for the operator to manage NAPT44 binding data
access and retention.
o Given the stateless nature of the 4via6 solution, all subscriber
CPEs in an operator's domain can share exactly the same 4via6
service configuration, i.e. The operator does not need to be
concerned with managing on a per user basis specific AFTR
assignment and/or load balancing such users and throughout
ensuring symmetric traffic flows throughout.
o The location of the NAPT44 function on the user's CPE, allows easy
and direct management of the port mappings by the end user
removing a need for the operator to introduce PCP
[I-D.wing-softwire-port-control-protocol] (or similar) protocols
in on AFTRs, and on CPE devices. In effect the end user can
Dec, et al. Expires April 16, 2012 [Page 26]
Internet-Draft stateless 4V6 October 2011
retains control of any bindings, which could be via today's GUI,
or UPnP IGDv2, or even PCP.
o As and when needed, a stateless 4via6 solution readily supports
the assignment of an unshared IPv4 address, and full port control
by the end user. A similar capability with centralised NAPT44
solutions involve onerous management of per subscriber
configurations on the operator's AFTR.
5.8. Training & Education
5.8.1. Overview
The issue claims a concern with the need for developers and support
staff to be trained & educated in dealing with a port constrained
systems.
5.8.2. Discussion
There appear to be at least two levels of looking at this issue in
the stateless 4via6 context. On one level, it is perfectly true that
developers and support staff will need to be trained with running/
supporting a native IPv6 network, that is now a basis of the
solution. This however is an inherent aspect of deploying an IPv6
network and applications. On another level, support and developers
need to familiarized with the NAPT44 characteristics of the system,
that are not different from those already known about such systems
today. More specifically, there appears to be no such thing as a
port unconstrained carrier grade NAPT44 system, in either tomorrow's
stateless 4via6 or AFTR guises, or today's residential CPE NAPT44
implementations that have an inherent hard set translation limit
(often 1024 translation, corresponding to a usage of 1024 ports).
That application developers should be trained to be reasonably
conservative in the usage of ports is thus not an issue of the
stateless 4via6 solution, but pretty much of any NAPT44 based
solution, even those in use today.
Another useful observation here is that the stateless 4via6 solution,
actually allows an operator to retain existing troubleshooting
procedures, given which today encompass CPE based NAPT44, rather than
changing them radically to an AFTR. Furthermore, it is possible to
alleviate any port-range constrains for users by allocating more
generous port ranges without the need to manage such users
configuration on active core network devices (eg AFTR).
Dec, et al. Expires April 16, 2012 [Page 27]
Internet-Draft stateless 4V6 October 2011
5.9. Security and Port Randomization
5.9.1. Overview
Preserving port randomization [RFC6056] may be more or less difficult
depending on the address sharing ratio (i.e., the size of the port
space assigned to a CPE). Port randomization may be more difficult
to achieve with a stateless solution than stateful solution. The CPE
can only randomize the ports inside be assigned a fixed port range.
5.9.2. Discussion
The difference in the random port selection range may be significant
in practice and using port-restricted systems without any measures
(like random port selection in draft-bajko-pripaddrassign-03) is one
of the trade-offs of the mechanism. It should be however noted that
even full port unrestricted systems, today, rarely implement random
port selection from the full port range, as such the difference is
largely theoretical, again viewed from today's perspective. Only
with a longer term prospect of devices/hosts adopting random port
selection according to RFC 6056 the NAT-based port-restricted
mechanisms, will degrade security to a certain extent.
5.10. Unknown Failure Modes
5.10.1. Overview
The issue purports that a system with a port constraints introduces
new unknown failure modes, not known with NAT44 or NAPT44 systems,
and in general is more complex than such a system.
5.10.2. Discussion
This claim does not appear to have objective technical arguments that
can be discussed. A restricted port range system, such as the one
assumed in this document, does not appear to have any more or less
complexity than any of the other NAPT44 solutions against which the
same issue has not been levelled. That is a statement that can be
made in consideration of each of those alternative solution network
design (eg elaborate routing rules or topologies) and feature
implementation complexities, which appear to be no better than that
of a stateless 4via6 address port range system. Ultimately, system
complexity is something best left adjudicated by the operators
choosing to deploy one or the other of these IP based transition
solutions.
Dec, et al. Expires April 16, 2012 [Page 28]
Internet-Draft stateless 4V6 October 2011
5.11. Possible Impact on NAT66 use & design
5.11.1. Overview
The notion of a shared address with a constrained port range is seen
as possibly bearing influence on use in future schemes involving
NAT66, where IPv6 address sharing is in general deemed not to be
desired (ie there is good reason to avoid PAT66).
5.11.2. Discussion
The authors do not propose, nor expect to see the IP address sharing
characteristic applying to future NAT66/PAT66 discussions and
specification. However, having said that it is useful to take a
humble step back and consider the general aspect of causality in this
context. The direct cause that brought about IPv4 shared address
solutions to the fore was a shortage/exhaustion of a limited IPv4
address resource, alongside a failure of the community to migrate
IPv4 networks to IPv6 in a timely manner. At the time of writing it
is hard to imagine the same occurring with respect to IPv6 address
resources, and hopefully the same set of causes will not be allowed
to re-occur. This appears to be the only way to ensure that IPv6
address sharing effect does not come to be, as opposed to precluding
such notions within the context of today's IPv4 world where the
causality is rather clear.
5.12. Port statistical multiplexing and monetization of port space
5.12.1. Overview
An issue attributed to 4V6 solutions is that due to their
characteristic of assigning a fixed amount of ports to participating
system nodes, the overall pool of ports cannot be dynamically/
statistically multiplexed.
A corollary of this claimed issue is the claim that port range
constraints will lead to monetization by service providers of such
port ranges, for example by charging users based on the number of
ports assigned or creating some bronze, silver, gold type of port
based service categories.
5.12.2. Discussion
The 4via6 address shared solution indeed limits the ability to
"overload" ie statistically multiplex amongst users, the ports
available of a given public IPv4 address. This can be seen as a
trade off vs dynamic allocation and the need to log (large amounts)
of NAT bindings. Furthermore, the solution is meant to be
Dec, et al. Expires April 16, 2012 [Page 29]
Internet-Draft stateless 4V6 October 2011
fundamentally a transitional one for supporting legacy IPv4 users
till full migration to IPv6 can occur. As an example, even with a
static allocation of ~1000 ports per shared IP user, it allows an
operator to effectively multiply by ~64 the current IPv4 unrealizable
address space. To put it into a network growth perspective, it
allows an operator to support for some 10 years a steady 50% annual
increase in users, without requiring new IPv4 addresses. This is
likely an alluring (if unlikely) prospect for most, but it
demonstrates the fact that even with static port allocations, IPv4
address sharing can go a long way for many operators.
CGN-based solutions, because they can dynamically assign ports,
provide better IPv4 address sharing ratio than stateless solutions
(i.e., can share the same IP address among a larger number of
customers). For Service Providers who desire an aggressive IPv4
address sharing, a CGN-based solution is more suitable than the
stateless. However, in case a CGN pre-allocates port ranges, for
instance to alleviate traceability complexity it also reduces its
port utilization efficiency.
5.13. Readdressing
5.13.1. Overview
Due to the port range encoding being part of the CPE's IPv6 address,
any change in the range requires a re-configuration of the CPEs 4via6
address. This is said to be an issue given the impact that IP
address changes have on existing traffic flows, as well as general
IPv6 network routing
5.13.2. Discussion
It is true that under the assumed notions of the stateless 4via6
solution, IPv6 re-addressing is required to effect a change in terms
of the shared IPv4 address or ports. Such changes can and are likely
best done using dynamic address configuration methods such as DHCPv6,
or alternatively out of band management tools, eg TR-69, especially
when the 4via6 address can be derived from a delegated prefix. Using
these, the impact of the address change does not translate to a
neither a classic IPv6 host renumbering problem nor an unmanageable
network renumbering problem. On the CPE, the change only affects the
4via6 address of the CPE and not any end user IPv6 hosts behind the
CPE (which would likely continue to derive their IPv6 addresses from
an unchanged delegated prefix). On the service provider network
side, the change, if any, represents a network renumbering case which
the operator can be reasonably expected to handle within their
network numbering plan, especially given that the IPv6-prefix of the
an IPv4-in-IPv6 address is summarizable.
Dec, et al. Expires April 16, 2012 [Page 30]
Internet-Draft stateless 4V6 October 2011
An addressing change will impacting any existing IPv4 flows that are
being NAT'ed by the CPE. This is also analogous to the today's
practice of IPv4 address changes espoused by some operators, which
while not being commendable, is established in the market.
Nevertheless, as a means of alleviating such an impact it appears
desirable for the solutions to investigate the viability of
mechanisms that could allow for more graceful addressing changes.
To facilitate IPv6 summarization and operator appears to have two 4V6
deployment choices. When encoding IPv4 addresses in lower order
address space bits that are subject to summarization,the operator
would need to assign a modest dedicated IPv6 prefix (such as a /64)
as an 4V6 IPv6 addressing sub-domain. Alternatively, without
resorting to a separate 4V6 addressing sub-domain, an operator could
allow for the IPv4 address embedding to be embedded in a high-order
portion of the IPv6 domain address space, one that closely follows
the IPv6 domain prefix. These two valid address subnetting and
deployment options deserve better description in the solution
specifications.
5.14. Ambiguity about communication between devices sharing an IP
address.
5.14.1. Overview
A regular IPv4 destination based routed system inherently does not
allow two devices to communicate while sharing the same IPv4 address,
even if with different ports. Similarly, such a system does not
allow on the basis of a IPv4 source address alone to perform address
spoofing prevention. These two issues naturally render regular IPv4
based routed networks incapable of supporting a shared address
solution.
5.14.2. Discussion
In terms of the IPv4 data plane of the 4via6 solution, the CPE and
the stateless gateway components need to be modified in terms of
their IPv4 forwarding behaviour. The CPE's NAPT44 function, must be
capable of sending traffic towards the IPv6 adaptation function when
the traffic is addressed to its (shared) IPv4 address but a different
port than the one assigned to the CPE. Similarly, the CPE's NAPT44
function must be capable of receiving traffic addressed from its
(shared) IPv4 address but a different port than the one assigned to
it.
On the IPv6 data plane the stateless 4via6 solution does not suffer
from the issue by the nature of relying on regular IPv6 forwarding.
Address-spoofing security can be realized on regular IPv6 devices
Dec, et al. Expires April 16, 2012 [Page 31]
Internet-Draft stateless 4V6 October 2011
plane, in a way which effectively does not allow a CPE to send IPv6
traffic from a source IPv6 address that it has not been assigned.
The spoofing of IPv4 addresses can be prevented in this manner in
4via6 solution relying on translation (dIVI). Tunneling 4via6
solutions (4rd) require IPv6+IPv4 source address validation to be
performed at the CPE and stateless gateway, by the IPv6 adaptation
function.
The conceptual IPv6 adaptation function has many of its core
principles already defined either as part of IPinIP tunneling or
stateless NAT64 drafts. However additional work, such as defining
the port indexing schemes, is needed and is at the heart of what
needs to be covered in the individual solution drafts that fall under
the stateless 4via6 family. Throughout, no legacy IPv4 end-systems
are expected to implement these techniques.
5.15. Other
5.15.1. Abuse Claims
Because the IPv4 address is shared between several customers, and in
order to meet the traceability requirement discussed in Section 12 of
[I-D.ietf-intarea-shared-addressing-issues], Service Providers must
store the assigned ports in addition to the IPv4 address.
If the remote server does not implement the recommendation detailed
in [I-D.ietf-intarea-server-logging-recommendations], the Service
Provider may be obliged to reveal the identity of all customers
sharing the same IP address at a given time.
5.15.2. Fragmentation and Traffic Asymmetry
In order to deliver a fragmented IPv4 packet to its final
destination, among those having the same IPv4 address, a dedicated
procedure similar to the one defined in Section 3.5 of [RFC6146] is
required to reassemble the fragments in order to look at the
destination port number.
When several stateless IPv4/IPv6 interconnection nodes are deployed,
and because of traffic asymmetry, situations where fragments are not
handled by the same stateless IPv4/IPv6 interconnection node may
occur. Such context would lead to session breakdowns. As a
mitigation, a solution would be to redirect fragments towards a given
node which will be responsible for implementing the procedure
documented in [RFC6146]. The redirection procedure is stateless.
As a conclusion, this issue can be mitigated.
Dec, et al. Expires April 16, 2012 [Page 32]
Internet-Draft stateless 4V6 October 2011
5.15.3. Multicast Services
IPv4 service continuity must be guaranteed during the transition
period, including the delivery of multicast-based services such as
IPTV. Because only an IPv6 prefix will be provided to a CPE,
dedicated functions are required to be enabled for the delivery of
legacy multicast services to IPv4 receivers. This is critical since
many of the current IPTV contents are likely to remain IPv4-formatted
and there will remain legacy receivers (e.g., IPv4-only Set Top Boxes
(STB)) that can't be upgraded or be easily replaced.
This issue is similar to the one encountered in the stateful case,
and the same solution can be used to mitigate the issue (e.g.,
[I-D.qin-softwire-dslite-multicast]).
As a conclusion, this issue can be solved.
6. Conclusion
As per the discussion in this document, the authors believe that the
set of issues specifically attributed to A+P based such as the
stateless 4via6 solution with characteristics as per Section 3,
either do not apply, or can be mitigated. In several aspects, a
stateless 4V6 solution represents a reasonable trade off compared to
alternatives in areas such as NAT logging, ease as of deployment and
operations, all of which are actually facilitated by such a solution.
In terms of the 4V6 transport mode, both translation and mapped
tunnel appear to be share the same key characteristics, but
applicable to different contexts. The mapped tunnel mode appears
desirable when the operator has no expectations of applying any more
elaborate traffic based services, and/or concerned about the loss of
IP Options or the use of NAT64 technology. The translation based
approach appears particularly attractive to operators who are
concerned about integrating traffic into a more elaborate suite of
services based on regular IPv6 data-plane functionality, as opposed
to specific IPinIP data plane functionality.
7. IANA Considerations
This document does not raise any IANA considerations.
8. Security Considerations
This document does not introduce any security considerations over and
Dec, et al. Expires April 16, 2012 [Page 33]
Internet-Draft stateless 4V6 October 2011
above those already covered by the referenced solution drafts.
9. Contributors and Acknowledgements
The authors thank Dan Wing, Nejc Skoberne, Remi Depres, Xing Li, Jan
Zorz, Satoru Matsushima, Mohamed Boucadair, Qiong Sun, and Arkadiusz
Kaliwoda for their reviews and draft input.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment",
draft-bajko-pripaddrassign-03 (work in progress),
September 2010.
[I-D.despres-softwire-4rd]
Despres, R., "IPv4 Residual Deployment across IPv6-Service
networks (4rd) A NAT-less solution",
draft-despres-softwire-4rd-00 (work in progress),
October 2010.
[I-D.ietf-intarea-server-logging-recommendations]
Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging recommendations for Internet facing servers",
draft-ietf-intarea-server-logging-recommendations-04 (work
in progress), April 2011.
[I-D.ietf-intarea-shared-addressing-issues]
Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing",
draft-ietf-intarea-shared-addressing-issues-05 (work in
progress), March 2011.
[I-D.ietf-softwire-ds-lite-tunnel-option]
Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite",
draft-ietf-softwire-ds-lite-tunnel-option-10 (work in
progress), March 2011.
Dec, et al. Expires April 16, 2012 [Page 34]
Internet-Draft stateless 4V6 October 2011
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work
in progress), May 2011.
[I-D.murakami-softwire-4v6-translation]
Murakami, T., Chen, G., Deng, H., Dec, W., and S.
Matsushima, "4via6 Stateless Translation",
draft-murakami-softwire-4v6-translation-00 (work in
progress), July 2011.
[I-D.operators-softwire-stateless-4v6-motivation]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Stateless IPv4
over IPv6 Migration Solutions",
draft-operators-softwire-stateless-4v6-motivation-02 (work
in progress), June 2011.
[I-D.qin-softwire-dslite-multicast]
Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y.
Lee, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments",
draft-qin-softwire-dslite-multicast-04 (work in progress),
June 2011.
[I-D.thaler-port-restricted-ip-issues]
Thaler, D., "Issues With Port-Restricted IP Addresses",
draft-thaler-port-restricted-ip-issues-00 (work in
progress), February 2010.
[I-D.vixie-dnsext-dns0x20]
Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to
Improve Transaction Identity",
draft-vixie-dnsext-dns0x20-00 (work in progress),
March 2008.
[I-D.wing-softwire-port-control-protocol]
Wing, D., Penno, R., and M. Boucadair, "Pinhole Control
Protocol (PCP)",
draft-wing-softwire-port-control-protocol-02 (work in
progress), July 2010.
[I-D.xli-behave-divi]
Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-03
(work in progress), July 2011.
Dec, et al. Expires April 16, 2012 [Page 35]
Internet-Draft stateless 4V6 October 2011
[I-D.xli-behave-divi-pd]
Li, X., Bao, C., Dec, W., Asati, R., Xie, C., and Q. Sun,
"dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix
Delegation", draft-xli-behave-divi-pd-01 (work in
progress), September 2011.
[I-D.ymbk-aplusp]
Bush, R., "The A+P Approach to the IPv4 Address Shortage",
draft-ymbk-aplusp-10 (work in progress), May 2011.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
August 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
January 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
Authors' Addresses
Wojciech Dec
Cisco
Haarlerbergweg 13-19
1101 CH Amsterdam
The Netherlands
Email: wdec@cisco.com
Dec, et al. Expires April 16, 2012 [Page 36]
Internet-Draft stateless 4V6 October 2011
Rajiv Asati
Cisco
Raleigh, NC
USA
Phone:
Fax:
Email: rajiva@cisco.com
URI:
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing, 100084
CN
Phone: +86 10-62785983
Fax:
Email: congxiao@cernet.edu.cn
URI:
Hui Deng
China Mobile
Beijing,
CN
Phone:
Fax:
Email: denghui@chinamobile.com
URI:
Mohamed Boucadair
France Telecom
France
Phone:
Fax:
Email: mohamed.boucadair@orange-ftgroup.com
URI:
Dec, et al. Expires April 16, 2012 [Page 37]