[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [v4tov6transition] FW: New Version Notification for draft-lee-v4v6tran-problem-01
<v6ops@ops.ietf.org>,
v4tov6transition@ietf.org
Message-id: <2B87304C-9FF5-43B4-8734-944C55AF674C@huawei.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.936)
Content-type: multipart/alternative;
boundary="Boundary_(ID_g0pUgEuZXQWallHIU+GQ9Q)"
References: <C8ADCBAA.317AD%yiu_lee@cable.comcast.com>
<927EA826-CEF7-4942-8AA5-45C0FA353446@cisco.com>
Sender: owner-v6ops@ops.ietf.org
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
http://tinatsou.weebly.com
On Sep 9, 2010, at 10:21 AM, Fred Baker wrote:
> 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 KeepV4Running@ietf.org; it is V4toV6Transition@ietf.org
> . 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
> v4tov6transition@ietf.org
> https://www.ietf.org/mailman/listinfo/v4tov6transition
--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:KeepV4Running@ietf.org";>KeepV4Running@ietf.org</a>; it is =
<a =
href=3D"mailto:V4toV6Transition@ietf.org";>V4toV6Transition@ietf.org</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:v4tov6transition@ietf.org";>v4tov6transition@ietf.org</a><br=
>https://www.ietf.org/mailman/listinfo/v4tov6transition<br></div></blockqu=
ote></div><br></body></html>=
--Boundary_(ID_g0pUgEuZXQWallHIU+GQ9Q)--