Subject: [v6ops] NAT64 Operational Considerations

From: GangChen <[email-masked]>
Date: Thu, 3 Nov 2011 10:00:15 +0800

Dear all,

I have just submitted the draft for NAT64 operational consideration.
The intention is to provide comprehensive considerations for NAT64 deployment.
The detailed information is listed at below

A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : NAT64 Operational Considerations
       Author(s)       : Gang Chen
       Filename        : draft-chen-v6ops-nat64-cpe-03.txt
       Pages           : 8
       Date            : 2011-10-31

  The document has summarized NAT64 usages on different modes, in which
  NAT64 may serve for a large-scale network or would give enterprise or
  residential service opportunities to be accessed by IPv6 remote
  subscribers.  The document has described different operations for
  each usage and proposed operational considerations for each
  particular NAT64-mode.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt

Many thanks

Gang

---

From: Qiong <[email-masked]>
Date: Thu, 3 Nov 2011 10:29:49 +0800

Hi, Gang,

I'm not against that NAT64 can be deployed in IDC scenario. But actually,
this deployment model is originally proposed by us in
draft-sunq-v6ops-contents-transition-00, don't you think it
is inappropriate to  include it without notification to us?

Best regards

Qiong

On Thu, Nov 3, 2011 at 10:00 AM, GangChen <[email-masked]> wrote:

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

---

From: GangChen <[email-masked]>
Date: Thu, 3 Nov 2011 20:59:39 +0800

hi Qiong,

I can hardly understand your points. I mean that is a pretty common
use case, not your proprietary. It has already been included in
draft-chen-v6ops-nat64-cpe-02 and presented in last IETF meeting. I
believe we all here is to find good solutions and contribute the
community. I'm very sorry to hear your suspicion, which is against the
IETF spirit. That is a place for technical discussion. Don't you think
that is inappropriate to make such statement?

Gang

---

From: "Eleven Fu(Yu)" <[email-masked]>
Date: Mon, 07 Nov 2011 10:02:11 +0000

Hi Gang,

I have read draft-chen-v6ops-nat64-cpe, please see come comments below,

The draft is structured by different deploy positions of NAT64 as different modes. It describes operational process for each mode. But I think as a informational guide for readers, some more considerations need to be described for each mode in more detail, such as logging problem, ALG issues, DNS, load balancing etc.

For section 4, some security considerations also need to be involved, such as user tracking, Dos attack etc.

Cheers

Yu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of GangChen
Sent: Thursday, November 03, 2011 10:00 AM
To: v6ops
Subject: [v6ops] NAT64 Operational Considerations

Dear all,

Many thanks

Gang

---

From: Arturo Servin <[email-masked]>
Date: Mon, 7 Nov 2011 15:04:12 -0200

Gang,

	I found a bit hard to see the target audience of this draft, it has a bit for developers and a bit for operators.

	As an operator I was expecting to see some practical recommendations on what to do (and what not to) for deploying NAT64. I haven't read RFC 6146 in a while but I think that you are repeating some of the recommendations that are said there. To make this document more valuable I would recommend you to go deeper  in the practical considerations when deploying NAT64.

Hope it helps,
/as

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Nov 2011 12:04:54 -0600

Hi Arturo,

I think this draft is not intended to repeat RFC 6146.

The way I understood is the draft discusses how NAT64 can be deployed in
broadband networks. Section 2.3 states a lot of requirements that Broadband
Forum may be interested in.

My question is what IDC?

Regards,

Behcet

On Mon, Nov 7, 2011 at 11:04 AM, Arturo Servin <[email-masked]>wrote:

> Gang,
>
>        I found a bit hard to see the target audience of this draft, it has
> a bit for developers and a bit for operators.
>
>        As an operator I was expecting to see some practical
> recommendations on what to do (and what not to) for deploying NAT64. I
> haven't read RFC 6146 in a while but I think that you are repeating some of
> the recommendations that are said there. To make this document more
> valuable I would recommend you to go deeper  in the practical
> considerations when deploying NAT64.
>
> Hope it helps,
> /as
>

---

From: Arturo Servin <[email-masked]>
Date: Mon, 7 Nov 2011 16:46:50 -0200

Behcet,

> I think this draft is not intended to repeat RFC 6146. 

	I know.

> 
> The way I understood is the draft discusses how NAT64 can be deployed in broadband networks. Section 2.3 states a lot of requirements that Broadband Forum may be interested in.

	There are some recommendations that are already in RFC 6146. Section 3.5 and Section 5.

	But I see no harm to repeat some of the content, my comments are that the draft could be improved by adding some other recommendations, not only the ones stated.

> Behcet

Regards,
.as

> 
> On Mon, Nov 7, 2011 at 11:04 AM, Arturo Servin <[email-masked]> wrote:
> Gang,
>

---

From: GangChen <[email-masked]>
Date: Tue, 8 Nov 2011 10:33:59 +0800

Hello Eleven Fu,

Please see my reply inline.

2011/11/7, Eleven Fu(Yu) <[email-masked]>:
> The draft is structured by different deploy positions of NAT64 as different
> modes. It describes operational process for each mode. But I think as a
> informational guide for readers, some more considerations need to be
> described for each mode in more detail, such as logging problem, ALG issues,
> DNS, load balancing etc.

That is a good suggestion. There are different considerations
regarding to different NAT64 position actually. I would like to
elaborate that in next version.

> as user tracking, Dos attack etc.

Yes. It should be added.

Many thanks

Gang

---

From: GangChen <[email-masked]>
Date: Tue, 8 Nov 2011 10:51:15 +0800

Hello Arturo,

Thanks for the comments.

> for developers and a bit for operators.

Sorry for the confusion. My intention is to help NAT64 deployment from
an operator point of view.

>
> As an operator I was expecting to see some practical recommendations on
> what to do (and what not to) for deploying NAT64. I haven't read RFC 6146 in
> a while but I think that you are repeating some of the recommendations that
> are said there.

I guess that impression is coming from the "Requirment Section".  I
agree it should be amended to be more practical, other than
implementation specific.

> To make this document more valuable I would recommend you to
> go deeper  in the practical considerations when deploying NAT64.

Thanks for the suggestion. I guess that is what Eleven suggested. I
will add more texts regarding to that.

Many thanks

Gang

---

From: GangChen <[email-masked]>
Date: Tue, 8 Nov 2011 11:04:25 +0800

Hello Behcet,

> Forum may be interested in.

IDC is a practical deployment case for NAT64. And it's getting more
and more prevalent. I adopt this as a case for NAT64 at CGN position.
A specific feature for this case is NAT64 would not only take the role
of  IPv4-IPv6 translator, but also load-balancer.

Not sure if answer your question :)

Many thanks

Gang

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Nov 2011 16:32:11 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eleven Fu(Yu)
> Sent: Monday, November 07, 2011 2:02 AM
> To: GangChen; v6ops
> Subject: Re: [v6ops] NAT64 Operational Considerations
> 
> Hi Gang,
> 
> The draft is structured by different deploy positions of NAT64 as
> different modes. It describes operational process for each mode. But I
> think as a informational guide for readers, some more considerations
> need to be described for each mode in more detail, such as logging
> problem, ALG issues, DNS, load balancing etc.
> 

Logging, user tracking, and DoS attacks are a problem with all IPv4
address sharing mechanisms -- not just NAT64.  Is 
http://tools.ietf.org/html/rfc6269 inadequate at describing 
the issues?

Are there NAT64 *specific* issues of logging, user tracking, and DoS
attacks that should be included in a document like 
draft-chen-v6ops-nat64-cpe?

-d

---

From: GangChen <[email-masked]>
Date: Thu, 10 Nov 2011 10:42:29 +0800

Hello Dan

Thanks for the comments.

> draft-chen-v6ops-nat64-cpe?

The draft has proposal a category regarding to NAT64 deployment
position. If we are talking about specific consideration for NAT64, it
may depend on the specific use cases. For example, logging has
different requirements whether NAT64 located on CGN side or CE side.
For example, NAT64 box may go beyond the operator control in CE case.
Operator may need to take extra consideration for logging. I think
that is only a tentative thought. Sorry about that. But I would like
to concrete the cases in next version.

Many thanks

Gang

2011/11/9, Dan Wing <[email-masked]>:
>> Of GangChen

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Nov 2011 19:20:09 -0800

> From: GangChen [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2011 6:42 PM
> To: Dan Wing
> Cc: Eleven Fu(Yu); v6ops

Yes, that difference is described in RFC6144, which uses the terminology
"Scenario 1: An IPv6 Network to the IPv4 Internet" and "Scenario 
3: The IPv6 Internet to an IPv4 Network" for these two cases.

> For example, NAT64 box may go beyond the operator control in CE case.

Someone operates the NAT64; just not the Internet Service Provider.

-d

> >> For section 4, some security considerations also need to be
> involved,
> >> such as user tracking, Dos attack etc.
> >

---

From: Qiong <[email-masked]>
Date: Thu, 10 Nov 2011 21:47:57 +0800

Hi Dan,

On Wed, Nov 9, 2011 at 8:32 AM, Dan Wing <[email-masked]> wrote:

> I agree there are similar issues in address sharing. But from our
deployment experience, I think it will still have different impact with
regard to IDC deployment model. Some specific considerations for NAT64
server-side deployment have been described in
draft-sunq-v6ops-contents-transition, including:
1) addressing: private address space can be provided in a controlled IPv4
network (IDC), which may further improve the scalability using 1:1 address
mapping
2) DNS: static AAAA records can be added directly in authoritative DNS
server, and this would be easier to implement in practice
3) Security: since there will be worldwide IPv6 users, some security
mechanisms e.g. acl, etc, will not be as efficient as customer-side
deployment. Additional considerations need to been taken here.
4) ALG: since the applications for a given IDC can be known in advance,
limited ALGs will been needed in this case compared to user-side
deployment.
5) Geographically aware services: For geo-location service, an open API can
be provided to ICPs to get original IPv6 address for subscribers when
needed.
6) Logging: user-level logging can be introduced to meet the practical
logging requirement for large-scale operators

I would like to have your comments as well :)

Best wishes

Qiong

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Nov 2011 07:13:25 -0800

> From: Qiong [mailto:[email-masked]]
> Sent: Thursday, November 10, 2011 5:48 AM
> To: Dan Wing
> Cc: Eleven Fu(Yu); GangChen; v6ops
> server-side deployment

Which is the "The IPv6 Internet to an IPv4 Network" scenario described
in RFC6144.

> have been described in draft-sunq-v6ops-
> contents-transition, including:
> 1) addressing: private address space can be provided in a controlled
> IPv4 network (IDC), which may further improve the scalability using 1:1
> address mapping

Yes, that is worth describing.

> server, and this would be easier to implement in practice

That is because "The IPv6 Internet to an IPv4 Network" does not
require synthesized AAAA, which was described in
http://tools.ietf.org/html/rfc6144#section-2.3

> 5) Geographically aware services: For geo-location service, an open API
> can be provided to ICPs to get original IPv6 address for subscribers
> when needed.

I like 3-6, too.  Thanks for explaining -- I now understand you are
concentrating on the "The IPv6 Internet to an IPv4 Network" scenario,
which I had previously mis-understood or I had missed.

-d

> 	> The intention is to provide comprehensive considerations for
> NAT64
> 	> deployment.
> 	> A New Internet-Draft is available from the on-line Internet-
> Drafts
> 	> directories.
> 	>

---

From: [email-masked]
Date: Fri, 11 Nov 2011 08:46:18 +0800

Hi, Mr Chen
I have read your draft, it covers most scenarios;
CGN hot-standby mechanism, Lawful interception (CC-IIF), user traceability 
and sceurity (TCP Track and Anti-DDOS) may be considered in "NAT64-CGN 
Mode Requirements"
Thanks!

Niu Qibo 牛启波
Bearer Networks Product Planning System Dept

Product Marketing System 
产品市场体系
5/B,N0.68 ZiJingHua Road,YuHua District,Nanjing,Jiangsu P.R.China, 210012
Tel:+86-25-52870483
Fax:+86-25-52870653
Email:[email-masked] 

GangChen <[email-masked]>
发件人： [email-masked]
2011-11-03 10:00
 
        收件人：        v6ops <[email-masked]>
        抄送： 
        主题：  [v6ops]  NAT64 Operational Considerations

Dear all,

I have just submitted the draft for NAT64 operational consideration.
The intention is to provide comprehensive considerations for NAT64 
deployment.
The detailed information is listed at below

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Many thanks

Gang

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: GangChen <[email-masked]>
Date: Fri, 11 Nov 2011 14:17:38 +0800

Hello Qibo,

Thanks for the comments.
That is a good suggestion. I will update in next version.

BRs

Gang

2011/11/11, [email-masked] <[email-masked]>:
> ZTE Information Security Notice: The information contained in this mail is
> solely property of the sender's organization. This mail communication is
> confidential. Recipients named above are obligated to maintain secrecy and
> are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the originator of the
> message. Any views expressed in this message are those of the individual
> sender.