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

From: "Eleven Fu(Yu)" <[email-masked]>
Date: Tue, 01 Nov 2011 08:54:42 +0000

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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Qiong
Sent: Saturday, October 29, 2011 4:38 PM
To: [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>
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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Nov 2011 09:16:04 +1300

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:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Qiong <[email-masked]>
Date: Wed, 2 Nov 2011 13:04:12 +0800

Hi Yu,

Thanks for your comments. Please see inline :)

On Tue, Nov 1, 2011 at 4:54 PM, Eleven Fu(Yu) <[email-masked]>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.****
>
> **
>

Sorry for misleading, and we would clarify it in the next version. Our
deployment model includes both stateful NAT64 and stateless NAT64(IVI), in
which stateful NAT64 is for scenario initiated by IPv6 side to IPv4 server,
while stateless NAT64(IVI) is for IPv4 initiated client to IPv6 server.

 **
>
> 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.*
> ***
>
> **
>
Thanks. Our basic idea is to encourage IPv6 traffic and enrich IPv6
contents ASAP. Actually, we have discussed with many ICPs and their
situations are quite complicated. Some of them even do not realize what is
IPv6, but just keep asking us whether we have IPv6 customers or not.
We believe that the amount IPv6 traffic and IPv6-reachable contents is a
key point to the development of IPv6. After so many years of IPv6 research,
our whole community really need the confidence to move forward, and maybe
IPv6 traffic is most convincing. Although it is a only initial step kind of
not so clean, but it does help enriching IPv6 content for a great many
ICPs. What's why we would like to offer transition service to ICPs at low
cost.

Best wishes

Qiong

> **
>
> Cheers ****
>
> ** **
>
> Yu****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Qiong
> *Sent:* Saturday, October 29, 2011 4:38 PM
> *To:* [email-masked]
> *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****
>
> ** **
>
> From: *sunqiong* <[email-masked]>
> Subject: Fw: New Version Notification
> fordraft-sunq-v6ops-contents-transition-02.txt
>
> ****
> ** **
> 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****
>
> ** **
>

---

From: Qiong <[email-masked]>
Date: Wed, 2 Nov 2011 16:23:54 +0800

Hi Brian,

Thanks for your comments.

I agree that dual-stack is a very straightforward way to IPv6 and should be
recommended in general. But frankly, I think the situation we are facing
with seems much more complicated, sometimes beyond technical issues. Most
ICPs are still lacking of motivation to upgrade, just waiting for v6 users.
And in the same way, operators are also hesitating to deploy v6 when there
are very few existing v6 contents. This chicken and egg thing is still
ongoing, even we are running out IPv4 address.

After all, dual stack is what we have discussing for 10 years. But up to
now, how many ICPs have upgraded to IPv6 in dual-stack directly? I really
think we need to re-think it again, from both technical aspect and the
industry/or market aspect. And the first step is rather important to give
us confidence to move forward. That's why we recommend single-stack (either
v4 or v6) transition in the current phase. Then, for the conservative
ones, the IPv4 services can be still offered natively, and the IPv6
services can be offered by the stateful NAT64; while for progressive ones
and newly comers, the stateless IVI can be employed to offer native IPv6
services reachable via IPv4. And we hope it would help enrich IPv6 content
asap. Then how do you think ?

Thanks

Qiong

---

From: John Mann <[email-masked]>
Date: Wed, 2 Nov 2011 22:26:41 +1100

Hi,

On 2 November 2011 19:23, Qiong <[email-masked]> wrote:
> now, how many ICPs have upgraded to IPv6 in dual-stack directly?

At Monash University, we dual-stacked the main web farm and most user subnets.
Not much IPv6 traffic due to slow roll-out of (IPv6-enabled) Windows7 clients.

The big step increases in IPv6 traffic were due to
a) Google over IPv6 whitelisting
b) YouTube available over IPv6

Through our Internet border, we are now doing 600 GB/day (10%) IPv6
traffic inbound
and 60 GB/day (1.5%) IPv6 traffic outbound.

Google have broken the chicken v. egg impasse.
Enable IPv6 on Facebook, other CDNs etc and we could have a lot of IPv6 traffic!

Thanks,
    John

>  I really
> industry/or market aspect. And the first step is rather important to give us
> confidence to move forward. That's why we recommend single-stack (either v4
> or v6) transition in the current phase. Then, for the conservative ones, the
> IPv4 services can be still offered natively, and the IPv6 services can be
> offered by the stateful NAT64; while for progressive ones and newly comers,
> the stateless IVI can be employed to offer native IPv6 services reachable
> via IPv4. And we hope it would help enrich IPv6 content asap. Then how do
> you think ?
> Thanks
> Qiong
>
> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter
> <[email-masked]> wrote:
>>

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 2 Nov 2011 08:03:08 -0700

On Nov 2, 2011 1:25 AM, "Qiong" <[email-masked]> wrote:
> I agree that dual-stack is a very straightforward way to IPv6 and should
be recommended in general. But frankly, I think the situation we are facing

I agree with concerns here. My understanding is that:

Content = cloud (many many horizontally scaled servers)

Users = many devices (phone, tablet, pc, ...)

Free ipv4 is less than near term cloud + many devices

That said, there is going to be a lot of MARKET pressure for content to be
reachable end to end given that there will be many single stacks on each
side of the internet

I don't have any conclusion beyond agreeing with Qiong that simple
dual-stack cannot work since cloud and devices exceed the ipv4 addresses to
service them.

Cb

Ps. I remain very concerned about the digital divide impacts of ipv4
markets. IETF needs to take a more bold stance on ipv6-single stacking,
otherwise we are just creating a stronger market for ipv4 addresses,
widening the digital divide , and increasing cost of all involved.

---

From: Qiong <[email-masked]>
Date: Thu, 3 Nov 2011 00:19:16 +0800

Hi, John,

Thanks. Please see inline.

> b) YouTube available over IPv6

Does Google upgrade all their services directly on IPv6, or use some kind
of translation or proxy mechanism within its servers? I heard that Youtube
has adopted LISP+NAT64 for its own transition, and Yahoo has also deployed
several translation POPs around the world. I'm not sure whether it is
correct or not. Please correct me if I'm wrong :)
Of course, google is a very good example and we all hope many other ICPs
will follow it in a short time.

> Enable IPv6 on Facebook, other CDNs etc and we could have a lot of IPv6

Very good news! I believe the traffic volume is the most exciting info for
us. In China, we also have a great volume of IPv6 traffic in CERNET2 (China
Education Network for next generation Internet), which is a IPv6-only
core-network. We have a lot of IPv6 contents including videos, BT, forums,
etc, and the preference policy over IPv6 is applied here. As indicated in
our draft (Appendix 1.1), more than 91 percent of our IPv6 users come from
CERNET2.

However, from operator perspective, I still think the situation here is a
little bit different in commercial network. Since operator itself is for
earning money rather than doing research, it would be more harder to
persuade market people when there is no explicit value for them. After all,
IPv6 deployment will cost quite a lot in the short run. So a simple
question would just come out, why should we invest so much when there is
still little reachable IPv6 content.
In the same way, ICPs are also waiting for IPv6 users. In our situation,
although we already have quite a lot of CERNET2 IPv6 users, it is still far
from enough to convince a majority of ICPs upgrading to IPv6 directly. We
all expect that ICPs would have the same belief with us, that IPv6 is
definitely the future direction, but here we should make things happen at
the first step. Anyway, we believe that ICP transition is the key point to
IPv6 success.

Best wishes

Qiong

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Nov 2011 09:12:51 +1300

Qiong,

On 2011-11-03 05:19, Qiong wrote:
> has adopted LISP+NAT64 for its own transition, 

LISP???

> and Yahoo has also deployed

And credit where it is due: the discussion about outside-in vs inside-out
approaches in draft-carpenter-v6ops-icp-guidance came from an off-list message
from Erik Kline at Google. The point is, using a dual stack proxy or a NAT64
as a front-end interface to the IPv6 Internet is the first step in an outside-in
approach. It's a starting point, not a permanent solution.

Personally I think a proxy is a more forward-looking solution, but NAT64 is
a little more efficient, as a student of mine has proved.
(See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.pdf)

I think my main issue with your draft is the way the proposal is
described in section 3.1. If it was described as the first step
towards a complete solution according to RFC6180, I would
be much happier.

   Brian

---

From: Tore Anderson <[email-masked]>
Date: Thu, 03 Nov 2011 01:06:45 +0100 (CET)

* Qiong

> http://tools.ietf.org/id/draft-sunq-v6ops-contents-transition-02.txt
> 

Hello,

My comments follow:

1) Figure 1 displays a single NAT64 gateway that both handles stateless
IPv4-client-to-IPv6-server translations as well as stateful IPv6-client-
to-IPv4-server translations. These two techniques are completely
independent of each other, so I suggest you display this as two separate
translator boxes, and rather mention that the two functions may be co-
located on the same physical hardware.

A stateful function is limited by the total amount of flows as well as
the flow initiation rate, it is much more prone to being overloaded
than a stateless function. I therefore generally recommend against co-
locating critical stateful and stateless functions on the same hardware,
unless it can be ensured that an overloading of the stateful function
does not impact the stateless function.

To prevent confusion, I would also avoid referring to the two distinct
functions with the same name ("NAT64 gateway"). Perhaps "IVI gateway"
would be better for the stateless function? (Or "SIIT gateway", see
below.)

2) The header of section 5 ("IPv6-to-IPv4 communication scenario") is
somewhat ambigous. I suggest rewriting it to e.g. "IPv6 client to IPv4
server communication scenario". Likewise for the title of section 6.

3) In section 5, I think it should be mentioned that an alternative to
using stateful NAT64 is using a Layer-4 or Layer-7 proxy (e.g. HAProxy).
This has the advantage of sometimes being able to communicate the
original IPv6 source address of the end user to the IPv4 server,e.g.,
for geo-location. This can be done by inserting a Layer-7 header such
as HTTP's X-Forwarded-For.

4) In section 6, it should be pointed out that due to its stateless
nature, the IVI translation function can trivially be made redundant
and load balanced, by using standard routing techniques such as
anycasting and equal-cost multipath routes. This is in my opinion an
enormous advantage over stateful NAT64, which requres symmetric traffic
flow across a single translator box.

5) I believe there should be some discussion of potential issues arising
from the fact that the IPv6 header usually is 20 bytes larger than an
IPv4 header:

Assuming a standard Ethernet MTU of 1500 bytes, if a translator receives
a maximum-sized IPv4 packet with the Don't Fragment flag unset, the
translator needs to fragment the packet when translating to IPv6. This
has some potential side-effects, as the addition of the IPv6 Extension
Header may prevent firewalls and similar middleware boxes from correctly
evaluating the fragmented packets according to ACLs or similar.

Use of a 1520 bytes large MTU in the IPv6 network between the translator
and the server may be one way to deal with this problem, in the IVI
scenario. Also, when using TCP, an IPv6 server using MTU 1500 will
generally ensure sufficiently small enough MSS is negotiated so that the
IPv4 client is prevented from ever sending larger IPv4 packets than 1480
bytes, which will not require fragmentation. In the stateful scenario,
this issue can be avoided by using a Layer-4/7 proxy rather than NAT64.

6) I feel that the references to RFC 6219 is wrong. In all three cases
(sections 1, 3.1, and 6), it is used as a normative reference, i.e., as
the IVI protocol specification. However, RFC 6219 is not a protocol
specification as far as I can tell, it is rather just a case study. It
should therefore be an informative reference.

As far as I've been able to understand from reading RFC 6219, the
protocol called "stateless IVI" is in reality specified in RFC 6145
where it is called "Stateless IP/ICMP Translation" (SIIT). If this is
correct, and there really is no difference between "stateless IVI" and
SIIT, I feel that the use of the name IVI is questionable as it does not
appear once in RFC 6145 (nor in RFC 6052 for that matter). The only
reference I find to the name "IVI" in current IETF docs are in this
draft as well as in RFC 6219 (where it just seems to describe SIIT).

I therefore suggest you replace all mentions of (stateless) IVI with
SIIT, and the related normative references from RFC 6219 to RFC 6145.

Best regards,
-- 
Tore Anderson

---

From: Qiong <[email-masked]>
Date: Fri, 4 Nov 2011 10:04:45 +0800

Hi Brian,

Please see inline :)

> > has adopted LISP+NAT64 for its own transition,
Sorry, I remember wrong. It is facebook who has adopted LISP to offer IPv6
service, not google. Sorry for that mistake.

> approach. It's a starting point, not a permanent solution.

I agree that it is only a transition approach for ICP. We believe IPv6-only
support should be our final objective. However, the starting point is quite
important for us all, especially when IPv6 is under discussing for so many
years.
Thanks for your understanding, and I do think your draft is a good
reference for ICPs who would like to adopt dual-stack upgrading.

> (See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.pdf)
Sorry, I'm kind of confused by the comparison result. It seems the
performance of NAT64 would decrease significantly for Big request. But in
our performance test, both on prototype and commercial device, we do not
find such problem. I can share you with our test results later.

Best wishes

Qiong

> >>> confidence to move forward. That's why we recommend single-stack
> (either
> >> v4

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 3 Nov 2011 19:21:08 -0700

[email-masked]> wrote:
> Sorry, I remember wrong. It is facebook who has adopted LISP to offer
IPv6 service, not google. Sorry for that mistake.

They also offer non-LISP ipv6 at www.v6.facebook.com

> I agree that it is only a transition approach for ICP. We believe
IPv6-only support should be our final objective. However, the starting
point is quite important for us all, especially when IPv6 is under
discussing for so many years.
>> >> Enable IPv6 on Facebook, other CDNs etc and we could have a lot of
IPv6
>> >> traffic!
(either

---

From: Jacni Qin <[email-masked]>
Date: Fri, 4 Nov 2011 11:28:13 +0800

Hi Tore,

Thanks for your careful review and comments, inline please,

On Thu, Nov 3, 2011 at 8:06 AM, Tore Anderson <
[email-masked]> wrote:

> ...
> We are following the specifications in RFC6145/6146 about the fragment
issue.

> True, this has been mentioned in,
http://tools.ietf.org/html/rfc6145#page-6
the recommended approach as well.

> Please see above the reference, thanks

Cheers,
Jacni

---

From: Tore Anderson <[email-masked]>
Date: Fri, 04 Nov 2011 09:40:27 +0100

* Jacni Qin

> the recommended approach as well.

Thanks for the pointer - I agree, the referenced text here is good enough.

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

---

From: Qiong <[email-masked]>
Date: Fri, 4 Nov 2011 21:40:08 +0800

Hi Tore,

Thanks a lot for your comments:) Sorry for late reply.

Please see inline.

> located on the same physical hardware.
I'm sorry this figure really causes misunderstanding. It will be clearer to
separate these two translator boxes accordingly.

> does not impact the stateless function.
I agree that stateless solution have better scalability compared to
stateful ones. But for the question whether they should co-locate in the
same hardware or not, I personally think it may depend on the
implementation for different vendors. As far as I know, some vendors intend
to implement quite a lot transition mechanisms on the same device. In this
case, it would be reasonable to deploy them in the same device if the
overall performance is ensured.

> would be better for the stateless function? (Or "SIIT gateway", see
Well, I think SIIT is an old word obsoleted by RFC6145. I have confirmed
with Prof. Li (the author of RFC6145) that "stateless translation" is a
more accurate word. How do you think of this one?

> server communication scenario". Likewise for the title of section 6.
Very good suggestion :) Thanks.

> as HTTP's X-Forwarded-For.
Yes, proxy is another alternative to this scenario. From my perspective, I
think NAT64 would have better efficiency and take lower cost compared to
Layer-7 method. And it is also application-independent, except for a few
ALGs. Besides, we have offered an open API for CPs to retrieve its original
IPv6 address when necessary.
Actually, for address sharing situation in the future, e.g. NAT444,
DS-Lite, etc, one public IPv4 address will be shared among multiple
subscribers. This will also have impact on CPs and this kind of binding
information is useful for them as well. So, we would like to provide them
with a unified API to get binding information.
Therefore, I personally prefer network-layer translation as a transition
service offered by operators. Layer-7 proxy is also a good solution when
CPs would like to deploy it by themselves.

> flow across a single translator box.
Exactly:) That's why we would like to adopt stateless translation here.

> this issue can be avoided by using a Layer-4/7 proxy rather than NAT64.
Jacni has explained this part.

> SIIT, and the related normative references from RFC 6219 to RFC 6145.

Thanks for pointing out this mistake. We will quote RFC6145 and RFC6052 as
normative reference and replace RFC6219 as informative reference.
Regarding the name issue, how about using "stateless translation" and
"stateful translation" ?
Thanks again for your detailed review. I very much appreciated it:)

Best wishes

Qiong

---

From: Tore Anderson <[email-masked]>
Date: Fri, 04 Nov 2011 15:35:09 +0100

Hi again,

* Qiong

>> 1) Figure 1 displays a single NAT64 gateway that both handles
>> stateless IPv4-client-to-IPv6-server translations as well as
>> stateful IPv6-client- to-IPv4-server translations. These two
>> techniques are completely independent of each other, so I suggest
>> you display this as two separate translator boxes, and rather
>> mention that the two functions may be co- located on the same
>> physical hardware.
>> 
> I'm sorry this figure really causes misunderstanding. It will be
> clearer to separate these two translator boxes accordingly.
> 
>> A stateful function is limited by the total amount of flows as well
>> as the flow initiation rate, it is much more prone to being
>> overloaded than a stateless function. I therefore generally
>> recommend against co- locating critical stateful and stateless
>> functions on the same hardware, unless it can be ensured that an
>> overloading of the stateful function does not impact the stateless
>> function.
>> 
> stateful ones. But for the question whether they should co-locate in
> the same hardware or not, I personally think it may depend on the 
> implementation for different vendors. As far as I know, some vendors
> intend to implement quite a lot transition mechanisms on the same
> device. In this case, it would be reasonable to deploy them in the
> same device if the overall performance is ensured.

Yes, my point was not really that you should make any strong
recommendation either way, just that it should be made clear that the
two deployment scenarios described are completely independent of each
other, and that there are nothing about them that *requires* them to be
co-located on the same box. Which means breaking up the "NAT64" box in
Figure 1 in two, and perhaps adding another figures in sections 5 and 6.

> Well, I think SIIT is an old word obsoleted by RFC6145.

The text in RFC6145 starts like this:

«This document describes the Stateless IP/ICMP Translation Algorithm (SIIT)»

So to me it seems that RFC6145 doesn't in any way obsolete the term
«SIIT», quite the opposite: it _defines_ it.

> I have confirmed with Prof. Li (the author of RFC6145) that
> "stateless translation" is a more accurate word. How do you think of
> this one?

Well, as SIIT is an abbreviation for «Stateless IP/ICMP Translation» I
believe that is as accurate as you can get...

>> 3) In section 5, I think it should be mentioned that an alternative
>> to using stateful NAT64 is using a Layer-4 or Layer-7 proxy (e.g.
>> HAProxy). This has the advantage of sometimes being able to
>> communicate the original IPv6 source address of the end user to the
>> IPv4 server,e.g., for geo-location. This can be done by inserting a
>> Layer-7 header such as HTTP's X-Forwarded-For.
>> 
> Yes, proxy is another alternative to this scenario. From my
> perspective, I think NAT64 would have better efficiency and take
> lower cost compared to Layer-7 method. And it is also
> application-independent, except for a few ALGs. Besides, we have
> offered an open API for CPs to retrieve its original IPv6 address
> when necessary. Actually, for address sharing situation in the
> future, e.g. NAT444, DS-Lite, etc, one public IPv4 address will be
> shared among multiple subscribers. This will also have impact on CPs
> and this kind of binding information is useful for them as well. So,
> we would like to provide them with a unified API to get binding
> information. Therefore, I personally prefer network-layer translation
> as a transition service offered by operators. Layer-7 proxy is also a
> good solution when CPs would like to deploy it by themselves.

I am making no statement whether network, transport, or application
layer translation/proxying is the best, but it seems to me that the
alternatives should be mentioned, at least, so that the reader can
decide for himself which solution suits him the best. Unless, of course,
the scope of the document is meant to focus on network layer translation
exclusively. But its title and abstract doesn't indicate that.

Actually, come to think of it, the title of the document, «Rapid
Transition of IPv4 contents to be IPv6-accessible» only really describes
the stateful model described in section 5. Maybe it should be made more
generic? Something like «Transition of single-stack content to
dual-stack end-user availability», maybe?

>> 6) I feel that the references to RFC 6219 is wrong. In all three
>> cases (sections 1, 3.1, and 6), it is used as a normative
>> reference, i.e., as the IVI protocol specification. However, RFC
>> 6219 is not a protocol specification as far as I can tell, it is
>> rather just a case study. It should therefore be an informative
>> reference. As far as I've been able to understand from reading RFC
>> 6219, the protocol called "stateless IVI" is in reality specified
>> in RFC 6145 where it is called "Stateless IP/ICMP Translation"
>> (SIIT). If this is correct, and there really is no difference
>> between "stateless IVI" and SIIT, I feel that the use of the name
>> IVI is questionable as it does not appear once in RFC 6145 (nor in
>> RFC 6052 for that matter). The only reference I find to the name
>> "IVI" in current IETF docs are in this draft as well as in RFC 6219
>> (where it just seems to describe SIIT). I therefore suggest you
>> replace all mentions of (stateless) IVI with SIIT, and the related
>> normative references from RFC 6219 to RFC 6145.
> 
> Thanks for pointing out this mistake. We will quote RFC6145 and
> RFC6052 as normative reference and replace RFC6219 as informative
> reference. Regarding the name issue, how about using "stateless
> translation" and "stateful translation" ?

For the stateless model described in section 6, RFC 6145 (which in turn
refers to RFC 6052) is the protocol specification, and it defines the
name to be «Stateless IP/ICMP Translation», or «SIIT» for short.

For the stateful model described in section 5, RFC 6146 is the protocol
specification, and it defines the name to be «Stateful NAT64», or just
«NAT64» for short.

I really think you should stick to these names exactly as they are
defined. It's hard enough to keep track of all the various IPv6/IPv4
transition technologies with only one name per tech, we really don't
need even more names to learn. :-)

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 05 Nov 2011 08:47:03 +1300

On 2011-11-04 15:04, Qiong wrote:

...
> find such problem. I can share you with our test results later.

We could never explain that performance anomaly, even after inspecting
the code and discussing with the software author. It is probably only an
implementation issue.

    Brian

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 05 Nov 2011 07:47:33 -0700

On 11/2/11 01:23 , Qiong wrote:
> be recommended in general. But frankly, I think the situation we are
> facing with seems much more complicated, sometimes beyond technical
> issues. Most ICPs are still lacking of motivation to upgrade, just
> waiting for v6 users. And in the same way, operators are also hesitating
> to deploy v6 when there are very few existing v6 contents. This chicken
> and egg thing is still ongoing, even we are running out IPv4 address.
> 
> now, how many ICPs have upgraded to IPv6 in dual-stack directly? I
> really think we need to re-think it again, from both technical aspect
> and the industry/or market aspect. And the first step is rather
> important to give us confidence to move forward. That's why we recommend
> single-stack (either v4 or v6) transition in the current phase. Then,
> for the conservative ones, the IPv4 services can be still offered
> natively, and the IPv6 services can be offered by the stateful NAT64;
> while for progressive ones and newly comers, the stateless IVI can be
> employed to offer native IPv6 services reachable via IPv4. And we hope
> it would help enrich IPv6 content asap. Then how do you think ?

Any solution that causes me to lose access to the source address is not
usable from my vantage point as a content provider. When I terminate
connections on an l7 load balancer as I generally do for http/https on
ipv4 and where we do it in ipv6 I can drop x-forwarded for in there.
That requires that I recieve the traffic unmolested by a nat transform
associated with my own service.

> <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Nov 2011 08:45:35 +1300

in line ..

> associated with my own service.

It certainly seems that geolocation would fail miserably behind
a NAT64 local to the ICP. All the IPv6 clients would be reported
as living in the computer room, wouldn't they?

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Nov 2011 16:59:04 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Friday, November 04, 2011 12:47 PM
> To: Qiong
> Cc: [email-masked]
> Subject: [v6ops] OT: NA64 performance [ New Version Notification for
> draft-sunq-v6ops-contents-transition-02.txt]
> 
> the code and discussing with the software author. It is probably only
> an implementation issue.

Were the packets big enough you might be hitting MTU problems or PMTUD?

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Nov 2011 16:25:53 +1300

> Were the packets big enough you might be hitting MTU problems or PMTUD?

I really don't think so. "Large" meant an HTTP POST with 1200 bytes
in the payload, for a total packet size of 1382 bytes. Our lab runs
at 1500 bytes, and there was no encapsulation involved.

We have a paper about these tests undergoing peer review, otherwise I would
just post it here and now.

   Brian

---

From: Qiong <[email-masked]>
Date: Tue, 8 Nov 2011 13:48:33 +0800

Hi, Tore,

Thanks again for your comments.

See inline~~

On Fri, Nov 4, 2011 at 10:35 PM, Tore Anderson <
[email-masked]> wrote:

> ok, I get it. That's true, there is no "requirement" to be co-located in
the same box.

> Well, the SIIT in RFC2765 defines both header translation and address
translation, while RFC6145 only defines header translation, leaving address
translation in RFC6052. Anyway, we need to find a well-defined word rather
than create a new one, maybe SIIT :)

> Agree, and we will mention it as two alternatives.

> dual-stack end-user availability», maybe?

Hmm~~~We will consider it:)

Thanks

Best regards

Qiong

---

From: Qiong <[email-masked]>
Date: Tue, 8 Nov 2011 14:13:11 +0800

Hi, Joel

On Sat, Nov 5, 2011 at 10:47 PM, Joel jaeggli <[email-masked]> wrote:

> I agree it is important. But there is another question here : although you
can use l7 load balancer to insert x-forwarded here,  how can you guarantee
that there is no CGN along the path from the user's end-host to the data
center. I mean, in case we cannot avoid deploying some kind of address
sharing mechanisms in the future, ICPs have to face the fact that they
will somehow lose the geo-location info when they receive IPv4 traffic. So
maybe it is one choice to provide them with a database which stores
the original binding information. Would it be some kind of helpful ?

Thanks

Best wishes

Qiong

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 10 Nov 2011 16:00:25 -0800

On 11/7/11 22:13 , Qiong wrote:
> Hi, Joel
> 
> On Sat, Nov 5, 2011 at 10:47 PM, Joel jaeggli <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I agree it is important. But there is another question here : although
> you can use l7 load balancer to insert x-forwarded here,  how can you
> guarantee that there is no CGN along the path from the user's end-host
> to the data center.

I don't have to, what I need is a granular enough view of where the
address sharing is occuring that I can serve my content accordingly.
it's not a problem for example if ~200,000 mobile users of an app at
Indonesia's 3rd largest mobile operator emerge from behind a /22

> I mean, in case we cannot avoid deploying some kind
> of address sharing mechanisms in the future, ICPs have to face the fact

you'll note that I'm assuming the existence of address sharing
mechanisms on both sides of the conversation. I'd very much prefer that
the one working on my behalf not necessarily throw out information as a
product of it's design.

> that they will somehow lose the geo-location info when they receive IPv4
> traffic. So maybe it is one choice to provide them with a database which
> stores the original binding information. Would it be some kind of helpful ? 

where are you going to put that and signal it?
>     > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     > [email-masked] <mailto:[email-masked]>

---

From: Qiong <[email-masked]>
Date: Mon, 14 Nov 2011 10:29:42 +0800

Hi Joel,

Thanks for your explaination. I now understand your points clearly.
Please see inline :)

> Indonesia's 3rd largest mobile operator emerge from behind a /22

Well, in that case, it would be much simpler. But the situation in our
network, is that we do have address exhaustion problem. I think this
will become common problem for most operators sooner or later, and we
somehow have to adopt some kind of address sharing approach in our
network.

> the one working on my behalf not necessarily throw out information as a
I think this is a tradeoff, and we would discuss it more clearly in
the next version.

> where are you going to put that and signal it?
We have offered an web-service based API and the content provider can
use it to retrieve its original IPv6 address when receiving an IPv4
packet.

Best wishes

Qiong

---

From: Chongfeng Xie <[email-masked]>
Date: Fri, 18 Nov 2011 15:32:02 +0800

Hi, Joel,

       The stateful NAT64 can serve multiple ICPs within the same IDC
simultaneously.  All of them are IPv4-only and can not read IPv6 address,
they have different expectations to get the source IPv6 address, some want
to get IPv6 address, some may not. Some may want to get this information
online, some may offline. What I mean is that ICPs have different
requirements to geo-location. The current NAT64 design keeps the mapping
between users' IPv6 source address and IPv4 address, so the geo-location
information was not threw out in the NAT64 design. We will provide
Interfaces to ICPs to meet their different demands, this is our on-going
work.

      From the standpoint viewpoint of carriers, NAT64 can server as a
shared platform for ICPs in the early phase of transition, especially when
the volume of IPv6 users in not big enough.  Carriers would NOT like to
deploy a system which is involved with too much application-layer
processing, we prefer a solution of network-layer, this is more consistent
with the role of IETF  "above the wire and below the application".

Thank you!

Chongfeng

2011/11/11 Joel jaeggli <[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Nov 2011 16:06:06 +0800

> with the role of IETF  "above the wire and below the application".

But we should also not recommend a solution for general use if it has
shortcomings.

This solution does not provide the servers with access to the original IPv6
address, and thus does not allow them to do abuse detection, abuse
mitigation, legal intercept, geolocation, and a host of other things. These
issues, coupled with scaling issues, make it unsuitable for real deployment
except in very small websites. It also has the operational disadvantage
that the complete logging information for a request (including the user's
IPv6 address) are not in one place any more, but either in two places (if
the NAT does logging) or not available at all (if it doesn't).

You could run an experiment using this solution. You could run
ipv6.company.com using this solution. But you couldn't run
www.company.comusing this solution unless it was very very small. So I
don't think that
this working group should sanction such a solution; instead, we should
provide implementors with tools and guidance for actually deploying IPv6 in
a way that will scale to their main websites.

---

From: Tina TSOU <[email-masked]>
Date: Fri, 18 Nov 2011 08:17:27 +0000

www.huawei.com<http://www.huawei.com> for World IPv6 Day and ipv6.huawei.com for long term, both use dual stack DNS server and Web server, and China Telecom's dual stack network.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Friday, November 18, 2011 4:06 PM
To: Chongfeng Xie
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

On Fri, Nov 18, 2011 at 15:32, Chongfeng Xie <[email-masked]<mailto:[email-masked]>> wrote:
      From the standpoint viewpoint of carriers, NAT64 can server as a shared platform for ICPs in the early phase of transition, especially when the volume of IPv6 users in not big enough.  Carriers would NOT like to deploy a system which is involved with too much application-layer processing, we prefer a solution of network-layer, this is more consistent with the role of IETF  "above the wire and below the application".

But we should also not recommend a solution for general use if it has shortcomings.

This solution does not provide the servers with access to the original IPv6 address, and thus does not allow them to do abuse detection, abuse mitigation, legal intercept, geolocation, and a host of other things. These issues, coupled with scaling issues, make it unsuitable for real deployment except in very small websites. It also has the operational disadvantage that the complete logging information for a request (including the user's IPv6 address) are not in one place any more, but either in two places (if the NAT does logging) or not available at all (if it doesn't).

You could run an experiment using this solution. You could run ipv6.company.com<http://ipv6.company.com> using this solution. But you couldn't run www.company.com<http://www.company.com> using this solution unless it was very very small. So I don't think that this working group should sanction such a solution; instead, we should provide implementors with tools and guidance for actually deploying IPv6 in a way that will scale to their main websites.

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 20 Nov 2011 05:11:09 +0800

On 11/18/11 15:32 , Chongfeng Xie wrote:
> simultaneously.  All of them are IPv4-only and can not read IPv6
> address, they have different expectations to get the source IPv6
> address, some want to get IPv6 address, some may not. Some may want to
> get this information online, some may offline. What I mean is that ICPs
> have different requirements to geo-location. The current NAT64 design
> keeps the mapping between users' IPv6 source address and IPv4 address,
> so the geo-location information was not threw out in the NAT64 design.
> We will provide Interfaces to ICPs to meet their different demands, this
> is our on-going work.
> 
> shared platform for ICPs in the early phase of transition, especially
> when the volume of IPv6 users in not big enough.  Carriers would NOT
> like to deploy a system which is involved with too much
> application-layer processing, we prefer a solution of network-layer,
> this is more consistent with the role of IETF  "above the wire and below
> the application".

This is IPv6 "operations"...

As an operator of an internet content provider I need more visibility
than this proposed approach provides and I'm not alone.

A document covering what you did, I think, is just peachy. Putting the
v6ops stamp of approval on such a document given that I view the
approach as a bad idea would be something that I oppose.

> Thank you!
> 
> Chongfeng
> 
> 2011/11/11 Joel jaeggli <[email-masked] <mailto:[email-masked]>>
> 
>     <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     > After all, dual stack is what we have discussing for 10
>     years. But
>     >     up to
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>> wrote:
>     >     >
>     <mailto:[email-masked] <mailto:[email-masked]>>