Subject: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02

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

The following message commences a 1 week call for opinions on the
adoption of draft-chen-v6ops-nat64-experience-02

 http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02

Friday 7/13/2012 is the deadline for this particular call.

Thank you.
joel

>> 企业标准的文本格式（模版）
>>
>> Dear Chairs,
>>
>>  
>>
>> We have posted new draft of NAT64 experiences.
>>
>> Current draft is a joined effort from four operators (China Mobile,
>> T-mobile USA, China Telecom and France Telecom)
>>
>> who is actively progressing IPv6 deployment depending on the practices.
>>
>> Several experts encourage us to continue the work after their kind review
>>
>>  
>>
>> For now, we have addressed all comments.
>>
>> The draft is ready for the adoption.
>>
>> The authors would like to consult your opinions and look forward your
>> guidance.
>>
>>  
>>
>>  
>>
>> Many thanks
>>
>>  
>>
>> Authors
>>
>>  
>>
>> =====================================================
>>
>> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt
>>
>> has been successfully submitted by Gang Chen and posted to the
>>
>> IETF repository.
>>
>>  
>>
>> Filename:        draft-chen-v6ops-nat64-experience
>>
>> Revision:        02
>>
>> Title:           NAT64 Operational Experiences
>>
>> Creation date:   2012-07-04
>>
>> WG ID:           Individual Submission
>>
>> Number of pages: 15
>>
>> URL:            
>> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02.txt
>>
>> Status:         
>> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience
>>
>> Htmlized:       
>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02
>>
>> Diff:           
>> http://tools.ietf.org/rfcdiff?url2=draft-chen-v6ops-nat64-experience-02
>>
>>  
>>
>> Abstract:
>>
>>    This document summarizes some stateful NAT64 deployment scenarios and
>>
>>    operational experiences for NAT64-CGN and NAT64-CE.
>>
>>  
>>
>>  
>>
>

---

From: <[email-masked]>
Date: Fri, 6 Jul 2012 18:06:45 +0200

WG,

I support the adoption of draft-chen-v6ops-nat64-experience-02 as a v6ops WG document.

Cheers,

Christian.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Joel jaeggli
Envoyé : vendredi 6 juillet 2012 17:43
À : IPv6 Ops WG
Objet : [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02

The following message commences a 1 week call for opinions on the adoption of draft-chen-v6ops-nat64-experience-02

Thank you.
joel

>> The authors would like to consult your opinions and look forward your 

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Masanobu Kawashima <[email-masked]>
Date: Mon, 9 Jul 2012 15:45:14 +0900

I support this document as a WG document.

Regards,
Masanobu

>>> $Bh>"f%/Th!!-m-fmz(B>>>

========================================
 NEC AccessTechnica, Ltd.               
 Product Development Department         
 Masanobu Kawashima                     
 [email-masked]               
 http://www.necat.co.jp/                
========================================

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 10 Jul 2012 06:44:44 +0000

Support for WG adoption. Quite useful experience for other ISPs.

Sheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Joel jaeggli
> Sent: Friday, July 06, 2012 11:43 PM
> To: IPv6 Ops WG
> Subject: [v6ops] Call for Adoption, was Re: New draft waiting for adoption:
> draft-chen-v6ops-nat64-experience-02
>

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 13 Jul 2012 11:07:32 +0900

I support this adoption. This draft would be a good start point to be gathered operator's experiences of NAT64. 
FWIW, I think that it would be nice if the draft describes further experiences into the draft, DNS64 operation for example.

Best regards,
--satoru

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 13 Jul 2012 13:53:37 -0500

> I support this adoption. This draft would be a good start point to be gathered operator's experiences of NAT64.

+ 1

> FWIW, I think that it would be nice if the draft describes further experiences into the draft, DNS64 operation for example.

I would like to see a discussion on multicast support.
With unicast NAT64 so much deployed, don't we need multicast NAT64?

Regards,

Behcet

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 13 Jul 2012 12:16:35 -0700

This document call has sort of gotten lost in the shuffle of other
activity on the list...

I would say that from my vantage point as an contributor and not as a wg
chair that the document has some potential imho, but,

It's in no way ready for last call, so acceptance or not as a wg
document is basically about encouraging work on this draft.

For a document titled  NAT64 Operational Experiences

	it needs more experience

	the recommendations for deployment need to be simple and
	unambiguous.

	scenarios which are perilous are not recomendations

	section 4.1 smacks of "if we put nat64 everywhere, then nat64
	will be everywhere"

I would be willing given a copy of the source file to provide the
authors with a set of corrections that they can use at the discretion in
order to improve the readability.

thanks
joel

---

From: Tetsuya Murakami <[email-masked]>
Date: Fri, 13 Jul 2012 19:33:37 +0000

On 2012/07/12, at 19:07, Satoru Matsushima wrote:

+1

I support for WG adoption. This draft is very useful experience for not only operators but also implementation.

Thanks,
Tetsuya

---

From: Tina TSOU <[email-masked]>
Date: Sat, 21 Jul 2012 04:25:57 +0000

Support with comments below.

In the draft, NAT64 was compared with dual stack network where more cost is involved while managing two stacks of protocol. If NAT64 is a way of coexistence of IPv6 and IPv4, a brief discussion of tunneling options compared to NAT64 can be added. Moreover, in the deployment considerations, in case NAT64 is integrated with an existing gateway, what would be the possible impacts and memory requirements of the gateway. There would a data base maintained of the mapping, that might demand more resources. Deploying it “close to BNG or CR has few impacts “ –if there can be few examples of the impacts.

Based on my NAT64 experience, the NAT64 gateway should also define routes to the block of addresses (for example ::/96 ipv6 address block) used to represent IPv4 address. If a.b.c.d is used to represent s:f:g:h::1 then there should be routes to a.b.c.d  as well to successfully NAT. In my opinion, this is an important implementation requirement.

In NAT64-CE Networking paragraph, I did not get this line: “One big challenge is NAT64-CE facing IPv6 Internet, on which a significant IPv6 users may connect to.”

Tina

On Jul 20, 2012, at 4:47 PM, "Sheng Jiang" <[email-masked]<mailto:[email-masked]>> wrote:

Sheng

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
Of Joel jaeggli
Sent: Friday, July 06, 2012 11:43 PM
To: IPv6 Ops WG
Subject: [v6ops] Call for Adoption, was Re: New draft waiting for adoption:
draft-chen-v6ops-nat64-experience-02

Thank you.
joel

企业标准的文本格式（模版）

Dear Chairs,

Many thanks

Authors

IETF repository.

Revision:        02

Number of pages: 15

URL:

http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02.
txt

Status:

Htmlized:

Diff:

Abstract:

  This document summarizes some stateful NAT64 deployment
scenarios and

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

---

From: GangChen <[email-masked]>
Date: Sun, 22 Jul 2012 11:42:13 +0800

> Support with comments below.

Thanks

> In the draft, NAT64 was compared with dual stack network where more cost is
> involved while managing two stacks of protocol. If NAT64 is a way of
> coexistence of IPv6 and IPv4, a brief discussion of tunneling options
> compared to NAT64 can be added.

If we are focusing on the case of IPv6 communicating with IPv4, they
are likely incomparable imho.

>Moreover, in the deployment considerations,
> in case NAT64 is integrated with an existing gateway, what would be the
> possible impacts and memory requirements of the gateway. There would a data
> base maintained of the mapping, that might demand more resources. Deploying
> it “close to BNG or CR has few impacts “ –if there can be few examples of
> the impacts.

Right. We documented that at Section 3.1. Please take a further check.

> Based on my NAT64 experience, the NAT64 gateway should also define routes to
> the block of addresses (for example ::/96 ipv6 address block) used to
> represent IPv4 address. If a.b.c.d is used to represent s:f:g:h::1 then
> there should be routes to a.b.c.d  as well to successfully NAT. In my
> opinion, this is an important implementation requirement.

Those were discussed at section 3.4 rfc6052.

> In NAT64-CE Networking paragraph, I did not get this line: “One big
> challenge is NAT64-CE facing IPv6 Internet, on which a significant IPv6
> users may connect to.”

When NAT64-CE is doing, care should be taken to be aware of the
problems it may caused. The draft intended to raise such caution.
NAT64-CE implicitly means it has to encounter significant IPv6
customers connectivity in the scenario of IPv6 Internet->IPv4 network.
When numerous IPv6 connections are launched, scalability concerns are
applied. The draft recommended NAT64-CE is *only* deployed and used in
a relative small scale where appropriate number of IPv6 customer from
early adopter to access services.

BRs

Gang

> Tina
>
> On Jul 20, 2012, at 4:47 PM, "Sheng Jiang"
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]] On Behalf
> Of Joel jaeggli

---

From: joel jaeggli <[email-masked]>
Date: Tue, 24 Jul 2012 00:41:45 -0700

On 7/20/12 9:25 PM, Tina TSOU wrote:
> In the draft, NAT64 was compared with dual stack network where more
> cost is involved while managing two stacks of protocol. If NAT64 is a
> way of coexistence of IPv6 and IPv4, a brief discussion of tunneling
> options compared to NAT64 can be added. Moreover, in the deployment
> considerations, in case NAT64 is integrated with an existing gateway,
> what would be the possible impacts and memory requirements of the
> gateway. There would a data base maintained of the mapping, that might
> demand more resources. Deploying it “close to BNG or CR has few
> impacts “ –if there can be few examples of the impacts.
The assertions about cost bound up in the document I don't buy at all.
Particularly in the context of CGN deployment.

You're not likely to build in consensus in the in v6ops that dual stack
deployment is dramatically more expensive that the alternative (outside
cases where externalities such as licensing apply), so if you're headed
that direction you should be prepared to marshall a rather convincing
argument.
> Based on my NAT64 experience, the NAT64 gateway should also define
> routes to the block of addresses (for example ::/96 ipv6 address
> block) used to represent IPv4 address. If a.b.c.d is used to represent
> s:f:g:h::1 then there should be routes to a.b.c.d as well to
> successfully NAT. In my opinion, this is an important implementation
> requirement.
> challenge is NAT64-CE facing IPv6 Internet, on which a significant
> IPv6 users may connect to.”
Given that I'm unconvinced in the context of DC migration that placing a
nat64 translator in front of a load balancer is a good idea, I certainly
wouldn't support it here either.

stacking stateful devices is expensive state-wise (as that section
asserts), results in additional latency, loses the source address if
you're doing a transform and so on, the previous section attempts to
assert that the existence of the mapping to source address is valuable,
and indeed it is so much so that correlation after the fact isn't a
substitution for having that data when the connection is made.

an earlier section cites draft-ietf-intarea-nat-reveal-analysis-02 in
the case of addressing the loss of source address, that sort of
demonstrates the scope of the problem since that document doesn't solve it.
>>> From: [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: GangChen <[email-masked]>
Date: Tue, 24 Jul 2012 23:34:55 +0800

> Particularly in the context of CGN deployment.

The draft didn't intend to assert about cost, because that is subject to
concrete business models which is going beyond the scope of documenting.
What the draft documented is to objectively describe the cons and pros
in a given implementation.
Accepting your revision, I think the position of draft is getting clear,
i.e. the draft just objectively report what we have done and what we find.

> cases where externalities such as licensing apply),

Exactly. We don't want to enter a topic that would be worthy of another
30-page document, with all the different considerations. The draft
focus on the potential benefits when IPv6-only is adopted.

>so if you're headed

Given there were sufficient discussions on the list, I guess group
would surely understand that well. The draft didn't want to venture to
recommend something in this case. However, it should at least identify
the issues and let people aware of those issues, since those case are
sure to exist for the time being. The draft would like to raise such
caution.

> demonstrates the scope of the problem since that document doesn't solve it.

Good comments.
As you could see, the draft already asserted the expense
FWIW, we can state that further in the draft, e.g. for operators who
already deployed such mode, it should be cautious and aware the
problems it may cause.
Such usages should be restrained to a relative small-scale, since
native IPv6 is always desirable. For operators who seek a clear
precedent for operating reliable ipv6-only services, it should be
prudent to adopt such mode (in some sense it's not recommended),
because the usages is problematic at several aspects.

Many thanks

Gang