Network Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Informational S. Matsushima
Expires: November 18, 2011 Softbank Telecom
Y. Lee
Comcast
O. Bonness
Deutsche Telekom
I. Borges
Portugal Telecom
May 17, 2011
Motivations for Stateless IPv4 over IPv6 Migration Solutions
draft-operators-softwire-stateless-4v6-motivation-01
Abstract
IPv4 service continuity is one of the most sensitive problems that
must be resolved by Service Providers during the IPv6 transition
period - especially after the exhaustion of the public IPv4 address
space. Current standardization effort that addresses IPv4 service
continuity focuses on stateful mechanisms. This document elaborates
on the motivations for the need to undertake a companion effort to
specify stateless IPv4 over IPv6 approaches. This document does not
claim that only stateless solutions are required but rather
acknowledges both stateless and stateful solutions are needed. The
selection of the appropriate solution(s) to be deployed depends on
each Service Provider's context and decision-making process. It
should take into account both technical and economical
considerations.
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."
Boucadair, et al. Expires November 18, 2011 [Page 1]
Internet-Draft Solution Motivations May 2011
This Internet-Draft will expire on November 18, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Boucadair, et al. Expires November 18, 2011 [Page 2]
Internet-Draft Solution Motivations May 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Why Stateless IPv4 over IPv6 Solutions are Needed? . . . . . . 6
3.1. Network Architecture Simplification . . . . . . . . . . . 6
3.1.1. Network Dimensioning . . . . . . . . . . . . . . . . . 6
3.1.2. No Intra-domain Constraint . . . . . . . . . . . . . . 6
3.1.3. CPE-to-CPE Communications . . . . . . . . . . . . . . 7
3.1.4. Logging - No Need for Dynamic Binding Notifications . 7
3.1.5. No Additional Protocol for Port Control is Required . 7
3.1.6. Support of Multi-Vendor Redundancy . . . . . . . . . . 8
3.2. Simplification of Qualification Procedures . . . . . . . . 8
3.3. Operational Tasks Efficiency . . . . . . . . . . . . . . . 8
3.3.1. Preserve Current Practices . . . . . . . . . . . . . . 9
3.3.2. Planned Maintenance Operations . . . . . . . . . . . . 9
3.3.3. Reliability and Robustness . . . . . . . . . . . . . . 9
3.4. Implicit Host Identification . . . . . . . . . . . . . . . 9
3.5. No Organizational Impact . . . . . . . . . . . . . . . . . 10
4. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Dependency Between IPv4 and IPv6 Address Assignments . . . 11
4.2. IPv4 Port Utilisation Efficiency . . . . . . . . . . . . . 11
4.3. IPv4 Port Randomization . . . . . . . . . . . . . . . . . 11
5. Both Stateless and Stateful are Needed . . . . . . . . . . . . 12
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Boucadair, et al. Expires November 18, 2011 [Page 3]
Internet-Draft Solution Motivations May 2011
1. Introduction
When the global IPv4 address space is exhausted, Service Providers
will be left with an address pool that cannot be increased anymore.
Many services and network scenarios will be impacted by the lack of
IPv4 public addresses. Providing access to the (still limited) IPv6
Internet only won't be sufficient to address the needs of customers,
as most of them will continue to access legacy IPv4-only services.
Service Providers must guarantee their customers that they can still
access IPv4 contents although they will not be provisioned with a
global IPv4 address anymore. Means to share IPv4 public addresses
are unavoidable [I-D.ietf-intarea-shared-addressing-issues].
Identifying the most appropriate solution(s) to the IPv4 address
exhaustion as well as IPv4 service continuity problems and deploying
them in a real network with real customers is a very challenging and
complex process for all Service Providers. There is nothing like a
"One size fits all" solution or one target architecture that would
work for all situations. Each Service Provider has to take into
account its own context (e.g., service infrastructures), policies and
marketing strategy (a document that informs Service Providers about
the impact of the IPv4 address shortage, and provides some
recommendations and guidelines, is available at [EURESCOM]).
Current standardization effort that is meant to address this IPv4
service continuity issue focuses mainly on stateful mechanisms that
assume the sharing of any global IPv4 address that is left between
several customers, based upon the deployment of NAT (Network Address
Translation) capabilities in the network. Because of some caveats of
such stateful approaches the Service Provider community feels that a
companion effort is required to specify stateless IPv4 over IPv6
approaches. This document provides elaboration on such need.
Particularly, this document describes the motivations for stateless
solutions within the context of an IPv6-enabled network as described
in [I-D.arkko-ipv6-transition-guidelines]. The following table shows
the targeted space:
Boucadair, et al. Expires November 18, 2011 [Page 4]
Internet-Draft Solution Motivations May 2011
+---------------+---------------+
| Crossing IPv4 | IPv6-enabled |
| networks | networks |
+-----------+---------------+---------------+
| Stateful | RFC5571 | DS-Lite |
| solution | (L2TP) | |
+-----------+---------------+---------------+
| Stateless | RFC5969 | *Target* |
| solution | (6rd) | *space * |
+-----------+---------------+---------------+
From a Service Provider perspective, stateless solutions are more
attractive because they do less impact the current network operation
and maintenance model that is widely based on stateless approaches.
While not all Service Providers environments are the same, a detailed
case study from one Service Provider
[I-D.matsushima-v6ops-transition-experience] reports that stateless
transition solutions can be considerably less expensive than stateful
transition solutions. Further elaboration on the hidden costs (e.g.,
update OSS, management interfaces, mitigation issues to solve issues
common to all address sharing techniques
[I-D.ietf-intarea-shared-addressing-issues]) is to be further
elaborated by each Service Provider.
It is explicitly acknowledged by the authors of this document that
both stateful and stateless solutions are required to meet Service
Providers needs and constraints.
2. Terminology
This document makes use of the following terms:
Stateful 4/6 solution (or stateful solution in short): denotes a
solution where the network maintains user-session
states relying on the activation of a NAT
function in the Service Providers' network
[I-D.ietf-behave-lsn-requirements]. The NAT
function is responsible for sharing the same IPv4
address among several subscribers and to maintain
user-session states.
Stateless 4/6 solution (or stateless solution in short): denotes a
solution which does not require any user-session
state to be maintained by any IP address sharing
function in the Service Provider's network. This
category of solutions assumes a dependency
between an IPv6 prefix and IPv4 address. More
Boucadair, et al. Expires November 18, 2011 [Page 5]
Internet-Draft Solution Motivations May 2011
precisely, the IPv4 address and the significant
bits coding the port range are reflected inside
the IPv6 prefix assigned to a port-restricted
device. This can be achieved either by embedding
the full IPv4 address and the significant bits in
the IPv6 prefix or by applying an algorithmic
approach. In an IPv4 address sharing context,
dedicated functions are required to be enabled in
the CPE router to restrict the source IPv4 port
numbers. Within this document, "port set" and
"port range" terms are used interchangeably.
3. Why Stateless IPv4 over IPv6 Solutions are Needed?
This section discusses motivations for preferring a deployment of
stateless 4/6 solutions. The technical and operational benefits of
the stateless solutions are possible because no per-user state is
maintained by any IP address sharing function in the Service
Providers networks.
3.1. Network Architecture Simplification
The deployment of stateless solutions relies upon the activation of a
stateless IPv4/IPv6 interconnection function located in the Service
Provider's network and in CPE routers. The stateless IPv4/IPv6
interconnection function is responsible to adapt in a stateless
fashion IPv4 datagrams into IPv6 ones and vice versa. The activation
of this stateless function in the Service Provider's network does not
introduce any major constraint on the network architecture and its
engineering. The following sub-sections elaborate on these aspects.
3.1.1. Network Dimensioning
Because no user-state is required, a stateless solution does not need
to take into account the maximum number of simultaneous user-sessions
and the maximum number of new user-sessions per second to dimension
its networking equipment. Like current network dimensioning
practices, only considerations related to the customer number,
traffic trends and the bandwidth usage need be taken into account for
dimensioning purposes.
3.1.2. No Intra-domain Constraint
Stateless IPv4/IPv6 interconnection functions can be ideally located
at the boundaries of an Autonomous System (e.g., ASBR routers that
peer with external IPv4 domains); in such case:
Boucadair, et al. Expires November 18, 2011 [Page 6]
Internet-Draft Solution Motivations May 2011
o Intra-domain paths are not altered: there is no need to force IP
packets to cross a given node for instance; intra-domain routing
processes are not tweaked to direct the traffic to dedicated
nodes.
o Intra-domain communications do not cross any IPv4/IPv6
interconnection resources.
3.1.3. CPE-to-CPE Communications
Another motivation for stateless is it optimizes CPE-to-CPE
communication in that packets don't go through the interconnection
function since the address and port mapping has been realized based
on a well defined mapping schema that is known to all involved
devices.
3.1.4. Logging - No Need for Dynamic Binding Notifications
Network abuse reporting requires traceability. To provide such
traceability, prior to IPv4 address sharing, logging the IPv4 address
assigned to a user was sufficient and generates relatively small
logs. The advent of stateful IPv4 address allows dynamic port
assignment, which then requires port assignment logging. This
logging of port assignments can be considerable.
In contrast, static port assignments do not require such considerable
logging. The volume of the logging file may not be seen as an
important criterion for privileging a stateless approach because
stateful approaches can also be configured (or designed) to assign
port ranges and therefore lead to acceptable log volumes.
If a dynamic port assignment mode is used, dedicated interfaces and
protocols must be supported to forward binding data records towards
dedicated platforms. The activation of these dynamic notifications
may impact the performance of the dedicated device. For stateless
solutions, there is no need for dynamic procedures (e.g., using
SYSLOG) to notify a mediation platform about assigned bindings.
Some Service Providers have a requirement to use only existing
logging systems and to avoid introducing new ones (mainly because of
CAPEX considerations). This requirement is easily met with stateless
solutions.
3.1.5. No Additional Protocol for Port Control is Required
The deployment of stateless solution does not require the deployment
of new dynamic signaling protocols to the end-user CPE in addition to
those already used. In particular, existing protocols (e.g., UPnP
Boucadair, et al. Expires November 18, 2011 [Page 7]
Internet-Draft Solution Motivations May 2011
IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the CPE.
3.1.6. Support of Multi-Vendor Redundancy
Deploying stateful techniques, especially when used in the Service
Providers networks, constrain severely deploying multi-vendor
redundancy since very often proprietary vendor-specific protocols are
used to synchronize state. This is not an issue for the stateless
case. Concretely, the activation of the stateless IPv4/IPv6
interconnection function does not prevent nor complicate deploying
devices from different vendors.
This criterion is very important for Service Providers having a
sourcing policy to avoid mono-vendor deployments and to operate
highly-available networks composed on multi-vendors equipment.
3.2. Simplification of Qualification Procedures
The introduction of new functions and nodes into operational networks
follows strict procedures elaborated by Service Providers. These
procedures include in-lab testing and field trials. Because of their
nature, stateless implementations optimize testing times and
procedures:
o The specification of test suites to be conducted should be
shorter;
o The required testing resources (in terms of manpower) are likely
to be less solicited that they are for stateful approaches.
One of the privileged approaches to integrate stateless IPv4/IPv6
interconnection function consists in embedding stateless capabilities
in existing operational nodes (e.g., IP router). In this case, any
software or hardware update would require to execute non-regression
testing activities. In the context of the stateless solutions, the
non-regression testing load due to an update of the stateless code is
expected to be minimal.
For the stateless case, testing effort and non-regression testing are
to be taken into account for the CPE side. This effort is likely to
be lightweight compared to the testing effort, including the non-
regression testing, of a stateful function which is co-located with
other routing functions for instance.
3.3. Operational Tasks Efficiency
Boucadair, et al. Expires November 18, 2011 [Page 8]
Internet-Draft Solution Motivations May 2011
3.3.1. Preserve Current Practices
Service Providers require as much as possible to preserve the same
operations as for current IP networking environments.
If stateless solutions are deployed, common practices are preserved.
In particular, the maintenance and operation of the network do not
require any additional constraints such as: path optimization
practices, enforcing traffic engineering policies, issues related to
traffic oscillation between stateful devices, load-balancing the
traffic or load sharing the traffic among egress/ingress points can
be used, etc. In particular:
o anycast-based schemes can be used for load-balancing and
redundancy purposes.
o asymmetric routing to/from the IPv4 Internet is natively supported
and no path-pinning mechanisms have to be additionally
implemented.
3.3.2. Planned Maintenance Operations
Since no state is maintained by stateless IPv4/IPv6 interconnection
nodes, no additional constraint needs to be taken into account when
upgrading these nodes (e.g., adding a new service card, upgrading
hardware, periodic reboot of the devices, etc.).
In particular, current practices that are enforced to (gracefully)
reboot or to shutdown routers can be maintained.
3.3.3. Reliability and Robustness
Compared to current practices (i.e., without a CGN in place), no
additional capabilities are required to ensure reliability and
robustness in the context of stateless solutions. Since no state is
maintained in the Service Provider's network, state synchronization
procedures are not required.
High availability (including failure recovery) is ensured owing to
best current practices in the field.
3.4. Implicit Host Identification
Service Providers do not offer only IP connectivity services but also
added value services (a.k.a., internal services). Upgrading these
services to be IPv6-enabled is not sufficient because of legacy
devices. In some deployments, the delivery of these added-value
services relies on implicit authentication mechanism based on the
Boucadair, et al. Expires November 18, 2011 [Page 9]
Internet-Draft Solution Motivations May 2011
source IPv4 address. Due to address sharing, implicit authentication
will fail [I-D.ietf-intarea-shared-addressing-issues]; replacing
implicit authentication with explicit authentication will be seen as
a non acceptable service regression by the end users (less quality of
experience).
When a stateless solution is deployed, implicit authentication for
internal services is likely to be easier to implement: the implicit
authentication should be updated to take into account the port range
and the IPv4 address. Techniques as those analyzed in
[I-D.boucadair-intarea-nat-reveal-analysis] are not required for the
delivery of these internal services if a stateless solution is
deployed.
3.5. No Organizational Impact
Stateless solutions rely on IP-related techniques to share and to
deliver IPv4 packets over an IPv6 network. In particular, IPv4
packets are delivered without any modification to their destination
CPE. As such there is a clear separation between the IP/transport
layers and the service layers; no service interference is to be
observed when a stateless solution is deployed. This clear
separation:
Facilitates service evolution: Since the payload of IPv4 packets is
not altered in the path, services can evolve without requiring any
specific function in the Service Provider's network;
Limits vendor dependency: The upgrade of value-added services does
not involve any particular action from vendors that provide
devices embedding the stateless IPv4/IPv6 interconnection
function.
No service-related skills are required for network operators who
manage devices that embed the IPv4/IPv6 interconnection function: IP
teams can be in charge of these devices; there is a priori no need
to create a dedicated team to manage and to operate devices
embedding the stateless IPv4/IPv6 interconnection function. The
introduction of stateless capabilities in the network are unlikely
to degrade management costs.
4. Open Questions
Issues common to all address sharing solutions are documented in
[I-D.ietf-intarea-shared-addressing-issues]. The following sub-
sections enumerates some open questions for a CPE-based stateless
solution. There are no universal answers to these open questions
Boucadair, et al. Expires November 18, 2011 [Page 10]
Internet-Draft Solution Motivations May 2011
since each Service Provider has its own constraints (e.g., available
address pool, address sharing ratio, etc.).
4.1. Dependency Between IPv4 and IPv6 Address Assignments
Complete stateless mapping implies that the IPv4 address and the
significant bits that are used to encode the set of assigned ports
can be retrieved from the IPv6 prefix assigned to the CPE. This
requirement can be addressed by either using the IPv6 prefix also
used to forward IPv6 traffic natively, or allocating two prefixes to
the CPE (one that will be used to forward IPv6 traffic natively, and
the other one to forward IPv4 traffic).
o Providing two IPv6 prefixes avoids the complexity that may be
related to the adaptation of the IPv6 addressing scheme to the
IPv4 addressing scheme. The drawback is the need to allocate two
prefixes instead of one to each CPE and to announce them
accordingly, possibly at the cost of jeopardizing the routing and
forwarding efficiencies.
o The use of a single prefix to cover both the forwarding of IPv6
and IPv4-in-IPv6 traffic avoids the need to maintain a double
information (e.g., for customer identification and management
purposes and for forwarding table maintenance purposes). This
scheme somewhat links strongly the IPv4 addressing scheme to the
allocated IPv6 prefixes. For Service Providers requiring to apply
specific policies on per Address-Family (e.g., IPv4, IPv6), some
provisioning tools (e.g., DHCPv6 option) may be required to derive
in a deterministic way the IPv6 address to be used for the IPv4
traffic based on the IPv6 prefix delegated to the home network.
4.2. IPv4 Port Utilisation Efficiency
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 (see Section 3.1.4) it
also reduces its port utilization efficiency.
4.3. IPv4 Port Randomization
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
Boucadair, et al. Expires November 18, 2011 [Page 11]
Internet-Draft Solution Motivations May 2011
can only randomize the ports inside be assigned a fixed port range.
Other means than the (IPv4) source port randomization to provide
protection against attacks should be used (e.g., use
[I-D.vixie-dnsext-dns0x20] to protect against DNS attacks, [RFC5961]
to improve the robustness of TCP against Blind In-Window Attacks, use
IPv6).
5. Both Stateless and Stateful are Needed
As discussed in Section 3, stateless solutions provide several
interesting features but they also share their part of drawbacks.
Trade-off between the positive vs. negative aspects of these
solutions is left to Service Providers. Each Service Provider will
have to select the appropriate solution (stateless, stateful or even
both) meeting its requirements.
The following table summarizes why stateful approaches shouldn't be
the only solution for conveying IPv4 traffic across IPv6 networks.
The table also aims at showing how stateless approaches can
complement stateful designs.
+----------+-----------+
| Stateful | Stateless |
+--------------------------------------------+----------+-----------+
| Flexible address and port allocation | + | - |
+--------------------------------------------+----------+-----------+
| Preserve IP engineering and operations | - | + |
| practices | | |
+--------------------------------------------+----------+-----------+
6. Conclusion
This document recommends to undertake as soon as possible the
appropriate standardization effort to specify a stateless IPv4 over
IPv6 solution.
7. IANA Considerations
No action is required from IANA.
8. Security Considerations
Except for the less efficient port randomization of Section 4.3 and
Boucadair, et al. Expires November 18, 2011 [Page 12]
Internet-Draft Solution Motivations May 2011
routing loops [I-D.ietf-v6ops-tunnel-loops], stateless 4/6 solutions
are expected to introduce no more security vulnerabilities than
stateful ones. Because of their stateless nature, they may in
addition reduce denial of service opportunities.
9. Contributors
The following individuals have contributed to this document:
Christian Jacquenet
France Telecom
Email: christian.jacquenet@orange-ftgroup.com
Pierre Levis
France Telecom
Email: pierre.levis@orange-ftgroup.com
Masato Yamanishi
SoftBank BB
Email: myamanis@bb.softbank.co.jp
Yuji Yamazaki
Softbank Mobile
Email: yuyamaza@bb.softbank.co.jp
10. Acknowledgments
Many thanks to the following individuals who provided valuable
comments:
+---------------+---------------+---------------+---------------+
| X. Deng | W. Dec | D. Wing | A. Baudot |
| E. Burgey | L. Cittadini | R. Despres | J. Zorz |
| M. Townsley | L. Meillarec | R. Maglione | J. Queiroz |
| C. Xie | | | |
+---------------+---------------+---------------+---------------+
Boucadair, et al. Expires November 18, 2011 [Page 13]
Internet-Draft Solution Motivations May 2011
11. Informative References
[EURESCOM]
Levis, P., Borges, I., Bonness, O. and L. Dillon L., "IPv4
address exhaustion: Issues and Solutions for Service
Providers", March 2010, <http://archive.eurescom.eu/~pub/
deliverables/documents/P1900-series/P1952/D2bis/
P1952-D2bis.pdf>.
[I-D.arkko-ipv6-transition-guidelines]
Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment",
draft-arkko-ipv6-transition-guidelines-14 (work in
progress), December 2010.
[I-D.boucadair-intarea-nat-reveal-analysis]
Boucadair, M., Touch, J., and P. Levis, "Analysis of
Solution Candidates to Reveal the Origin IP Address in
Shared Address Deployments",
draft-boucadair-intarea-nat-reveal-analysis-01 (work in
progress), March 2011.
[I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for IP address sharing
schemes", draft-ietf-behave-lsn-requirements-01 (work in
progress), March 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-v6ops-tunnel-loops]
Nakibly, G. and F. Templin, "Routing Loop Attack using
IPv6 Automatic Tunnels: Problem Statement and Proposed
Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in
progress), May 2011.
[I-D.matsushima-v6ops-transition-experience]
Matsushima, S., Yamazaki, Y., Sun, C., Yamanishi, M., and
J. Jiao, "Use case and consideration experiences of IPv4
to IPv6 transition",
draft-matsushima-v6ops-transition-experience-02 (work in
progress), March 2011.
[I-D.vixie-dnsext-dns0x20]
Boucadair, et al. Expires November 18, 2011 [Page 14]
Internet-Draft Solution Motivations May 2011
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.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
August 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
January 2011.
[UPnP-IGD]
UPnP Forum, "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD) V 2.0", December 2010,
<http://upnp.org/specs/gw/igd2/>.
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Satoru Matsushima
Softbank Telecom
Tokyo
Japan
Email: satoru.matsushima@tm.softbank.co.jp
Yiu Lee
Comcast
US
Email: Yiu_Lee@Cable.Comcast.com
Boucadair, et al. Expires November 18, 2011 [Page 15]
Internet-Draft Solution Motivations May 2011
Olaf Bonness
Deutsche Telekom
Germany
Email: Olaf.Bonness@telekom.de
Isabel Borges
Portugal Telecom
Portugal
Email: Isabel@ptinovacao.pt
Boucadair, et al. Expires November 18, 2011 [Page 16]