Subject: [v6ops] IPv6 content transition

From: Qiong <[email-masked]>
Date: Mon, 18 Jul 2011 09:57:20 +0800

Dear all,

We have updated the draft for IPv6 content transition (
http://www.ietf.org/id/draft-sunq-v6ops-contents-transition-01.txt). It
describes one deployment model of NAT64, aiming at rapidly increasing the
amount of IPv6 accessible contents for users from IPv6 Internet. We
have deployed
it in Hunan province, and there are six sites (including the official
website of China Telecom) have migrated through this approach. And it has
also been exhibited on world IPv6 day.

We sincerely have comments from you and hopeful to have a discussion on this
approach in the incoming IETF 81th.

Refer to the report on "The official website of China Telecom launches IPv6
address to visit formally"
http://networkvip.net/archives/the-official-website-of-china-telecom-launches-ipv6-address-to-visit-formally.html

Thank you very much for your interests.

Best regards

Qiong SUN

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 17 Jul 2011 22:40:45 -0700

Hi, so perhaps i'm confused, but basically this draft says, put a v6 address on your load balancer and you can serve content to v6 clients.

faithd  (which does the nat64 portion of what is described here) was commmited into the kame project codebase something like 1997/01/25

I think this is all very well and good but it's not real new, since basically every load balancer vendor out there has a white paper stating pretty much the same thing.

http://www.google.com/search?q=ipv6+load+balancer+whitepaper

turns up f5 h3c a10 vmware microsft white-papers for the top 5 hits. 

As an observation, l4 and higher load balancers are generally agnostic about the address family of the source and destination address family anyway so in some cases they're not even network address translators per-say.

On Jul 17, 2011, at 6:57 PM, Qiong wrote:

> Dear all,
> 
> We have updated the draft for IPv6 content transition ( http://www.ietf.org/id/draft-sunq-v6ops-contents-transition-01.txt). It describes one deployment model of NAT64, aiming at rapidly increasing the amount of IPv6 accessible contents for users from IPv6 Internet. We have deployed it in Hunan province, and there are six sites (including the official website of China Telecom) have migrated through this approach. And it has also been exhibited on world IPv6 day.
> 
> We sincerely have comments from you and hopeful to have a discussion on this approach in the incoming IETF 81th.
> 
> Refer to the report on "The official website of China Telecom launches IPv6 address to visit formally"
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Qiong <[email-masked]>
Date: Mon, 18 Jul 2011 18:43:26 +0800

Hi, Joel,

Thanks very much for your comments. Actually, our deployment model is not
designed for load balancer specifically. *It is a shared platform which
could offer the transition service for many CP/SPs at the same time and it
is usually located in the entrance of IPv4 IDC.*

In my understanding, load balancers are mostly used by individual ICPs,
while In our situation, we have found that a great many small-to-medium
CP/SPs (with/without load balancers) are quite willing to transit to IPv6
with this NAT64 platform. On the one hand, they do not need to upgrade their
load balancer at the current stage in order to support IPv6. On the other
hand, they can still make use of IPv4 security infrastructure in the data
center and rapidly increasing the contents accessible through IPv6.

Our document is not a new protocol, but a deployment model for NAT64 in
CP/SP side. And we would give some measurement results later.

We are lacking of IPv6 contents for such a long time. We hope this
deployment model can be regarded as an encouraging way to rapidly increase
IPv6 contents. It is quite simple and straightforward. And it can offer IPv6
service in such a short time. So why not use it in our network ?

Best wishes

Qiong SUN

On Mon, Jul 18, 2011 at 1:40 PM, Joel Jaeggli <[email-masked]> wrote:

> Hi, so perhaps i'm confused, but basically this draft says, put a v6
> address on your load balancer and you can serve content to v6 clients.
>
> faithd  (which does the nat64 portion of what is described here) was
> commmited into the kame project codebase something like 1997/01/25
>
> I think this is all very well and good but it's not real new, since
> basically every load balancer vendor out there has a white paper stating
> pretty much the same thing.
>
> As an observation, l4 and higher load balancers are generally agnostic
> about the address family of the source and destination address family anyway
> so in some cases they're not even network address translators per-say.
>
> amount of IPv6 accessible contents for users from IPv6 Internet. We have deployed

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 18 Jul 2011 07:53:40 -0700

On Jul 18, 2011, at 3:43 AM, Qiong wrote:

> Hi, Joel,
> 
> Thanks very much for your comments. Actually, our deployment model is not designed for load balancer specifically. It is a shared platform which could offer the transition service for many CP/SPs at the same time and it is usually located in the entrance of IPv4 IDC.

I don't think changing the name of the devices changes what it does. If the distinction is that the box is multi-tenant that doesn't seem like much of a distinction.

> In my understanding, load balancers are mostly used by individual ICPs, while In our situation, we have found that a great many small-to-medium CP/SPs (with/without load balancers) are quite willing to transit to IPv6 with this NAT64 platform. On the one hand, they do not need to upgrade their load balancer at the current stage in order to support IPv6. On the other hand, they can still make use of IPv4 security infrastructure in the data center and rapidly increasing the contents accessible through IPv6. 
> 
> Our document is not a new protocol, but a deployment model for NAT64 in CP/SP side. And we would give some measurement results later. 
> 
> We are lacking of IPv6 contents for such a long time. We hope this deployment model can be regarded as an encouraging way to rapidly increase IPv6 contents.

The problem that content providers have is not that they can't deploy a AAAA record and route one ip address to a load balancer.

> It is quite simple and straightforward. And it can offer IPv6 service in such a short time. So why not use it in our network ?

Indeed, why not? Does the draft advance the knowledge of the art?

---

From: Jacni Qin <[email-masked]>
Date: Tue, 19 Jul 2011 11:27:55 +0800

hi Joel,

Thanks a lot for the comments, inline please,

On Mon, Jul 18, 2011 at 10:53 PM, Joel Jaeggli <[email-masked]> wrote:

> I don't think changing the name of the devices changes what it does. If the
> distinction is that the box is multi-tenant that doesn't seem like much of a
> distinction.
>

Jacni>: Sorry, I guess the text about relationships/co-location with load
balancer in the draft makes it confusing.
If I understand it correctly, there are many different approaches
implemented on load balancers currently, some are NAT based, some are of
higher layers. While the simple deployment model discussed in the draft is
just based on NAT64, but the box is not necessarily to be colocated on the
load balancer.

I agree with you that the load balancers can achieve the same goal by means
of their own, or in this way, if they can be NAT based and with new NAT64
functions enabled.

> IPv6 contents.
> The problem that content providers have is not that they can't deploy a
> AAAA record and route one ip address to a load balancer.
>

Jacni>: IMHO, they share the same requirement of adding AAAA records.

> It is quite simple and straightforward. And it can offer IPv6 service in
> such a short time. So why not use it in our network ?
>
>

Jacni>: In short, as we all know, the most important thing for now is to
encourage the IPv6 deployments in every aspect. What we are doing is just to
use one product from IETF (NAT64) for this purpose, no new protocols.
And it works (please see the examples). So we wrote an informational
document to share what we've learned, and to discuss with you that whether
this is a good way, if so, we can move forward.

Cheers,
Jacni