Subject: Re: [v6ops] Draft on DC migration to IPv6

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 01 Jul 2012 13:10:11 +0000

Hi Arturo,

On 28 Jun 2012, at 14:58 , Arturo Servin wrote:
>> The maturity level 1 corresponds to a datacenter in which all traffic it is v4-based,
>> and translation from and to the v6 Internet is provided at the border. Our take is
>> that this is the most common case nowadays.
>
>       Do you have some examples? Personally I haven't seen any (but I have seen just a few DC with v6, so I am not expert. I am just curious about the basis of your claim).

Precisely one of the references in the document describes one of these cases:
draft-sunq-v6ops-contents-transition-03

>       I have seen load balancers in front of webservers, but that I think is different.
>
>       For now the most common that I have seen are load balancers in DS and webservers in v4; and dual stack DCs where some services (i.e web, dns and sometimes email ) are in v6 and some others (legacy applications, video streaming, etc.) are in v4.

I think both of them would be cases for level 2 (the one based on LBs es described
in Figure 3, as far as I can tell) and the other one is a case that, as I said in
my previous reply, should be included in level 2 as well and mentioned as well.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 06 Jul 2012 09:08:47 -0700

On 6/25/12 05:56 , Fred Baker (fred) wrote:
> In addition to getting working group commentary (which has to happen to make it onto the agenda), may I suggest you discuss the draft with my co-chair, who is an IPv6 data center operator?

over in 2.1

   The translation of IPv6 requests into the internal infrastructure
   format occurs at the outmost level of the DC Internet connection.
   This can be typically achieved at the DC gateway routers, that
   support the appropriate address translation mechanisms for those
   services required to be accessed through native IPv6 requests.  The
   policies for applying adaptation can range from performing it only to
   a limited set of specified services to providing a general
   translation service for all public services.  Finer mechanisms, based
   on address ranges or more sophisticated dynamic policies are also
   possible, as they are applied by a limited set of control elements.
   This provides an additional level of control to the usage of IPv6
   routable addresses in the DC environment, which can be especially
   significant at the early deployment stages.

   This model is also suitable to be applied in an "off-shore" mode by
   the service provider connecting the DC infrastructure to the
   Internet, as described in [I-D.sunq-v6ops-contents-transition]

Basically no content provider that  I know of want to lose the source
address associated with the incoming request. so the recommendation
here, to the extent that it's a recommendation is really unappealing.

   o  Flow labels can be applied to enhance load-balancing, as described
      in [I-D.carpenter-v6ops-label-balance].  Incoming IPv6 requests
      can take advantage of them, and the gateway systems use them as a
      hint for applying load-balancing mechanisms at the IPv4 internal
      accesses.

The majority of the flow labels today are zero. datacenter operators are
not os developers and we don't engage in wishful thinking.

> On Jun 25, 2012, at 4:58 PM, Diego R. Lopez wrote:

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Wed, 11 Jul 2012 09:39:12 +0000

Hi Joel,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel jaeggli
Sent: Saturday, July 07, 2012 12:09 AM
To: Fred Baker (fred)
Cc: IPv6 Ops WG
Subject: Re: [v6ops] Draft on DC migration to IPv6

over in 2.1

[Cathy] The content provider will not lose the source address associated with the incoming request. The source IPv6 address is translated to IPv4 address, and the translator need retain the correspondence between IPv6 source address and IPv4 source address. This is similar to NAT64, but there is a bit different: typical NAT64 is session based while IPv4/v6 translator in datacenter can be user based which can reduce the binding entries. If we don't use v4/v6 translator and just update the datacenter to dual-stack, there will be a very huge cost. So it is not recommended at the begin of IPv6 migration.

[Cathy] Yes, I agree with you that "The majority of the flow labels today are zero". The datacenter will still use the tradition of the load-balance method. Using flow labels for load balance is a complementary method.

Cathy

> On Jun 25, 2012, at 4:58 PM, Diego R. Lopez wrote:
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Jul 2012 14:42:20 +0000

On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote:

> [Cathy] The content provider will not lose the source address associated with the incoming request. The source IPv6 address is translated to IPv4 address, and the translator need retain the correspondence between IPv6 source address and IPv4 source address. 

Yes, but for many data center applications, the application itself wants to know the original source address in order to provide location-aware services. So it is not sufficient for the NAT to know; the information needs to somehow be presented to the application. This has been brought up by Lorenzo among others as a requirement in their data centers and public services.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 11 Jul 2012 07:51:21 -0700

> [Cathy] The content provider will not lose the source address associated with the incoming request. The source IPv6 address is translated to IPv4 address, and the translator need retain the corresp…
The content provider will lose access to the source ip for the purposes 
of the application. retaining a correspondence in a log someplace is not 
the equivalent of passing that information along. Presuming the 
existance of a hypthetical message bus by which I can signal the 
application what the source address was is all fine and dandy but I 
don't have one. Some application layer proxies e.g. http(s) can pass 
this information in-band so you end up with x-forwarded-for for example 
(and no nat64) presuming  that you can enable load balancer application 
tier to handle such activities.
> [Cathy] Yes, I agree with you that "The majority of the flow labels today are zero". The datacenter will still use the tradition of the load-balance method. Using flow labels for load balance is a…
It's not complementary because today it doesn't work. So...  What useful 
advice does that amount to for someone considering enabling ipv6 on 
their load balancer tier?

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 11 Jul 2012 15:08:23 +0000

Hi,

> Yes, but for many data center applications, the application itself wants to know the original source address in order to provide location-aware services. So it is not sufficient for the NAT to know…

The draft does not imply that this is a recommended or desirable solution, but just
uses it to illustrate a possible way of achieving level 1, that have been reported
as a service by a network operator. And I can imagine that some DC operators
may well renounce to know the actual v6 source if they can have an easy path to
achieve v6 accesibility via a managed service like this.

And, just in case, I personally find many of those location-aware services more an
annoyance than  anything else: I don't see any advantage in getting an Estonian UI or
a search engine prioritizing results in Norwegian for me.

Be goode.

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 11 Jul 2012 15:14:54 +0000

On 11 Jul 2012, at 16:51 , joel jaeggli wrote:
> It's not complementary because today it doesn't work. So...  What useful advice does that amount to for someone considering enabling ipv6 on their load balancer tier?

It is a mention to the advantages that a generalization of the proposed usage of flow
labels for load balancing can bring. It this application of flow labels does not get
traction we shall delete it, but in its current status is a sound technical proposal
and I don't see it makes any harm.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: Qiong <[email-masked]>
Date: Wed, 11 Jul 2012 23:39:05 +0800

Dear Fred,

On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) <[email-masked]> wrote:

> > [Cathy] The content provider will not lose the source address associated
> with the incoming request. The source IPv6 address is translated to IPv4
> address, and the translator need retain the correspondence between IPv6
> source address and IPv4 source address.
>
> Yes, but for many data center applications, the application itself wants
> to know the original source address in order to provide location-aware
> services. So it is not sufficient for the NAT to know; the information
> needs to somehow be presented to the application. This has been brought up
> by Lorenzo among others as a requirement in their data centers and public
> services.
>

With regard to this point, I think it will be a common problem in address
sharing environment, especially when NAT becomes more and more prevalent
(NAT444, DS-Lite, NAT64, etc.) in the future. Content providers have to
face this problem that they will lose the original source address anyhow,
and we should think of a way to solve this problem, right?

In our trial, we have tried inserting X-forward header in NAT device to
make application get to know the original address. Besides, I think HOST_ID
(draft-ietf-intarea-nat-reveal-analysis) is also a possible solution. How
do you think ?

Thanks!

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Jul 2012 16:22:44 +0000

On Jul 11, 2012, at 8:39 AM, Qiong wrote:

Dear Fred,

On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) <[email-masked]<mailto:[email-masked]>> wrote:

With regard to this point, I think it will be a common problem in address sharing environment, especially when NAT becomes more and more prevalent (NAT444, DS-Lite, NAT64, etc.) in the future. Content providers have to face this problem that they will lose the original source address anyhow, and we should think of a way to solve this problem, right?

A solution needs to be arrived at; I'm not sure we need to think of the solution, but we should at least identify the issue.

In our trial, we have tried inserting X-forward header in NAT device to make application get to know the original address. Besides, I think HOST_ID (draft-ietf-intarea-nat-reveal-analysis) is also a possible solution. How do you think ?

Those are possible solutions. They represent adding some form of Application Layer Gateway, which is necessarily application-specific and to my knowledge are not defined for a variety of applications. My point to Cathy was that it is inadequate to dismiss the issue with "the NAT knows the translation"; while true at the network layer, it misses an important set of issues entirely.

I suspect that this document is not complete without addressing the application geolocation issues.

Thanks!

Best wishes
Qiong

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

Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
===============================================

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 11 Jul 2012 10:10:39 -0700

On 7/11/12 08:39 , Qiong wrote:
>     > [Cathy] The content provider will not lose the source address
>     associated with the incoming request. The source IPv6 address is
>     translated to IPv4 address, and the translator need retain the
>     correspondence between IPv6 source address and IPv4 source address.
> 
>     Yes, but for many data center applications, the application itself
>     wants to know the original source address in order to provide
>     location-aware services. So it is not sufficient for the NAT to
>     know; the information needs to somehow be presented to the
>     application. This has been brought up by Lorenzo among others as a
>     requirement in their data centers and public services.
> 
> 
> With regard to this point, I think it will be a common problem in
> address sharing environment, especially when NAT becomes more and more
> prevalent (NAT444, DS-Lite, NAT64, etc.) in the future. Content
> providers have to face this problem that they will lose the original
> source address anyhow, and we should think of a way to solve this
> problem, right?

The fact that the carrier the customer is behind might also nat their
source address or that they have a residential gateway is a rather more
distant problem then an nat64 located rather closer to me. I still want
to know that the source is verizon's cgnat rather than my local nat64
gateway.

> make application get to know the original address. Besides, I think
> HOST_ID (draft-ietf-intarea-nat-reveal-analysis) is also a possible
> solution.

Not within a draft that operates within the confines of existing reality
it isn't.

> How do you think ?

so you're rewriting the protocol stream on the fly, or this really an
alg and not a nat box, and I imagine you don't do http(s) in the case of
the former.

>     [email-masked] <mailto:[email-masked]>
> lightweight 4over6: /http://sourceforge.net/projects/laft6//
> PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ /

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 11 Jul 2012 22:03:14 +0000

> I suspect that this document is not complete without addressing the application geolocation issues.

I think you have a point here. What if we update the document explicitly mentioning
that managed v6 access to the DC in level 1 has issues with geolocation and other
applications expecting to apply the actual source address?

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: joel jaeggli <[email-masked]>
Date: Wed, 11 Jul 2012 20:10:11 -0700

> applications expecting to apply the actual source address?
Such that it shouldn't be done that way, sure.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 11 Jul 2012 20:18:23 -0700

> and I don't see it makes any harm.
I would hope that a document aiming to be,

  A Reference Framework for DC Migration to IPv6

would stick to things that you can in fact deploy. Datacenter v6 
deployment is not a theoretical future activity.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 11 Jul 2012 20:23:38 -0700

On 7/11/12 8:08 AM, Diego R. Lopez wrote:
> And, just in case, I personally find many of those location-aware 
> services more an annoyance than anything else: I don't see any 
> advantage in getting an Estonian UI or a search engine prioritizing 
> results in Norwegian for me.
fraud and abuse detection is a large application for source addresses, 
user visible content changes are one of the least important considerations.

---

From: Qiong <[email-masked]>
Date: Thu, 12 Jul 2012 11:54:11 +0800

Dear Fred,

On Thu, Jul 12, 2012 at 12:22 AM, Fred Baker (fred) <[email-masked]> wrote:

> On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) <[email-masked]>wrote:
>
>>
>> associated with the incoming request. The source IPv6 address is translated
>> to IPv4 address, and the translator need retain the correspondence between
>> IPv6 source address and IPv4 source address.
>>
>  A solution needs to be arrived at; I'm not sure we need to think of the
> solution, but we should at least identify the issue.
>
>  Those are possible solutions. They represent adding some form of
> Application Layer Gateway, which is necessarily application-specific and to
> my knowledge are not defined for a variety of applications. My point to
> Cathy was that it is inadequate to dismiss the issue with "the NAT knows
> the translation"; while true at the network layer, it misses an important
> set of issues entirely.
>

Qiong: Agree with you. We should identify the issue and the possible
solutions.

Best wishes
Qiong

Open source code:

---

From: Qiong <[email-masked]>
Date: Thu, 12 Jul 2012 12:10:46 +0800

Hi Joel,

> to know that the source is verizon's cgnat rather than my local nat64
But the fact is that you can not "assume" how close this NAT64 gateway is
the network. This depends on the operational deployment model, traffic
model, etc. It might be deployed distributed, centralized or in other ways.
But anyway, you will lose the orignial address and you can not trust it
anymore. Even if it is still a verizon's address, you can not know to what
extend the granularity you have lost. It is a reality now, and it will be
more and more prevalent in the future. The content provider should also
have to face it.

> Not within a draft that operates within the confines of existing reality
Why NAT+some sort of Application Gateway can not be a possible solution ?

Best wishes
Qiong

Open source code:

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2012 08:16:42 +0100

On 12/07/2012 05:10, Qiong wrote:
...
> more and more prevalent in the future. The content provider should also

Consider that this is also a massive problem created by the deployment
of NAT444 brought about by CGNs. IPv6 can only win here, as it offers a
long-term solution. But it seems clear to me that in the short term, IPv6
wins if we advocate full dual stack for DCs, because that maximizes the number
of cases in which we have end to end addressing and therefore have useable
geolocation.

     Brian

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Thu, 12 Jul 2012 08:05:23 +0000

Hi Brian,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, July 12, 2012 3:17 PM
To: Qiong
Cc: IPv6 Ops WG
Subject: Re: [v6ops] Draft on DC migration to IPv6

Full IPv6 in datacenter is the ultimate goal. However, the datacenter supporting IPv6 is not only network supporting, but also application layer supporting. Supporting IPv6 is a huge cost for the existing IPv4 only datacenter and some small ICPs. Currently, the IPv6 traffic and users are only a small part. Forcing the datacenter to fully support IPv6 is not a good choice at the beginning of IPv6 migration, and it may even impact the evolution of IPv6. It may be a good way to let current IPv4 only datacenter support IPv6 with small change. Through this way, it can promote the growth of IPv6 traffic.

Cathy

     Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Jul 2012 17:38:21 +0900

> Full IPv6 in datacenter is the ultimate goal. However, the datacenter
> supporting IPv6 is not only network supporting, but also application
> layer supporting. Supporting IPv6 is a huge cost for the existing IPv4
> only datacenter and some small ICPs. Currently, the IPv6 traffic and
> users are only a small part. Forcing the datacenter to fully support
> IPv6 is not a good choice at the beginning of IPv6 migration, and it
> may even impact the evolution of IPv6. It may be a good way to let
> current IPv4 only datacenter support IPv6 with small change. Through
> this way, it can promote the growth of IPv6 traffic.
> 
> Cathy

i am having problems reconciling these two paragraphs.

randy

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Thu, 12 Jul 2012 11:35:17 +0000

Agree with Diego that the solution in this document is only a possible way. 
For the operators who have easy IPv6 access, NAT is not needed. The source address could be presented to the application.
But for the operators who don't have easy IPv6 access, some encapsulation method should 
be used, e.g., IPv6-in-IPv4, to carry IPv6 traffic over IPv4.

Best Regards,
Cathy

-----Original Message-----
From: Diego R. Lopez [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2012 11:08 PM
To: Fred Baker (fred)
Cc: Zhouqian (Cathy); IPv6 Ops WG
Subject: Re: [v6ops] Draft on DC migration to IPv6

Hi,

Be goode.

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 12 Jul 2012 13:31:23 +0000

On 12 Jul 2012, at 05:23 , joel jaeggli wrote:
>> And, just in case, I personally find many of those location-aware services more an annoyance than anything else: I don't see any advantage in getting an Estonian UI or a search engine prioritizing results in Norwegian for me.
> fraud and abuse detection is a large application for source addresses, user visible content changes are one of the least important considerations.

Reputation services, applied for fraud and abuse detection, are another kind of
managed services that some network operators offer.

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2012 17:45:30 +0100

> i am having problems reconciling these two paragraphs.

That is because I wrote the first one, and Cathy wrote the second,
but her mail software did not mark up the text accordingly.

I think the problem is that the "level 1" phase advocated by the
draft is pretty broken, and geolocation is one of the damaged
pieces.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jul 2012 06:27:25 +0900

> but her mail software did not mark up the text accordingly.

oh <bleep>.  could people *please* learn how to configure their mail
user agents?

randy

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 12 Jul 2012 21:55:36 +0000

> draft is pretty broken, and geolocation is one of the damaged

Let me note that source address is only lost for the DC operator (and
geolocation jeopardized) only if level 1 is applied with an address translator
offered as a managed service by the network operator. As the text says, you
can have the address translator in the DC infrastructure, and in that case
the DC operator has the information.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 13 Jul 2012 00:46:31 -0700

On 7/12/12 01:05 , Zhouqian (Cathy) wrote:

> layer supporting. Supporting IPv6 is a huge cost for the existing
> IPv4 only datacenter and some small ICPs.

You're making an assertion you'd have to support with data.

> Currently, the IPv6 traffic
> and users are only a small part. Forcing the datacenter to fully
> support IPv6 is not a good choice at the beginning of IPv6 migration,
> and it may even impact the evolution of IPv6. 

I've never asserted that. What I have asserted is that nat64 translation
loses me the approximation of source addresses and my customers don't
consider that acceptable today regardless if the source addresses are
ipv4 or ipv6.

> It may be a good way to
> let current IPv4 only datacenter support IPv6 with small change.
> Through this way, it can promote the growth of IPv6 traffic.

So consider, as an operator, if your requirement were to provide the
source address as you recived it, how would you do that?

some (but certainly not a complete list of) possible answers are:

proxy where possible, that works fine for http/s/websockets/spdy

tunnel, all the way to the host if like. that can be done statelessly
and it leverages the fact that your servers have ipv6 stacks and support
ip-in-ip tunneling and have for more than a decade.

Be selective rather than plunging towards dualstack DC, customer facing
assets are only a portion of the stack that looks more like some of the
further discussion in this document.

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Mon, 16 Jul 2012 03:37:26 +0000

Hi Joel,

> From: Joel jaeggli [mailto:[email-masked]]
> Sent: Friday, July 13, 2012 3:47 PM
> To: Zhouqian (Cathy)
> Cc: Brian E Carpenter; Qiong; IPv6 Ops WG
There are only a few ICPs supporting IPv6 in China. But China is one of the countries 
which most lacks IPv4 addresses. The main reason is the cost and the small IPv6 traffic.

> consider that acceptable today regardless if the source addresses are
You are correct and the problem does exist in nat64 translation. But at the first 
stage of IPv6 datacenter transition when the client is v6 but the datacenter is still v4, 
this scenario is inevitable. We should think a better way to solve this. But currently 
nat64 translation or IPv6 in IPv4 tunnel may be possible solutions.

> further discussion in this document.
For some IPv6 applications in IPv4 only datacenter, we could use an IPv4 header 
in the original IPv6 packet(v6 in v4 tunnel). But for some content which does not 
support IPv6, translation is still needed.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 17 Jul 2012 00:43:19 +0000

On Jul 15, 2012, at 8:37 PM, Zhouqian (Cathy) wrote:

> There are only a few ICPs supporting IPv6 in China. But China is one of the countries which most lacks IPv4 addresses. 

I think there is some old data there. China took its time getting started, but the rapid collapse of the IPv4 pool in APNIC was in large part due to Chinese addressing demand. 

But taking your argument as it stands, it's that much better of an argument for Chinese ICPs to deploy IPv6.

If I were a Chinese ISP, which I'm not, rather than thinking long and hard about NAT64 translation as a way to deliver traffic to an IPv4-only ICP across an IPv6-dominant ISP network, I would think about how to open a cloud business model. "Just think, ICPs, instead of or in addition to running your data centers, you could also run a service in our cloud". I would then make a characteristic of VMs in the cloud datacenter and a requirement of applications using it be dual stack operation. That could be as simple as building an OS-specific replacement for gethostbyname and getaddrinfo that one handed a character string - an IPv4 literal, an IPv6 literal, or a domain name - and it handed back a connected socket or an error message, having executed a "happy eyeballs" algorithm underneath, and on incoming connections didn't care about the distinction. Wouldn't it be interesting if we had a public specification for that...

Business model => revenue for one's favorite ISP.

I would then take my IPv4-only client-side customers and use stateless NAT64 to support them in an (increasingly) IPv6-only network, with the effect of moving traffic from the IPv4-only data centers to the dual stack cloud data centers. And as residential customers become IPv6-capable, give them IPv6 service. Net effect: *native* IPv6 service.

If ICP customers complain that this is a business game, say "fine, deploy IPv6 in your data center, and then the game is over - we can even prefer your data center if you like". When the lack of IPv6 support becomes an issue for the ICP, the ICP will deploy it.

Note that half of the folks on this list just forwarded this email to their lawyers: it contained the phrase "business model" and the word "revenue".

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 17 Jul 2012 16:55:02 +0000

On 17 Jul 2012, at 02:43 , Fred Baker (fred) wrote:
> I would then make a characteristic of VMs in the cloud datacenter and a requirement of applications using it be dual stack operation. That could be as simple as building an OS-specific replacement for gethostbyname and getaddrinfo that one handed a character string - an IPv4 literal, an IPv6 literal, or a domain name - and it handed back a connected socket or an error message, having executed a "happy eyeballs" algorithm underneath, and on incoming connections didn't care about the distinction. Wouldn't it be interesting if we had a public specification for that…

Hmmm, that looks like an interesting additional approach to level 2 dual-stack DCs.
If the hypothetical OS functions replacement were smart enough, it would allow the
transparent interoperation of DCs with different levels of v6 penetration, either
horizontal (internal data paths are not migrated, for example) or vertical (per tenant or service group).

I'll add a mention to this possibility in the new version I'm working in, and
I think we could ellaborate a little more on the idea of the spec...

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Wed, 18 Jul 2012 06:32:41 +0000

Hi Fred,
>From the IPv6 world day website below, we can see that there are only 16 organizations in China 
which participate in the 2012 IPv6 World Day and part of them support IPv6 page.
http://www.worldipv6launch.org/participants/?q=1

Cathy

> From: Fred Baker (fred) [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2012 8:43 AM
> To: Zhouqian (Cathy)
> Cc: Joel jaeggli; IPv6 Ops WG
> > There are only a few ICPs supporting IPv6 in China. But China is one of the
> countries which most lacks IPv4 addresses.
> 
> I think there is some old data there. China took its time getting started, but
> the rapid collapse of the IPv4 pool in APNIC was in large part due to Chinese
> addressing demand.
> 
> If I were a Chinese ISP, which I'm not, rather than thinking long and hard
> about NAT64 translation as a way to deliver traffic to an IPv4-only ICP across
> an IPv6-dominant ISP network, I would think about how to open a cloud
> business model. "Just think, ICPs, instead of or in addition to running your
> data centers, you could also run a service in our cloud". I would then make a
> characteristic of VMs in the cloud datacenter and a requirement of
> applications using it be dual stack operation. That could be as simple as
> building an OS-specific replacement for gethostbyname and getaddrinfo that
> one handed a character string - an IPv4 literal, an IPv6 literal, or a domain
> name - and it handed back a connected socket or an error message, having
> executed a "happy eyeballs" algorithm underneath, and on incoming
> connections didn't care about the distinction. Wouldn't it be interesting if we
> had a public specification for that...
> 
> I would then take my IPv4-only client-side customers and use stateless
> NAT64 to support them in an (increasingly) IPv6-only network, with the
> effect of moving traffic from the IPv4-only data centers to the dual stack
> cloud data centers. And as residential customers become IPv6-capable, give
> them IPv6 service. Net effect: *native* IPv6 service.
> 
> If ICP customers complain that this is a business game, say "fine, deploy IPv6
> in your data center, and then the game is over - we can even prefer your
> data center if you like". When the lack of IPv6 support becomes an issue for
> the ICP, the ICP will deploy it.
> 
> Note that half of the folks on this list just forwarded this email to their
> lawyers: it contained the phrase "business model" and the word "revenue".

---

From: joel jaeggli <[email-masked]>
Date: Wed, 25 Jul 2012 08:48:21 -0700

> which most lacks IPv4 addresses. The main reason is the cost and the small IPv6 traffic.
Internet content providers are rather efficient users of ipv4 addresses 
on a host count vs address consumption basis, much moreso than retail ISPs.

Rather than perpetuate a myth of indigenous internet exceptional-ism 
which you have little evidence to support I would focus on advice to 
internet content providers that does not leave them worse of then they 
are remaining ipv4-only.
> this scenario is inevitable.
No it is not. It is not inevitable in my environment nor in that of many 
other operators.
>   We should think a better way to solve this.
This is an ops working group. we don't need more transition technology 
to provide advice to operators. in many respects we need less.
>   But currently