Subject: Re: [v6ops] [v4tov6transition] FW: New Version Notification fordraft-lee-v4v6tran-problem-01

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
http://tinatsou.weebly.com

On Sep 9, 2010, at 10:40 PM, David Harrington wrote:

> +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
>>
>> On Sep 9, 2010, at 12:24 PM, Yiu L. Lee wrote:
>>>> 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.
>>
>> 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.
>> _______________________________________________
>> v4tov6transition mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>
>
> _______________________________________________
> v4tov6transition mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v4tov6transition

---

From: "David Harrington" <[email-masked]>
Date: Sat, 11 Sep 2010 21:25:03 +0000

<[email-masked]>
Subject: RE: [v4tov6transition] FW: New Version Notification
fordraft-lee-v4v6tran-problem-01
Date: Thu, 9 Sep 2010 16:40:35 -0400
Message-ID: <C7F5DB277EC04D64A613D611E450076B@23FX1C1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[email-masked]>
Thread-Index: ActQAfvOsal3v+W1TBi4a0jfyjmvKgAXQ+iA
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
Sender: [email-masked]
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

+1

dbh

---

From: Tina TSOU <[email-masked]>
Date: Sat, 11 Sep 2010 21:24:40 +0000

<[email-masked]>,
 [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.936)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_g0pUgEuZXQWallHIU+GQ9Q)"
References: <[email-masked]>
 <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

--Boundary_(ID_g0pUgEuZXQWallHIU+GQ9Q)
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-transfer-encoding: 7BIT

B. R.
Tina

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.

--Boundary_(ID_g0pUgEuZXQWallHIU+GQ9Q)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div =
apple-content-edited=3D"true"> <span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: medium; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: medium; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div><span class=3D"Apple-style-span" =
style=3D"font-size: 12px; "><div>B. R.</div><div>Tina</div><div><a =
href=3D"http://tinatsou.weebly.com">http://tinatsou.weebly.com</a></div><d=
iv></div></span></div><div><br></div></div></span><br =
class=3D"Apple-interchange-newline"></div></span><br =
class=3D"Apple-interchange-newline"> </div><br><div><div>On Sep 9, 2010, =
at 10:21 AM, Fred Baker wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>On =
Sep 9, 2010, at 12:24 PM, Yiu L. Lee wrote:<br><blockquote =
type=3D"cite"><blockquote type=3D"cite">The objective is to turn on =
IPv6;<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">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.<br></blockquote><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>I will now refer you to the name of the email alias that =
Tina set up for this project. It is not <a =
href=3D"mailto:[email-masked]">[email-masked]</a>; it is =
<a =
href=3D"mailto:[email-masked]">[email-masked]</a>. =
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.<br><br>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.<br></div></blockquote><!--StartFragment--><p =
class=3D"MsoNormal"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 16px;">You are right. I =
completely understand your o<span class=3D"Apple-style-span" =
style=3D"font-family: 'Helvetica Neue'; font-size: 15px; white-space: =
pre-wrap; ">riginal intention</span>.</span></font></p><p =
class=3D"MsoNormal"><span style=3D"font-size:12.0pt">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.<o:p></o:p></span></p>

<!--EndFragment-->

<blockquote =
type=3D"cite"><div>_______________________________________________<br>v4to=
v6transition mailing list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br=
>https://www.ietf.org/mailman/listinfo/v4tov6transition<br></div></blockqu=
ote></div><br></body></html>=

--Boundary_(ID_g0pUgEuZXQWallHIU+GQ9Q)--

---

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