Subject: [v4tov6transition] FW: New Version Notification for draft-lee-v4v6tran-problem-01

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 3 Sep 2010 19:01:41 -0400

A new version has been uploaded. It updated the author list and made few
editorial changes.

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-lee-v4v6tran-prob
lem-01.txt

------ Forwarded Message
From: IETF I-D Submission Tool <[email-masked]>
Date: Fri, 3 Sep 2010 15:33:46 -0700
To: Yiu Leung Lee <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>,
<[email-masked]>
Subject: New Version Notification for draft-lee-v4v6tran-problem-01

A new version of I-D, draft-lee-v4v6tran-problem-01.txt has been
successfully submitted by Yiu Lee and posted to the IETF repository.

Filename:  draft-lee-v4v6tran-problem
Revision:  01
Title:   Problem Statements of IPv6 Transition of ISP
Creation_date:  2010-09-04
WG ID:   Independent Submission
Number_of_pages: 11

Abstract:
The IETF has defined a number of technologies and techniques that
targets the transition from IPv4 to IPv6.  Documented techniques
identify high level use cases and generalized options for networks.
Operators may have difficulty attempting to apply the documented
techniques to their networks since each network and system operates
uniquely within the global Internet.  Operators may require guidance
on how to identify the appropriate technology, or technologies, and
apply them to their specific environments.  This memo describes the
problem statements related to the transition of operator's networks
to IPv6.

The IETF Secretariat.

------ End of Forwarded Message

---

From: Fred Baker <[email-masked]>
Date: Sat, 4 Sep 2010 09:07:29 +0900

Thanks.

> 1.  Problem Statement
> 
>    ...IPv4 and IPv6 are not
>    interoperable and the uptake of IPv6 in client and server nodes will
>    be gradual.

One question - given that many client and server nodes already support IPv6, why do you believe that the uptake will be "gradual"? What we observe in many places is that if the network deploys IPv6 connectivity, applications start using them automatically, without the user's knowledge. An example was discussed in v6ops at IETF-74, slides at http://www6.ietf.org/proceedings/74/slides/v6ops-5/v6ops-5_files/v3_document.htm

>    One possible reason is that operators face lags in
>    the IPv6 development in applications, hosts, CPEs, network equipment
>    and contents.  Another possible reason is that operators didn't know
>    how to apply the technologies and techniques in their networks
>    without causing service interruption.

The CPE Router is indeed a problem, including the several CPEs that come from my employer. On much of this other stuff, I am concerned about what we call "FUD" - "Fear, Uncertainty, and Doubt". None of these questions should be taken lightly. On the other hand, many operators have deployed IPv6 in their networks and have done so without the level of concern this document suggests.

Looking through the rest of the document, I find myself wondering if the operators in question have taken advantage of the training opportunities that are available. The EU 6deploy program (http://www.6deploy.eu/), APNIC's training program (http://www.apnic.net/community/ipv6-program/apnic-and-ipv6), and wikis such as Randy pointed us to a few weeks ago or which various folks maintain (example: http://www.getipv6.info/index.php/Educating_Yourself_about_IPv6) give a lot of information on this from other operators that deployed a decade or more ago.

I think my first recommendation to the operational community is to take advantage of the training that is out there and try a trial experiment in their network. I suspect much of this will become clear when they have done this.

One concern that I have here is that we are potentially looking at the trees and missing the forest. The objective is to turn on IPv6; one can do that throughout one's existing IPv4 infrastructure without hurting the IPv4 infrastructure. The objective isn't to figure out how to use every specific coexistence (called "transition", but to be honest they are mostly about not transitioning) technology; it is to figure out how to deploy IPv6 in your networks. If a coexistence technology will help you over a temporary hurdle, so be it. Now, before your customers have done their part, is the time to try this out.

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 8 Sep 2010 23:24:26 -0400

Hi Fred,

Sorry for getting back to you so late. For some reason, I overlooked this
email in my inbox.

> One question - given that many client and server nodes already support IPv6,
> why do you believe that the uptake will be "gradual"? What we observe in many
> places is that if the network deploys IPv6 connectivity, applications start
> using them automatically, without the user's knowledge. An example was
> discussed in v6ops at IETF-74, slides at
> http://www6.ietf.org/proceedings/74/slides/v6ops-5/v6ops-5_files/v3_document.h
> tm
> 
I think this is what we disagree with each other. There are many legacy
equipments which won't talk v6 for some time. I agree that more and more
clients and nodes will support v6, but it will take time. For example:
almost all (except OpenWRT, DD-WRT, etc) HGW today won't do v6. I can't ask
my clients to upgrade their HGW because if you don't do it, you won't have
v6. For them, they don't care running v4, v6 or v8, all they care is whether
they can browse google and facebook, and play Call-of-Duty on their Xbox
360. By observing the market movement so far, I believe the uptake will be
gradual. I am glad to be proven wrong, but I have to see the evidence.

> The objective is to turn on IPv6;
>
I agree with that, but please don't forget the other important objective: To
continue offer v4 services during transition while no more public v4 address
is available.

Cheers,
Yiu

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Sep 2010 17:21:14 +0900

On Sep 9, 2010, at 12:24 PM, Yiu L. Lee wrote:
> I agree with that, but please don't forget the other important objective: To continue offer v4 services during transition while no more public v4 address is available.

I hope I have been clear that keeping your IPv4 business running is something I agree is important for the lifetime of that IPv4-only equipment and software.

The problem is that you really don't have a lot of options in that; there is no magic that this working group or anyone else can provide for you, which is why the IPv6 Forum and others have spent the past decade trying to get companies to prepare themselves for this point. Once you cannot reliably get global IPv4 addresses, you will be forced to use RFC 1918 space within the ISP on paths to customers, who further NAT themselves. Since the edge user's domains use 10.0.0.0/8 and 192.168.0.0/16, but 172.16.0.0/12 is less widely used, 172.16.0.0/12 is your option. You build multiple instances of it, as many as you need, and you NAT those areas to the general Internet.

The effect of that is much like today's IPv4 Internet with NAT around the periphery, but applications work even less well than they do in the single-NAT'd IPv4 of today. I can think of more than one ISP that has built layered NAT domains and has come to me asking me to speak with the RIRs on their behalf, because it is no fun for the ISP and no fun for the customer. As a vendor, I talk with customers that use CGN now. They don't talk about being "on the Internet" as much as they talk about being some number of "hops away from the Internet". IPv4 CGN is not a great service, but it's what exists if you don't have the address space to build out with global addresses.

It's also a lot of effort for you. In essence, it means that you will renumber your network, withdrawing global addresses from customers and deploying private addresses. At some point, you will do so again - and again. It's a lot like running with a stack of plates; you can always handle "just one more on the pile" with a little extra effort, but at some point the cumulative extra effort becomes quite a bit.

I will now refer you to the name of the email alias that Tina set up for this project. It is not [email-masked]; it is [email-masked]. We'll acknowledge and help you with your very real business issues with your IPv4 network to the extent that we can, and we will expect the network operator groups to do the same. But if you don't spend at least as much concern and effort on moving into the IPv6 future, it won't be our networks that are no longer viable businesses, it will be yours. You really can't expect a lot of sympathy for not taking advantage of the available education, or for lack of planning, given how long we have known we were coming to this point.

Speaking as the Chair of the "IPv6 Operations Working Group", I very seriously expect, starting now and from this point forward, that the discussion will not be about "keeping IPv4 running" anywhere near as much as it will be about IPv6 deployment issues, IPv4/IPv6 coexistence issues, and strategizing on moving your network and your customers into the very real IPv6 future. Keeping IPv4 running for a period of time will be among those coexistence issues, but it must take second place to IPv6 deployment and operation of IPv6-only and dual stack networks.

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Sep 2010 18:39:42 +0900

The problem is that you really don't have a lot of options in that; there is no magic that this working group or anyone else can provide for you, which is why the IPv6 Forum and others have spent the past decade trying to get companies to prepare themselves for this point. Once you cannot reliably get global IPv4 addresses, you will be forced to either

(a) use RFC 1918 space within the ISP on paths to customers, who further NAT themselves. Since the edge user's domains use 10.0.0.0/8 and 192.168.0.0/16, but 172.16.0.0/12 is less widely used, 172.16.0.0/12 is your option. You build multiple instances of it, as many as you need, and you NAT those areas to the general Internet - or

(b) deploy an IPv6-only network for a growing portion of your network, translate IPv4 to IPv6 within that domain, and tunnel IPv4 to an IPv4 CGN when crossing that domain, - or

(c) deploy an IPv6-only domain, allow customer IPv6 traffic into that domain, and tunnel IPv4 over the domain to an upstream CGN.

You'll recognize those as topics being discussed in v6ops, softwire, and behave...

The effect of CGN, however accomplished, is much like today's IPv4 Internet with NAT around the periphery, but applications work even less well than they do in the single-NAT'd IPv4 of today. I can think of more than one ISP that has built layered NAT domains and has come to me asking me to speak with the RIRs on their behalf, because it is no fun for the ISP and no fun for the customer. As a vendor, I talk with customers that use CGN now. They don't talk about being "on the Internet" as much as they talk about being some number of "hops away from the Internet". IPv4 CGN is not a great service, but it's what exists if you don't have the address space to build out with global addresses.

It's also a lot of effort for you. In essence, it means that you will renumber your network, withdrawing global addresses from customers and deploying private addresses. At some point, you will do so again - and again. It's like running with a stack of plates; you can always handle "just one more on the pile" with a little extra effort, but at some point the cumulative extra effort becomes quite a bit.

I will now refer you to the name of the email alias that Tina set up for this project. It is not [email-masked]; it is [email-masked]. We'll acknowledge and help you with your very real business issues with your IPv4 network to the extent that we can - we all have them - and we will expect the network operator groups to do the same. But if you don't spend at least as much concern and effort on moving into the IPv6 future, the implications are yours, not ours. You really can't expect a lot of sympathy for not taking advantage of the available education, or for lack of planning, given how long we have known we were coming to this point.

<soapbox>
Speaking as the Chair of the "IPv6 Operations Working Group", I very seriously expect, starting now and from this point forward, that the discussion will not be about "keeping IPv4 running" anywhere near as much as it will be about IPv6 deployment issues, IPv4/IPv6 coexistence issues, and strategizing on moving your network and your customers into the very real IPv6 future. Keeping IPv4 running for a period of time will be among those coexistence issues, but cannot be allowed to dominate the discussion.
</soapbox>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 09 Sep 2010 12:26:50 +0200

B. R.
Tina
http://tinatsou.weebly.com

On Sep 9, 2010, at 10:21 AM, Fred Baker wrote:

>> I agree with that, but please don't forget the other important  
>> objective: To continue offer v4 services during transition while no  
>> more public v4 address is available.
>
> I hope I have been clear that keeping your IPv4 business running is  
> something I agree is important for the lifetime of that IPv4-only  
> equipment and software.
>
> The problem is that you really don't have a lot of options in that;  
> there is no magic that this working group or anyone else can provide  
> for you, which is why the IPv6 Forum and others have spent the past  
> decade trying to get companies to prepare themselves for this point.  
> Once you cannot reliably get global IPv4 addresses, you will be  
> forced to use RFC 1918 space within the ISP on paths to customers,  
> who further NAT themselves. Since the edge user's domains use  
> 10.0.0.0/8 and 192.168.0.0/16, but 172.16.0.0/12 is less widely  
> used, 172.16.0.0/12 is your option. You build multiple instances of  
> it, as many as you need, and you NAT those areas to the general  
> Internet.
>
> The effect of that is much like today's IPv4 Internet with NAT  
> around the periphery, but applications work even less well than they  
> do in the single-NAT'd IPv4 of today. I can think of more than one  
> ISP that has built layered NAT domains and has come to me asking me  
> to speak with the RIRs on their behalf, because it is no fun for the  
> ISP and no fun for the customer. As a vendor, I talk with customers  
> that use CGN now. They don't talk about being "on the Internet" as  
> much as they talk about being some number of "hops away from the  
> Internet". IPv4 CGN is not a great service, but it's what exists if  
> you don't have the address space to build out with global addresses.
>
> It's also a lot of effort for you. In essence, it means that you  
> will renumber your network, withdrawing global addresses from  
> customers and deploying private addresses. At some point, you will  
> do so again - and again. It's a lot like running with a stack of  
> plates; you can always handle "just one more on the pile" with a  
> little extra effort, but at some point the cumulative extra effort  
> becomes quite a bit.
>
> I will now refer you to the name of the email alias that Tina set up  
> for this project. It is not [email-masked]; it is [email-masked] 
> . We'll acknowledge and help you with your very real business issues  
> with your IPv4 network to the extent that we can, and we will expect  
> the network operator groups to do the same. But if you don't spend  
> at least as much concern and effort on moving into the IPv6 future,  
> it won't be our networks that are no longer viable businesses, it  
> will be yours. You really can't expect a lot of sympathy for not  
> taking advantage of the available education, or for lack of  
> planning, given how long we have known we were coming to this point.
>
> Speaking as the Chair of the "IPv6 Operations Working Group", I very  
> seriously expect, starting now and from this point forward, that the  
> discussion will not be about "keeping IPv4 running" anywhere near as  
> much as it will be about IPv6 deployment issues, IPv4/IPv6  
> coexistence issues, and strategizing on moving your network and your  
> customers into the very real IPv6 future. Keeping IPv4 running for a  
> period of time will be among those coexistence issues, but it must  
> take second place to IPv6 deployment and operation of IPv6-only and  
> dual stack networks.
You are right. I completely understand your original intention.

However, some operators would like to focus on operational issues  
related to the final phases of transition of v4 networks to v6. i.e.  
the protection of v4 applications that need to continue to be  
operational for all users while the networks are gradually  
transitioned from v4 to v6. That's why Can-Can and Remi suggested a  
separate WG.

> _______________________________________________
> v4tov6transition mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v4tov6transition

---

From: "David Harrington" <[email-masked]>
Date: Thu, 9 Sep 2010 16:40:35 -0400

+1

actually I feel quite strongly about this not being about keeping
ipv4. 
Can I say +6?

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Thursday, September 09, 2010 4:21 AM
> To: Yiu L. Lee
> Cc: IPv6 v6ops; [email-masked]
> Subject: Re: [v4tov6transition] FW: New Version Notification 
> fordraft-lee-v4v6tran-problem-01
> 
> > I agree with that, but please don't forget the other 
> important objective: To continue offer v4 services during 
> transition while no more public v4 address is available.
> 
> I hope I have been clear that keeping your IPv4 business 
> running is something I agree is important for the lifetime of 
> that IPv4-only equipment and software.
> 
> The problem is that you really don't have a lot of options in 
> that; there is no magic that this working group or anyone 
> else can provide for you, which is why the IPv6 Forum and 
> others have spent the past decade trying to get companies to 
> prepare themselves for this point. Once you cannot reliably 
> get global IPv4 addresses, you will be forced to use RFC 1918 
> space within the ISP on paths to customers, who further NAT 
> themselves. Since the edge user's domains use 10.0.0.0/8 and 
> 192.168.0.0/16, but 172.16.0.0/12 is less widely used, 
> 172.16.0.0/12 is your option. You build multiple instances of 
> it, as many as you need, and you NAT those areas to the 
> general Internet.
> 
> The effect of that is much like today's IPv4 Internet with 
> NAT around the periphery, but applications work even less 
> well than they do in the single-NAT'd IPv4 of today. I can 
> think of more than one ISP that has built layered NAT domains 
> and has come to me asking me to speak with the RIRs on their 
> behalf, because it is no fun for the ISP and no fun for the 
> customer. As a vendor, I talk with customers that use CGN 
> now. They don't talk about being "on the Internet" as much as 
> they talk about being some number of "hops away from the 
> Internet". IPv4 CGN is not a great service, but it's what 
> exists if you don't have the address space to build out with 
> global addresses.
> 
> It's also a lot of effort for you. In essence, it means that 
> you will renumber your network, withdrawing global addresses 
> from customers and deploying private addresses. At some 
> point, you will do so again - and again. It's a lot like 
> running with a stack of plates; you can always handle "just 
> one more on the pile" with a little extra effort, but at some 
> point the cumulative extra effort becomes quite a bit.
> 
> I will now refer you to the name of the email alias that Tina 
> set up for this project. It is not [email-masked]; it 
> is [email-masked]. We'll acknowledge and help you 
> with your very real business issues with your IPv4 network to 
> the extent that we can, and we will expect the network 
> operator groups to do the same. But if you don't spend at 
> least as much concern and effort on moving into the IPv6 
> future, it won't be our networks that are no longer viable 
> businesses, it will be yours. You really can't expect a lot 
> of sympathy for not taking advantage of the available 
> education, or for lack of planning, given how long we have 
> known we were coming to this point.
> 
> Speaking as the Chair of the "IPv6 Operations Working Group", 
> I very seriously expect, starting now and from this point 
> forward, that the discussion will not be about "keeping IPv4 
> running" anywhere near as much as it will be about IPv6 
> deployment issues, IPv4/IPv6 coexistence issues, and 
> strategizing on moving your network and your customers into 
> the very real IPv6 future. Keeping IPv4 running for a period 
> of time will be among those coexistence issues, but it must 
> take second place to IPv6 deployment and operation of 
> IPv6-only and dual stack networks.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 09 Sep 2010 22:58:21 +0200

It is not keeping IPv4.
It is the protection of v4 applications that need to continue to be  
operational for all users while the networks are gradually  
transitioned from v4 to v6.

B. R.
Tina

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 17 Sep 2010 08:01:42 -0700

> It is not keeping IPv4. 

I don't want to belabor this anymore than necessary, but I think it's
only fair to point out that the legacy application isn't going to change.

> operational for all users while the networks are gradually transitioned
> from v4 to v6.  

And those v4 only applications will need to talk to their v4 only
endpoints, so whatever assumptions you make about the particular
application in use, the assumption on the part of two v4 hosts is that
there is v4 network between them, whether that's accomplished through
the existence of a v4 network or slight-of-hand isn't entirely germain.

there will be a time where these applications age out of the network
(e.g. becuase they're effectivly unusable, they've but updated, or the
users have moved on), but in the mean-time you are in fact providing
ipv4 service.

>>> <mailto:[email-masked]>
>>> <mailto:[email-masked]>
>>> Subject: Re: [v4 tov6tran otification
>>> running is something I agree is important fo r the li e>
>>>> 192.168.0.0/16, but 172.16.0.0/12 is less uote>
>>>> set up for this project. It is not [email-masked]
>>>> <mailto:[email-masked]>; it
>>>> is [email-masked] <mailto:[email-masked]>.
>>>> We'll acknowledge and help you
>>>> < ture, it won't be our networks that are no longer viable
>>> [email-masked] <mailto:[email-masked]>
>> v4tov6transition mailing l ist
>> < [email-masked]">[email-masked]
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Tina TSOU <[email-masked]>
Date: Sun, 19 Sep 2010 15:43:31 +0800

Hi Joel,

You are right; I completely understand your original intention.

Another perspective:

For some operators, what they hope from the transition guide is below.

Based on their network situation and service development situation 
(Currently broadband users are growing at high speed, the other service is 
also developing, which is different with the situation in the other 
operators), what technologies, how to transit to IPv6 smoothly. For these 
operators, in the transition process they need to pay more attention to how 
to develop the existing service; this is different with the broadband users 
in saturation for other operators.

For IP address lacking issues, different operators face the problem in 
different levels. For some operators who have broadband users growing at 
high speed, they face the lacking IP address issues seriously more than the 
other operators, may deploy IPv6 earlier. Since there is no service and/or 
application which have to use IPv6 to develop, before the IPv4 address 
depletion completely, the broadband users for these operators are basically 
IPv4 only user, therefore the surrounding industry train will support the 
IPv6 later than the ISP introduces IPv6.

Just 2 cents (=0.14CNY).

B. R.
Tina
----- Original Message ----- 
From: "Joel Jaeggli" <[email-masked]>
To: "Tina TSOU" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; "Yiu L. Lee" <[email-masked]>
Sent: Friday, September 17, 2010 11:01 PM
Subject: Re: [v6ops] [v4tov6transition] FW: New Version Notification 
fordraft-lee-v4v6tran-problem-01