Network Working Group J. Xu
Internet Draft China Telecom
Intended status: Informational S. Jiang
Expires: October 8, 2009 Huawei Technologies Co., Ltd
April 14, 2009
A Hybrid ISP Platform (or Architecture) for IPv6: Problem Statement
draft-xu-v6ops-hybrid-platform-ps-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 12, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Xu, et al. Expires October 12, 2009 [Page 1]
Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009
Abstract
Global IPv6 deployment is inevitable. There are many solutions have
been specified in order to provide IPv6 connectivity services. In
order to provide IPv6 connectivity services to all kinds of
host/client devices, ISP networks need to support as many as possible
IPv6 connectivity solutions. This document proposes a hybrid ISP
platform that supports the coexistence of variable IPv6 connectivity
solutions and analyses the configuration requirements raised by this
platform. Additionally, the applicability of different configuration
mechanisms for performing this configuration is discussed.
Table of Contents
1. Introduction................................................3
2. Overview of A Hybrid ISP Platform.............................4
3. Configuration Mechanisms.....................................5
3.1. Manual configuration....................................5
3.2. DHCPv6.................................................6
3.3. Domain Name Service.....................................6
3.4. Others.................................................6
4. Security Considerations......................................6
5. IANA Considerations.........................................6
6. References..................................................6
6.1. Normative References....................................6
6.2. Informative References..................................7
Author's Addresses.............................................8
Xu, et al. Expires October 12, 2009 [Page 2]
Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009
1. Introduction
Global Internet has grown up rapidly in last 25 years. More and more
devices are linked on the Internet. Internet Protocol (version 4
[RFC791]) plays an important role during the success of the Internet.
IPv4 addresses identify the logic location of every device in the
Internet so that data packets can be delivered to the right
destination. However, giving the fact that the length of IPv4
addresses is only 32 bits, there is only less that 4 billion
available IPv4 address. IPv4 address exhaustion is now confirmed to
happen soon. The dynamically-updated IPv4 Address Report [IPUSAGE]
has analyzed this issue. It predicts early 2011 for IANA unallocated
address pool exhaustion and middle 2012 for RIR unallocated address
pool exhaustion.
Although there are a number of mechanisms trying to extend the life
time of IPv4, the transition of the Internet to Internet Protocol
version 6 [RFC2460] is the only practical and readily available long-
term solution to IPv4 address exhaustion. The Internet industry
appears to have reached consensus that global IPv6 deployment is
inevitable and has to be done quite quickly. IPv4/IPv6 transition,
including intercommunication between IPv4 and IPv6, therefore becomes
more critical and complicated for the soon-coming global IPv6
deployment.
On another side, there are many solutions have been specified in
order to provide IPv6 connectivity services, include 6over4 [RFC3056],
6to4 [RFC3056], ISATAP (Intra-Site Automatic Tunnel Addressing
Protocol [RFC5214]), NAT-PT [RFC2663] (though NAT-PT has been
obsoleted [RFC4966], NAT-PT-like technologies, for example NAT64
[NAT64], are still needed), SIIT (Stateless IP/ICMP Translation
Algorithm [RFC2765]), BIS (Dual Stack Hosts using the Bump-In-the-
Stack Technique [RFC2767]), Transport Replay Translator [RFC3142],
Socks 64 Gateway [RFC3089], BIA (Dual Stack Hosts Using Bump-in-the-
API [RFC3338]), etc. Each of them has different service scenarios and
needs both Internet Service Provider (ISP) networks and host/client
devices to support them at the same time. Furthermore, in the IPv6
global deployment, more issues or different scenarios may occur.
Correspondently, more solutions may be developed to meet certain
requirements in the future. 6RD (IPv6 Rapid Deployment [6RD]), Dual-
Stack Lite [DSLite] and Incremental CGN [ICGN], TURN (Traversal Using
Relays around NAT [TURN]) has been submitted to IETF.
Up to now, there is not AN universal mechanism that can meet all IPv6
connectivity service scenarios, including connectivity between IPv6-
only and IPv4-only, see table 1. Host/client devices may choose to
Xu, et al. Expires October 12, 2009 [Page 3]
Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009
support one or more certain solutions. But host/client devices with
variable solution all require IPv6 connectivity through ISP network
services. In order to provide IPv6 connectivity services to all kinds
of host/client devices, ISP networks need to support as many as
possible IPv6 connectivity solutions. Additionally beside
availability, all these efforts should be transparent for end-user.
+------------------------------------------------------------+
| |6o4|6to4| ISA |NAT|SIIT|BIS|Trans.|SOCKS|BIA|
| | | |-TAP |-PT| | |Relay | G/W | |
|---------------+---+----+-----+---+----+---+------+-----+---|
|Dual Stack Host| X | | X | | | X | | | X |
|---------------+---+----+-----+---+----+---+------+-----+---|
| Upper Message | | | | | | | X | X | X |
| Manipulation | | | | | | | | | |
|---------------+---+----+-----+---+----+---+------+-----+---|
| IP Header | | | | X | X | X | | | |
| Translation | | | | | | | | | |
|---------------+---+----+-----+---+----+---+------+-----+---|
| Tunneling | X | X | X | | | | | | |
|---------------+---+----+-----+---+----+---+------+-----+---|
| In Host | X | | X | | | X | X | X | X |
|---------------+---+----+-----+---+----+---+------+-----+---|
| In Gate | | X | | X | | | X | X | |
|---------------+---+----+-----+---+----+---+------+-----+---|
| Consider APPs.| | | | | | | | | X |
+------------------------------------------------------------+
Table 1: Characters of IPv6 connectivity mechanisms
This document proposes a hybrid ISP platform that supports the
coexistence of multiple IPv6 connectivity solutions and analyses the
configuration requirements raised by this platform. Additionally, the
applicability of different configuration mechanisms for performing
this configuration is discussed.
2. Overview of A Hybrid ISP Platform
The proposed hybrid ISP platform supports the co-existence of hybrid
IPv6 connectivity and IPv6/IPv4 intercommunication solutions. It
encourages that ISPs work together with Internet Content Providers
(ICPs) to provide IPv6 connectivity and IPv6/IPv4 intercommunication
services. ISPs provide as much as possible generic support. ICPs can
design and implement their application specific traverse mechanisms
utilizing ISP's generic services.
Xu, et al. Expires October 12, 2009 [Page 4]
Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009
First, ISP deploys required devices for IPv6 connectivity and
IPv6/IPv4 intercommunication solutions in its ISP networks. Depending
on each solution, the required devices may be located at different
positions. For example, IPv6/IPv4 intercommunication devices should
be placed at the edge between IPv4/IPv6 networks. CGNs may be
deployed according to the ISP customer aggregation strategy.
Application-specific gateways for IPv6/IPv4 intercommunication may be
deployed as services by ICP within ISP network too. Each application
may have their customized traversal mechanisms and servers.
All information of deployed services, including IP addresses of
devices, needs to be collected and distributed to ISP access devices,
such as BRAS. Through standard protocols, which need to be extended
based on existing DHCPv6, PPPoEv6 or other protocols, ISP access
devices propagate the availability information to the host/client
devices.
The operation system on the host/client devices may filter IPv6
connectivity services according to its own supporting status. The OS
should provide standard IPv6 connectivity invoking interface for the
upper layer applications, for example, GetSocks64Address, GetNAT-
PTAddress.
Based on the availability, applications can choose the IPv6
connectivity services accordingly.
This hybrid ISP platform provides the maximum IPv6 connectivity
support for all different solutions.
In order to fulfil this hybrid ISP platform, there are two technical
gaps needs to be supplied: configuration mechanisms in which service
information could be pushed to the host/client devices; standard IPv6
connectivity invoking interface on the hosts/client devices. The
latter is out of scope of this document. The configuration mechanism
is discussed below.
3. Configuration Mechanisms
There are a number of configuration mechanisms that could be
potentially used to propagate IPv6 connectivity service information
to the host/client devices.
3.1. Manual configuration
Manual configuration has already been used in many IPv6 connectivity
solutions. However, this method requires expert knowledge for at
least first time configuration. Its scalability is quite poor.
Xu, et al. Expires October 12, 2009 [Page 5]
Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009
Furthermore, this mechanism is lack of flexibility. For example, the
connectivity service will become unavailable after a server changes
its IP address.
3.2. DHCPv6
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can
assign addresses statefully. Besides, DHCPv6 can also be used to
distribute other configuration information. DHCPv6 can be extended to
propagate IPv6 connectivity service information. A set of new options
needs to be developed and their interaction behaviour need to be
defined clearly.
3.3. Domain Name Service
For well-known services, certain DNS records may be defined so that
host/client devices can resolve their IP address through DNS query.
For example, natpt.chinatelecom.com.cn can be used to point all China
Telecom customers to available NATPT servers. With intelligence DNS
mechanism, client requirements can be diverted to a suitable server
among many available servers.
3.4. Others
According to different access technologies, certain protocol, such as
PPPOE or ICMP may be extended to propagate IPv6 connectivity service
information.
4. Security Considerations
The security issues for each solution that provides IPv6 connectivity
services are out of scope. However, further security analysis will be
needed to understand whether there are security issues for
configuration mechanisms mentioned in this document.
5. IANA Considerations
This draft does not request any IANA action.
6. References
6.1. Normative References
[RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981.
[RFC2460] S. Deering, et al., "Internet Protocol, Version 6 (IPv6)
Specification", RFC2460, December 1998.
Xu, et al. Expires October 12, 2009 [Page 6]
Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009
[RFC2765] E. Nordmark, "Stateless IP/ICMP Translation Algorithm (SIIT)
", RFC 2765, February 2000.
[RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
IPv6", RFC3315, July 2003.
6.2. Informative References
[RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999.
[RFC2767] K. Tsuchiya, et al., "Dual Stack Hosts using the Bump-In-
the-Stack Technique (BIS)", RFC 2767, February 2000.
[RFC3089] H. Kitamura, "A SOCKS-based IPv6/IPv4 Gateway Mechanism,
RFC3089", April 2001.
[RFC3142] J. Hagino, "An IPv6-to-IPv4 Transport Relay Translator" RFC
3142, June 2001.
[RFC3338] S. Lee, et al., "Dual Stack Hosts Using Bump-in-the-API
(BIA)", RFC 3338 October 2002
[RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address
Translator - Protocol Translator (NAT-PT) to Historic
Status", RFC 4966, July 2007.
[RFC5214] F. Templin, T. Gleeson, and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[IPUSAGE] G. Huston, IPv4 Address Report, March 2009,
http://www.potaroo.net/tools/ipv4/index.html.
[6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures
(6rd)", draft-despres-6rd-03.txt, working in progress,
April 2009.
[DSLite] A. Durand, et al., "Dual-stack lite broadband deployments
post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-
00.txt, working in progress, March 2009.
Xu, et al. Expires October 12, 2009 [Page 7]
Internet-Draft draft-xu-v6ops-hybrid-platform-ps-00.txt April 2009
[ICGN] S. Jiang, et al., "An Incremental Carrier-Grade NAT (CGN)
for IPv6 Transition" draft-jiang-incremental-cgn-00.txt,
working in progress, March 2009.
[NAT64] M. Bagnulo, et al., "NAT64: Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers", draft-
bagnulo-behave-nat64-03.txt, work in progress, March 2009.
[TURN] G. Camarillo and O.Novo, "Traversal Using Relays around NAT
(TURN) Extension for IPv6", draft-ietf-behave-turn-ipv6-
06.txt, working in progress, March 2009.
Author's Addresses
Jianfeng Xu
China Telecom
No.109, West Zhongshan Street, Tian-He District, Guangzhou 510630
P.R. China
Phone: 86-20-38639112
EMail: xujf@gsta.com
Sheng Jiang
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-82836774
EMail: shengjiang@huawei.com
Xu, et al. Expires October 12, 2009 [Page 8]