Subject: [BEHAVE] draft-jiang-incremental-cgn-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2009 12:12:44 +1300

This draft was discussed in v6ops, but the authors would be interested
in comments from BEHAVE as well. We'll start working on the next version
in a couple of weeks, so please comment soon.

The slides are at
http://www3.ietf.org/proceedings/09mar/slides/v6ops-7.pdf

    Brian

---

From: Shin Miyakawa <[email-masked]>
Date: Thu, 26 Mar 2009 08:26:35 +0900 (JST)

Brian,

This looks simlar to a (potential) transition scheme
I showed at IETF72 Technical prenaly.

http://www.nttv6.jp/~miyakawa/IETF72/IETF-IAB-TECH-PLENARY-NTT-miyakawa.pdf

My example uses NAT444 + Softwire to achieve the goal.

Best wishes,

Shin Miyakawa

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Mar 2009 22:57:43 -0700

This document appears to be in very good shape for a
-00 draft, and I have only one observation for now. In
Section 3, the sentence: "...NAT-PT [RFC2766, RFC4966]
(or its replacement) can be integrated with CGN." - I
am wondering here whether a NAT-PT or equivalent
function could also reside within the Dual-Stack
Home Gateway (HG) such that the state maintenance,
DNS, fate sharing, etc. is kept close to the hosts?

Then, let the CGN become a dual-stack IPv6 router, and
the ISP network can be traversed via an IPv6/IPv4 tunnel.
Consider also that tunnels could go from HG(A) to HG(B)
within the same ISP network. Only the HGs and CGNs
are touched while the ISP network can remain as IPv4,
so the scenario begins to look very much like VET.

In this sort of arrangement, for an IPv4-only host in
the home network connecting to an IPv4 server in the
Internet, the HG just lets it go as IPv4 using NAT44.
For an IPv4-only host connecting to an IPv6 server,
however, the HG's NAT-PT function (or equivalent) would
establish the necessary state such that IPv4 packets
going out are translated to IPv6, and IPv6 packets
coming in are translated to IPv4.

For an IPv6-only host in the home network connecting
to an IPv6 server, the HG just lets it go as IPv6,
tunneled over IPv4 in the ISP network if necessary.
For an IPv6-only host connecting to an IPv4 server,
however, discover the server's address ('a.b.c.d')
and map it to a special-use IPv6 /96 prefix, e.g., as
"f00::a.b.c.d/96". Let the CGN advertise reachability
to "f00::/96" such that the HG's IPv6 packets are
conveyed to the CGN. The CGN then translates the
IPv6 packets going out into IPv4 packets, and uses
NAT44 to forward them on to the IPv4 server (with
IPv4-to-IPv6 translation in the reverse path). In
this sense, "f00::/96" represents the entire IPv4
Internet.

So, there are two seperate and complimentary NAT-PT
(or equivalent) functions - one in the HG and one in
the CGN - but each presents a slightly different
service model as described above. Is this something
like what you had in mind?

Fred
[email-masked]  

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, March 25, 2009 4:13 PM
> To: Behave WG
> Cc: [email-masked]
> Subject: [BEHAVE] draft-jiang-incremental-cgn-00.txt
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2009 03:39:19 +1300

Fred,

Thanks for your comment. I think placement of NAT64 functions
will be an interesting discussion - essentially you seem to be
suggesting that in the 'IPv4 network connects to IPv6 Internet'
scenario, the IPv4 network is limited to whatever is behind
an individual CPE. That does appear to have a scaling advantage,
but on the other hand it's a lot of extra logic to be shoved
inside a $99 CPE.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Mar 2009 09:01:05 -0700

Brian,

> Sent: Thursday, March 26, 2009 7:39 AM
> To: Templin, Fred L
> Cc: Behave WG; [email-masked]
> Subject: Re: Comments on draft-jiang-incremental-cgn-00.txt
> 
> Fred,
> 

I'm not a CPE vendor, but it seems simpler and more robust
to have everything self-contained in the same box - fewer
moving parts, and fewer things to go wrong.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Mar 2009 10:11:54 -0700

Sheng,

> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Thursday, March 26, 2009 9:27 AM
> To: Templin, Fred L; 'Brian E Carpenter'; 'Behave WG'
> Subject: [BEHAVE] ***SPAM*** 7.569 (5) 答复: Comments on draft-jiang-incremental-cgn-00.txt
> 
> Hi, Templin,
> 
> Thanks for your comments. When we wrote the draft, we mainly meant traffic
> went through NAT-PT after CGN aggregation. However, I also agree what you
> describe can work: NAT-PT or equivalent function can also be integrated
> within CPE. Actually, this scenario may avoid some performance issue in CGN
> by reducing the maintaining burden for stateful NAT-PT mapping. On another
> side, I am also concerned it may increase CPE's complication, and also the
> network management complication.

I'm not sure that it would be so bad. The CPE already has
to provide DNS services, so how bad would it be to have it
also set up NAT state based on the DNS queries. The CPE is
also closest to the hosts that need the service, so the
fate sharing balance seems better.

So, with IPv4-only hosts behind a CPE that does something
like NAT-PT, wouldn't it be better to up-convert to IPv6
at the CPE itself?

Fred

> 
> Sheng
> 
> > -----邮件原件-----
> > 发件人: Templin, Fred L [mailto:[email-masked]]
> > 发送时间: 2009年3月26日 13:58
> > 收件人: Brian E Carpenter; Behave WG
> > 抄送: [email-masked]
> > 主题: Comments on draft-jiang-incremental-cgn-00.txt
> >