guidelines for the operation of a shared IPv4/IPv6 Internet

headers Eleven Fu(Yu | 1 Nov 2011 09:54

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

* Brian E Carpenter

> That is a very different deployment model than
> draft-carpenter-v6ops-icp-guidance advocates. I can understand that
> there might be unusual circumstances in which it would be chosen, but
> it is so much simpler to dual-stack all servers.

In a purely technical sense, you might be right. However, I've come to
realize that dual-stack is not really a viable transition approach for
us, due to organizational and human considerations. I think the draft is
intended exactly for organizations such as ours btw, as we're a
small/medium-sized ICP.

We have a team of people that works on the network infrastructure (of
which I'm part), and several teams with sysadmins that operate the
customers' servers, operating systems, and the applications running on
them. While my colleagues and I are happy to promote IPv6 by always
assigning an IPv6 prefix to all LANs that are requested by the server
guys, their priorities are very different - they don't want to get
involved more networking than absolutely necessary. So if I give them
two IP stacks to work with, they'll choose one and leave the other one
unused, and not surprisingly, the one they choose to work with is going
to be the most familiar one - IPv4.

I can understand it, too - dual stack is in a sense dual work and dual
complexity. They'd need to configure ACLs twice, monitor everything
twice, accept lots of new failure scenarios and so on. It's real
operational overhead, and nobody really wants that.

If there is an explicit demand from the customer to have IPv6
availability, that changes things somewhat - but usually not more than
causing a dual-stacking of the public internet-facing frontends. Most
servers remain IPv4-only, while only the load balancers/web
servers/whatever gets an additional IPv6 address that can be published
in DNS. In any case, customer requests for IPv6 are few and far between,
and to this date no customer has ever asked us for a dual-stacking of
all of his servers.

After all, dual-stack as a transition mechanism has gained approx. zero
momentum in the decade it's been the recommended IPv6 transition
mechanism. I don't see any reason why that would change any time soon.

I'm instead pursuing a path where I'll give the sysadmins single-stack
IPv6 to work with, and handle IPv4 connectivity as a translation
function in the core network (e.g. using SIIT). We'll see how that works
out in the end, but it has some advantages over dual-stack, in my
opinion: First, it forces the sysadmins to actually make use of IPv6.
Second, it doesn't require them to deal with more than 1 IP protocol.
Third, and perhaps most importantly, it helps a lot with IPv4 depletion.

Best regards,
--

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

I'm not seeing why this is a better solution for a small/medium ICP
than just moving to a dual stack. That is much easier for a small
network than for a big one.

Regards
   Brian

On 2011-11-01 21:54, Eleven Fu(Yu) wrote:
> Hi Qiong:
> 
>    Please see some comments for draft-sunq-v6ops-contents-transition-02 below,
> 
> Figure 1 is a little misleading. Because NAT64 can only serve the communications initiated by IPv6 side to
IPv4 sever. It can’t provide connection service initiated by IPv4 side. However, the figure 1 may give
readers some information that it also use NAT64 to serve the connections initiated by IPv4 side to IPv6
sever. So I think some more information may need to be  described in the figure to clarify the IPv4 to IPv6
communitarian scenario.
> 
> Overall,  I think this solution is meaningful for mid-size and small ICPs to  provide IPv6  access service
and is useful to encourage IPv6 traffic.
> 
> Cheers
> 
> Yu
> 
> 
> From: v6ops-bounces <at> ietf.org<mailto:v6ops-bounces <at> ietf.org>
[mailto:v6ops-bounces <at> ietf.org]<mailto:[mailto:v6ops-bounces <at> ietf.org]> On Behalf Of Qiong
> Sent: Saturday, October 29, 2011 4:38 PM
> To: v6ops <at> ietf.org<mailto:v6ops <at> ietf.org>
> Subject: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt
> 
> Dear, all,
> 
> Thanks for your feedback from IETF 81th. We have updated a new version of "Rapid Transition of IPv4
contents to be IPv6-accessible". We have deployed several models for the transition of IPv4 services to
IPv6 in our commercial network, aiming at rapidly increasing the amount of IPv6 accessible contents for
users from IPv6 Internet while preserving the continuity of IPv4 service delivery. We would like to share
our experiments and considerations. Anyway, content transition is very important in the whole IPv6
transition process.
> 
> You can find it through: http://tools.ietf.org/id/draft-sunq-v6ops-contents-transition-02.txt
> 
> Your comments will be very much appreciated.  Thanks in advance!
> 
> Best wishes
> 
> Qiong
> 
> ---------- Forwarded message ----------
> From: sunqiong <sunqiong <at> ctbri.com.cn<mailto:sunqiong <at> ctbri.com.cn>>
> Date: Sat, Oct 29, 2011 at 4:20 PM
> Subject: Fw: New Version Notification fordraft-sunq-v6ops-contents-transition-02.txt
> A new version of I-D, draft-sunq-v6ops-contents-transition-02.txt has been successfully submitted
by Qiong Sun and posted to the IETF repository.
> 
> Filename:  draft-sunq-v6ops-contents-transition
> Revision:  02
> Title:  Rapid Transition of IPv4 contents to be IPv6-accessible
> Creation date:  2011-10-29
> WG ID:  Individual Submission
> Number of pages: 14
> Abstract:
>    This document describes several deployment models for the transition
>    of IPv4 services to IPv6, aiming at rapidly increasing the amount of
>    IPv6 accessible contents for users from IPv6 Internet while
>    preserving the continuity of IPv4 service delivery.
> 
> The IETF Secretariat
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> v6ops mailing list
> v6ops <at> ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops <at> ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

Grumble. I don't like that conclusion, because it's clear that
the desired end point is native v6 and I don't see how your
approach gets us there.

OK, if the draft becomes a WG draft, I can see that we would
need to add the draft-sunq-v6ops-contents-transition model
to the outside-in scenario, as an alternative to the dual
stack proxy. However, although the proxy may be a bit slower,
it strikes me as a much cleaner solution than NAT64. And
of course it's off-the-shelf running code.

Regards
   Brian

On 2011-11-01 22:10, Tore Anderson wrote:
> * Brian E Carpenter
> 
>> That is a very different deployment model than
>> draft-carpenter-v6ops-icp-guidance advocates. I can understand that
>> there might be unusual circumstances in which it would be chosen, but
>> it is so much simpler to dual-stack all servers.
> 
> In a purely technical sense, you might be right. However, I've come to
> realize that dual-stack is not really a viable transition approach for
> us, due to organizational and human considerations. I think the draft is
> intended exactly for organizations such as ours btw, as we're a
> small/medium-sized ICP.
> 
> We have a team of people that works on the network infrastructure (of
> which I'm part), and several teams with sysadmins that operate the
> customers' servers, operating systems, and the applications running on
> them. While my colleagues and I are happy to promote IPv6 by always
> assigning an IPv6 prefix to all LANs that are requested by the server
> guys, their priorities are very different - they don't want to get
> involved more networking than absolutely necessary. So if I give them
> two IP stacks to work with, they'll choose one and leave the other one
> unused, and not surprisingly, the one they choose to work with is going
> to be the most familiar one - IPv4.
> 
> I can understand it, too - dual stack is in a sense dual work and dual
> complexity. They'd need to configure ACLs twice, monitor everything
> twice, accept lots of new failure scenarios and so on. It's real
> operational overhead, and nobody really wants that.
> 
> If there is an explicit demand from the customer to have IPv6
> availability, that changes things somewhat - but usually not more than
> causing a dual-stacking of the public internet-facing frontends. Most
> servers remain IPv4-only, while only the load balancers/web
> servers/whatever gets an additional IPv6 address that can be published
> in DNS. In any case, customer requests for IPv6 are few and far between,
> and to this date no customer has ever asked us for a dual-stacking of
> all of his servers.
> 
> After all, dual-stack as a transition mechanism has gained approx. zero
> momentum in the decade it's been the recommended IPv6 transition
> mechanism. I don't see any reason why that would change any time soon.
> 
> I'm instead pursuing a path where I'll give the sysadmins single-stack
> IPv6 to work with, and handle IPv4 connectivity as a translation
> function in the core network (e.g. using SIIT). We'll see how that works
> out in the end, but it has some advantages over dual-stack, in my
> opinion: First, it forces the sysadmins to actually make use of IPv6.
> Second, it doesn't require them to deal with more than 1 IP protocol.
> Third, and perhaps most importantly, it helps a lot with IPv4 depletion.
> 
> Best regards,
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

In message <4EAFB76D.7070208@...>, Tore Anderson writes:
> * Brian E Carpenter
> 
> > That is a very different deployment model than
> > draft-carpenter-v6ops-icp-guidance advocates. I can understand that
> > there might be unusual circumstances in which it would be chosen, but
> > it is so much simpler to dual-stack all servers.
> 
> In a purely technical sense, you might be right. However, I've come to
> realize that dual-stack is not really a viable transition approach for
> us, due to organizational and human considerations. I think the draft is
> intended exactly for organizations such as ours btw, as we're a
> small/medium-sized ICP.
> 
> We have a team of people that works on the network infrastructure (of
> which I'm part), and several teams with sysadmins that operate the
> customers' servers, operating systems, and the applications running on
> them. While my colleagues and I are happy to promote IPv6 by always
> assigning an IPv6 prefix to all LANs that are requested by the server
> guys, their priorities are very different - they don't want to get
> involved more networking than absolutely necessary. So if I give them
> two IP stacks to work with, they'll choose one and leave the other one
> unused, and not surprisingly, the one they choose to work with is going
> to be the most familiar one - IPv4.
> 
> I can understand it, too - dual stack is in a sense dual work and dual
> complexity. They'd need to configure ACLs twice, monitor everything
> twice, accept lots of new failure scenarios and so on. It's real
> operational overhead, and nobody really wants that.

Our ops people would say you are exagerating the costs.  They have
7+ years of dual stack experience.  It's not zero but is close to
that.

Mark
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@...
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

* Brian E Carpenter

> Grumble. I don't like that conclusion, because it's clear that
> the desired end point is native v6 and I don't see how your
> approach gets us there.

Native IPv6 on all servers and used by all applications running on those
servers doesn't get us to native IPv6? Huh? 

--

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

* Mark Andrews

> In message <4EAFB76D.7070208@...>, Tore
Anderson writes:
>>
>> In a purely technical sense, you might be right. However, I've come to
>> realize that dual-stack is not really a viable transition approach for
>> us, due to organizational and human considerations. I think the draft is
>> intended exactly for organizations such as ours btw, as we're a
>> small/medium-sized ICP.
>>
>> We have a team of people that works on the network infrastructure (of
>> which I'm part), and several teams with sysadmins that operate the
>> customers' servers, operating systems, and the applications running on
>> them. While my colleagues and I are happy to promote IPv6 by always
>> assigning an IPv6 prefix to all LANs that are requested by the server
>> guys, their priorities are very different - they don't want to get
>> involved more networking than absolutely necessary. So if I give them
>> two IP stacks to work with, they'll choose one and leave the other one
>> unused, and not surprisingly, the one they choose to work with is going
>> to be the most familiar one - IPv4.
>>
>> I can understand it, too - dual stack is in a sense dual work and dual
>> complexity. They'd need to configure ACLs twice, monitor everything
>> twice, accept lots of new failure scenarios and so on. It's real
>> operational overhead, and nobody really wants that.
> 
> Our ops people would say you are exagerating the costs.

Considering I didn't mention costs at all, I'm not sure how you came to
that conclusion. I don't believe that dual stack mean you have to double
your operations budget. The added technical complexity is the main
problem for us, not costs.

Not even an hour after I sent my previous e-mail yesterday, a colleague
came over to me asking if I could look into why some accounting cron
jobs had stopped working since last month. Turns out the problem was
that a server had been recently dual-stacked, which caused a download
job from another server (which had been dual-stacked for a long time) to
fail, because the ACLs that allowed the download to happen over IPv4
wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately
not critical at all, but it's an example of a failure scenario you are
open to only when running dual-stack.

Best regards,
--

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

In message <4EB10BDA.3060202@...>, Tore Anderson writes:
> * Mark Andrews
> 
> > In message <4EAFB76D.7070208@...>, Tore
Anderson writes:
> >>
> >> In a purely technical sense, you might be right. However, I've come to
> >> realize that dual-stack is not really a viable transition approach for
> >> us, due to organizational and human considerations. I think the draft is
> >> intended exactly for organizations such as ours btw, as we're a
> >> small/medium-sized ICP.
> >>
> >> We have a team of people that works on the network infrastructure (of
> >> which I'm part), and several teams with sysadmins that operate the
> >> customers' servers, operating systems, and the applications running on
> >> them. While my colleagues and I are happy to promote IPv6 by always
> >> assigning an IPv6 prefix to all LANs that are requested by the server
> >> guys, their priorities are very different - they don't want to get
> >> involved more networking than absolutely necessary. So if I give them
> >> two IP stacks to work with, they'll choose one and leave the other one
> >> unused, and not surprisingly, the one they choose to work with is going
> >> to be the most familiar one - IPv4.
> >>
> >> I can understand it, too - dual stack is in a sense dual work and dual
> >> complexity. They'd need to configure ACLs twice, monitor everything
> >> twice, accept lots of new failure scenarios and so on. It's real
> >> operational overhead, and nobody really wants that.
> > 
> > Our ops people would say you are exagerating the costs.
> 
> Considering I didn't mention costs at all, I'm not sure how you came to
> that conclusion. I don't believe that dual stack mean you have to double
> your operations budget. The added technical complexity is the main
> problem for us, not costs.
> 
> Not even an hour after I sent my previous e-mail yesterday, a colleague
> came over to me asking if I could look into why some accounting cron
> jobs had stopped working since last month. Turns out the problem was
> that a server had been recently dual-stacked, which caused a download
> job from another server (which had been dual-stacked for a long time) to
> fail, because the ACLs that allowed the download to happen over IPv4
> wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately
> not critical at all, but it's an example of a failure scenario you are
> open to only when running dual-stack.

I would suggest that your tools are not RFC 1123 compliant as they
didn't cope with a multi-homed servers.  This failure could have
happened with IPv4 only.  It's only been been 22 years since support
for multi-homed servers was recommended.

> Best regards,
> -- 
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@...
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

35	May 2013
85	April 2013
762	March 2013
402	February 2013
161	January 2013
54	December 2012
166	November 2012
218	October 2012
342	September 2012
453	August 2012
231	July 2012
116	June 2012
433	May 2012
249	April 2012
368	March 2012
264	February 2012
137	January 2012
266	December 2011
569	November 2011
386	October 2011
96	September 2011
375	August 2011
500	July 2011
207	June 2011
444	May 2011
547	April 2011
312	March 2011
604	February 2011
279	January 2011
580	December 2010
327	November 2010
421	October 2010
208	September 2010
175	August 2010
80	July 2010
34	June 2010
9	May 2010
223	April 2010
278	March 2010
63	February 2010
135	January 2010
24	December 2009
44	November 2009
47	October 2009
41	September 2009
91	August 2009
163	July 2009
28	June 2009
55	May 2009
57	April 2009
216	March 2009
27	February 2009
27	January 2009
36	December 2008
114	November 2008
68	October 2008
58	September 2008
134	August 2008
489	July 2008
91	June 2008
61	May 2008
284	April 2008
130	March 2008
141	February 2008
186	January 2008
127	December 2007
128	November 2007
138	October 2007
79	September 2007
70	August 2007
237	July 2007
32	June 2007
76	May 2007
145	April 2007
163	March 2007
29	February 2007
27	January 2007
33	December 2006
43	November 2006
37	October 2006
20	September 2006
30	August 2006
123	July 2006
78	June 2006
83	May 2006
53	April 2006
80	March 2006
34	February 2006
48	January 2006
25	December 2005
51	November 2005
65	October 2005
42	September 2005
159	August 2005
48	July 2005
29	June 2005
45	May 2005
100	April 2005
74	March 2005
30	February 2005
68	January 2005
44	December 2004
308	November 2004
131	October 2004
108	September 2004
236	August 2004
172	July 2004
177	June 2004
187	May 2004
179	April 2004
283	March 2004
135	February 2004
40	January 2004
32	December 2003
409	November 2003
194	October 2003
167	September 2003
124	August 2003
237	July 2003
53	June 2003
91	May 2003
24	April 2003
199	March 2003
154	February 2003
128	January 2003
139	December 2002
288	November 2002
123	October 2002
480	September 2002
4	August 2002

Re: Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

Re: new draft: draft-carpenter-v6ops-icp-guidance

Re: Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

Re: new draft: draft-carpenter-v6ops-icp-guidance

Re: Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

Re: new draft: draft-carpenter-v6ops-icp-guidance

Re: Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

Re: new draft: draft-carpenter-v6ops-icp-guidance

Re: new draft: draft-carpenter-v6ops-icp-guidance

Re: new draft: draft-carpenter-v6ops-icp-guidance