One document matched: draft-yang-v6ops-fast6-tools-selection-00.txt
Internet Engineering Task Force G. Yang
Internet-Draft C. Huang
Intended status: Informational Y. Wu
Expires: November 24, 2011 China Telecom
May 23, 2011
The analysis of tools selection for broadband ISP
draft-yang-v6ops-fast6-tools-selection-00
Abstract
NAT444, DS-LITE, 6RD and other transition technologies have been well
done, the ISP should select the most suitable tool to meet the
requirements of a typical broadband access network in the real world
regarding its network architecture, operation situation and
transition goals, etc.
According to the mainstream broadband access network, this draft
focuses on analyzing the problems that may be encountered when using
various transitional technologies during the transition and finally
introduces a more systematic and operational proposal.
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 November 24, 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
Yang, et al. Expires November 24, 2011 [Page 1]
Internet-Draft FAST6-tools selection May 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Brief Description of ISP's Broadband Network . . . . . . . . . 3
5. Transition Principles . . . . . . . . . . . . . . . . . . . . 4
6. Technologies Selection . . . . . . . . . . . . . . . . . . . . 4
6.1. Goal Consistency . . . . . . . . . . . . . . . . . . . . . 5
6.2. Application Continuity . . . . . . . . . . . . . . . . . . 5
6.3. User Habit . . . . . . . . . . . . . . . . . . . . . . . . 5
6.4. Network Scalability . . . . . . . . . . . . . . . . . . . 6
7. DS-lite & NAT444 . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Deployment differences . . . . . . . . . . . . . . . . . . 6
7.2. CPE diversity . . . . . . . . . . . . . . . . . . . . . . 7
7.3. Cost Difference . . . . . . . . . . . . . . . . . . . . . 7
7.4. O&M Diversity . . . . . . . . . . . . . . . . . . . . . . 7
7.5. Supporting system Differences . . . . . . . . . . . . . . 8
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Yang, et al. Expires November 24, 2011 [Page 2]
Internet-Draft FAST6-tools selection May 2011
1. Introduction
Various transition tools have been proposed and well optimized.The
ISP should select most suitable tools to meet the requirements of a
mainstream broadband access network in the real world regarding its
network architecture, operation situation and transition goals, etc.
To satisfy the typical broadband access network, which provides
subscribers internet service through PPPOE via L2 access network,
this draft filters numbers of transition technologies basing on
specific principles. Then, a detailed comparison is made between
native dual-stack and tunnels, represented by NAT444 and DS-lite
respectively. It is concluded that native dual-stack is more
appropriate than tunnels for this specific network. At last, this
draft points out some problems that NAT444 are not designed to solve
during each period of transition and refers to a more systematic and
operational proposal.
2. 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].
3. Terminologies
To be continued.
4. Brief Description of ISP's Broadband Network
At the present stage, there are two major service models: PPPoE and
IPoE for operators to provide broadband access service to the
subscriber. In some scenes, PPPoE offers better security and control
functions for the home user than IPoE, and relatively more suitable
for broadband service. But IPoE is more appropriate for multicast
services. For broadband access network, it's reasonable to believe
that PPPoE is much more popular than the other one. So, it is urgent
to do some research on this typical broadband access model.
Broadband access network which uses PPPoE technology also has
following characteristics:
o L2 access network;
o Bridged mode or routed mode CPE are both permitted for users;
Yang, et al. Expires November 24, 2011 [Page 3]
Internet-Draft FAST6-tools selection May 2011
o Large number of existing users, it grows rapidly and IPv4 address
depletion has a direct impact on services;
o Due to large network, there is enormous number of network devices
and part of them cannot support IPv6 in the future. Although this
kind of equipment will be replaced partially , this situation will
last for a long period. That means in current network, there will
be a number of equipments that are unable to be updated to support
IPv6.
The new ISP can achieve the goal in one leap through building a new
network. However, for some old brand ISPs with heavy load on
transition for their large number of subscribers and diverse
situation of the legacy devices, choosing an appropriate transition
strategy is a key point for development, and has a great impact in
the future.
5. Transition Principles
The ISP requirement for IPv6 transition is depend on ISP's role. As
a company, making profit is the most important goal of ISP.
Therefore, for example, when the network is transiting to IPv6, a
more mature and stable technology is more applicable to be chosen
than a newer, more creative and greener one. ISP is also different
from equipment manufacturers for they pursuit a balance between user
experience and investment. For instance, when make an IPv6
transition route, a conservative one maybe more popular than an
aggressive one.
From the perspective of an ISP, principles of network migration are
concluded as follows:
o Ensure user experience.;
o Save cost;
o Reduce technical risks;
o Convenient operation and maintenance.
o Security supervision.
6. Technologies Selection
Now there are two solutions for IPv4 address depletion: using private
IPv4 (RFC1918) and IPv6. For private IPv4, there are two transition
Yang, et al. Expires November 24, 2011 [Page 4]
Internet-Draft FAST6-tools selection May 2011
technologies: A+P and NAT. For IPv6, there are two types of
transition mechanisms, the first type is dual-stack, including 6RD,
NAT444, DS-LITE, etc., and the second type is native IPv6, including
PNAT, 1:N IVI, NAT64, etc,.
This chapter would describe the transitional problems related to the
existing transitional technologies, under the principles of technical
choice, and considering the current situation of broadband access
network.
6.1. Goal Consistency
In the short term, to permit the network to continue to grow, a
series of tools are developed. These tools include more efficient
use of the IPv4 address resource, conservation, and the sharing of
IPv4 addresses through the use of NAT. While these provide partial
mitigation for IPv4 exhaustion, they are not a long-term solution,
increase network costs, and merely postpone some of the consequences
of address exhaustion without solving the underlying problem. Some
of these fixes break end-to-end connectivity, impairing innovation
and hampering applications, degrading network performance, and
resulting in an inferior version of the Internet. Network operators
will be confronted with increased costs to offer potentially inferior
service.
The short term solution is problematic. The "solution to the
solution" is to complete the transition to the native IPv6 network.
So, using NAT and A+P can obstruct the development of IPv6, and it's
inconsistent with the goal of the Next Generation Internet.
6.2. Application Continuity
There are lots of applications that don't support IPv6, and many are
not workable in native IPv6 network. Some other applications, such
as VoIP, IM, P2P, etc,couldn't traverse through NAT64 or 1:N IVI.
Besides, at the beginning of transition, there are still lots of IPv4
resources, which don't support IPv6 yet. Using a native IPv6
solution will have a great impact on the customers, so it can only be
used in a specific scenario or in the later transitional period.
Therefore, the terminal can't directly be pure IPv6, unless it is a
special set-top box or mobile phone. In other words, the pure IPv6
solution is not suitable for the continuity of existing applications.
6.3. User Habit
ISP should not force customers to install application in their
terminals. First of all, users reject installing software
mandatorily. In addition, there is no clear management boundary for
Yang, et al. Expires November 24, 2011 [Page 5]
Internet-Draft FAST6-tools selection May 2011
mandatory software installation. ISP has the right to manage user
software or not is questionable. So the terminal software for PNAT,
DS-LITE is not suitable.
6.4. Network Scalability
With the continually increasing number of subscribers, the network
scale will correspondingly expand. 6RD cannot meet the requirements
of the network when their trends are native IPv6 or dual-stack, since
it is only applicable in native IPv4 network.
In summary, considering the fitness of the long term goal of
Internet, the continuity of applications, end user application habits
and network scalability, and according to this specific broadband
network scenario, the native IPv4, native IPv6 and part of the dual-
stack transition skills are not proper to be deployed. It seems like
that NAT444 and DS-lite are more applicable to choose.
7. DS-lite & NAT444
Both DS-lite and NAT444 are belonging to dual-stack tools and they
are different in technology maturity, equipment maturity and
applicable scenarios. NAT444 is composed of mature tools while DS-
lite is a green technology and has a long way to be a standard. In
addition, NAT has existed for many years in firewall while DS-lite is
only on its way of trial with no large-scale commercial deployment
cases. NAT444 and DS-lite are the same in consuming IPv4 address
number, and they are all supported by current mainstream Internet
applications.
Which is more suitable for this typical broadband network? The
detailed analysis is as below:
7.1. Deployment differences
The difficulties of switchover and deployment for NAT444 and DS-LITE
are basically the same. However, NAT444 is much more flexible in
deployment for it can be allocated either in distributed way or
centralized way. In comparison, DS-lite prefers centralized
deployment because the distributed way is meaningless for the
specific scenario. The reason is that if AFTR is distributed besides
the BNG, there is no native IPv6 network for DS-lite to show its
advantages, since in this typical broadband network scenario, the
access network is composed of L2 equipments which are unaware of
IPv6. In addition, at present, the native IPv6 network has not been
tested for a long time enough, there is a considerably high risk for
the operators to carry the most important service traffic over it.
Yang, et al. Expires November 24, 2011 [Page 6]
Internet-Draft FAST6-tools selection May 2011
In conclusion, in the initial period of transition, it is not proper
to use DS-lite for the large quantity of IPv4 traffic.
7.2. CPE diversity
Currently, most CPEs are in bridged-mode and they have already
supported NAT444. The newly developed CPEs are baring dual-stack and
consequently support NAT444. When the legacy CPE are used to deploy
NAT444, the running IPv4 services will not be impacted.
However, if the CPE is transformed to support DS-lite, despite the
NAT444 function, the tunnel function should also be incorporated.
The CPEs can not access the current IPv4 services if they are not
replaced with an updated one when DS-lite is deployed.
In conclusion, NAT444 can not only continue the existing terminal
strategies but also keep the existing service model unchanged when
using routed or bridged CPE to support PPPOE accessing. In contrast,
DS-lite cannot easily be socialized for its customized routed-model
CPE.
7.3. Cost Difference
Considering the network cost aspect, NAT444 has very little
difference from DS-lite.
From the perspective of terminal, DS-lite costs slightly higher than
NAT444GBP"because it should support DS-lite despite of dual-
stackGBP(C)for the new subscribers. For the legacy ones, if they use
NAT444, they have no need to replace the bridged-mode CPE and the
routed-mode CPE only need to support IPv6. It is very easy for
NAT444 to socialize and lower the operation cost. In contrast, the
DS-lite technology is not mature,it will impact existing IPv4 service
once they are running abnormally and consequently cause the lost of
customers. DS-lite has larger risk in cost.
In terms of operation, NAT444 can follow the traditional operation
method with low cost while DS-lite has high risk on cost for changing
the original operation way.
7.4. O&M Diversity
From trouble shooting aspect, NAT444 can easily locate the errors
happen in IPv4 and IPv6 separately. In contrast, it is difficult to
detect the troubles of IPv4 since IPv4 is encapsulated in IPv6 tunnel
in DS-lite.
In terms of reliability, logically speaking, IPv6 and IPv4 are ships
Yang, et al. Expires November 24, 2011 [Page 7]
Internet-Draft FAST6-tools selection May 2011
in the night and IPv6 error won't influence the stability of IPv4
directly in NAT444. Otherwise, the troubles happened in IPv6 will
affect the IPv4 running in DS-lite.
As for the aspect of forwarding efficiency, enabling IPv6 has little
influence in NAT444. However, in DS-lite, all this traffic must be
tunneled,encapsulated and decapsulated, so it will cut down the
forwarding efficiency.
Considering from the operational staff training aspect, it is not
very difficult to train the NAT skilled staff to operate NAT444 and
people have enough time to be familiar with NAT444. In contrast, the
training on DS-lite should be finished before the deployment. The
time is too short for the people to be fully trained.
7.5. Supporting system Differences
In the term of DNS, NAT444 and DS-lite are almost the same.
Considering the accounting, the workload of NAT444 is twice as the
DS-lite and the accounting logic is much more complicated than DS-
lite. Both of them ask for much higher performance requirement for
NAT444 DNS. But basically they have the same customer management and
tracing system which need to trace IPv6 and IPv4 separately and to
save the record of address translation respectively.
Since NAT444 and DS-lite have different requirements for support
system, it is not proper to deploy both of these two transition tools
in the same time and in the same region.
The comparisons of NAT444 and Ds-lite are summarized as follows:
Regarding the impact on customers, both of them can support IPv4
Internet application and have tiny influences to the user' IPv4
application.
From the point of cost controlling, the DS-lite costs a little higher
than NAT444 for a single terminal. However, when DS-lite is deployed
in large-scale, the cost of terminals will be highly raised.
Speaking of technique risk, the NAT444 is much mature than DS-lite
and won't impact the IPv4 service. DS-lite is a new tool for
transition and its future trend is not very clear, so operator will
take higher risk in the early stage of transition. Meanwhile, using
tunnel makes DS-lite increase the difficulties of operation and
maintenance, leading performance bottleneck in the initial period
which will decline the network performance and customer experience
and correspondingly heighten the deployment risk.
Yang, et al. Expires November 24, 2011 [Page 8]
Internet-Draft FAST6-tools selection May 2011
Technically speaking, NAT444 and DS-LITE are no matter which is
better and which is worse, they are simply different from the period
of deploying, network scenarios and service model. And because of
the different requirements for network,support system and terminals,
it is not recommended to use both of these two transition tools in
the same time and the same region.
As we analyzed in the above paragraph, NAT444 is more suitable to be
used in the whole transition period while DS-lite is proper for the
latter period of transition with small number of IPv4 subscribers.
8. Conclusion
For the mainstream ISP, native dual stack is more appropriate
compared to dual stack tunnel. Although NAT444 makes a balance
between guaranteeing the customer experience and promoting the
development of IPv6. However, it is not a comprehensive solution for
broadband network. For example, how to provide the IPv6 service to
legacy subscribers, if their default network gateway(BNG) cannot be
upgraded to support IPv6 and consequently unable to allocate IPv6
address to the customers, is not mentioned in NAT444. In addition,
the emergence of mixed routes (private and public IPv4 route) may
bring operators great difficulties to manage the routes, how to solve
this problem is not taken account in NAT444. Above there are just
two exampled problems that NAT444 doesn't design to solve. In
conclusion, as a transition technology, NAT444 has the weakness of
one-sided consideration about the transition scenarios and doesn't
give a complete solution for each period of IPv6 migration. To meet
the ISP's requirement, which needs a more systematic and operational
technologies, FAST6, a comprehensive solution based on native dual
stack is proposed and its detail is described in
I.D:draft-yang-v6ops-fast6-pppoe-00.
9. Acknowledgements
The authors would like to acknowledge the discussions on this topic
with Yangchun Li, Youming Wu, Jinhua Tan, Jinyan Lin, Qi Chen.
10. IANA Considerations
This memo includes no request to IANA.
Yang, et al. Expires November 24, 2011 [Page 9]
Internet-Draft FAST6-tools selection May 2011
11. Security Considerations
TBD.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006.
12.2. Informative References
[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.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-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-10 (work
in progress), May 2011.
[I-D.kuarsingh-lsn-deployment]
Kuarsingh, V. and J. Cianfarani, "NAT44/LSN Deployment
Options and Experiences",
draft-kuarsingh-lsn-deployment-01 (work in progress),
January 2011.
[I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
in progress), January 2011.
[I-D.shirasaki-nat444-isp-shared-addr]
Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444 addressing models",
Yang, et al. Expires November 24, 2011 [Page 10]
Internet-Draft FAST6-tools selection May 2011
draft-shirasaki-nat444-isp-shared-addr-05 (work in
progress), January 2011.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into
ISP Networks", RFC 4029, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4241] Shirasaki, Y., Miyakawa, S., Yamasaki, T., and A.
Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet
Access Service", RFC 4241, December 2005.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider
Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[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.
Yang, et al. Expires November 24, 2011 [Page 11]
Internet-Draft FAST6-tools selection May 2011
Authors' Addresses
GuoLiang Yang
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: yanggl@gsta.com
CanCan Huang
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: huangcc@gsta.com
YouMing
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: Wuym@gsta.com
Yang, et al. Expires November 24, 2011 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 01:11:01 |