Subject: [BEHAVE] draft-nishitani-cgn-00.txt

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 Jul 2008 09:42:56 -0700

This draft is probably interesting for many people in BEHAVE.

-d

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, July 02, 2008 2:45 AM
To: [email-masked]
Subject: I-D Action:draft-nishitani-cgn-00.txt 

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

	Title           : Carrier Grade Network Address Translator (NAT)
Behavioral Requirements for Unicast UDP, TCP and ICMP
	Author(s)       : T. Nishitani, S. Miyakawa
	Filename        : draft-nishitani-cgn-00.txt
	Pages           : 15
	Date            : 2008-07-02

This document defines basic terminology for describing different
types of carrier-grade Network Address Translation (NAT) behavior
when handling Unicast UDP, TCP and ICMP.  Developing carrier-grade
NATs that meet this set of requirements increase transparency of data
between carrier networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nishitani-cgn-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Tomohiro Nishitani" <[email-masked]>
Date: Thu, 03 Jul 2008 13:52:00 +0900

Hi Dan:
Thank you for the introducing our draft.
The main target of the draft is 4-4-4 model which uses IPv4
address both internal and external side of CGN.
[I-D.durand-v6ops-natv4v6v4] describes 4-6-4 model, and CGN may apply
to 4-6-4 model.

> ------------------------------------------------------------------------
>

-- 

Tomohiro Nishitani
Chief, Network Systems and Technologies,
Innovative IP Architecture Center
NTT Communications Corporation
[email-masked]
TEL: +81-3-6800-3214

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 3 Jul 2008 10:44:16 +0300

Dear Tomohiro Nishitani-san,

> This draft is probably interesting for many people in BEHAVE.

| The main target of this document is 4-4-4 model which uses IPv4
| address both internal and external side of CGN.
| [I-D.durand-v6ops-natv4v6v4] describes 4-6-4 model, and CGN may apply
| to 4-6-4 model.

There are v4/v4 NAPTs. Your document does not seem to require anything from 
the CPE for the benefit of the CGN - contrary to Alain Durand's 4-6-4 model.

Hence, I personally feel it is not appropriate to refer to this as a "4-4-4 
model". Your draft really seems to be a plain 4-4 model: I could replace the 
CPE with a plain IPv4-only host and it would work all the same.

| REQ-1: A CGN MUST allocate one external IP address to each CPE.

To me, this means that the C-G NAT is doing 1:1 address translation. I suppose 
this is not the intent.

| a) CGN external IP address of the UDP, TCP and ICMP MUST be same.

*Empirically*, I would warn you against upsetting our dear IETF Transport area 
directors and some other IETF attendees for restricting a new network element 
to UDP, TCP and ICMP :)

| a) A CGN MUST NOT overload CGN external port while a NAT UDP
|    mapping timer does not expire.

Because I have been following the BEHAVE working group recently, I know what 
this means. IMHO, however, you should really define "overload".

(...)

| A carrier MAY introduce TURN [I-D.ietf-behave-turn] to support
| communications among CPEs.  If CGN supports "Hairpinning", CGN can
| hairpin the communications between CPEs in the same CGN.  Therefore
| the requirements of Hairpinning for CGN MAY reduce requirements for
| the performance of TURN servers.  When CPEs decide the course of UDP
| between CPEs, CPE MAY use [I-D.ietf-mmusic-ice] .

I don't understand this. If the CGN supports hairpinning, there is no need to 
deploy TURN for hairpinning. And if the CPE does not support hairpinning, 
adding a TURN server close to the CGN does not really help with it.

It would be much simpler to require that the CGN supports hairpinning.

Regards,

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Tomohiro Nishitani" <[email-masked]>
Date: Thu, 03 Jul 2008 17:43:03 +0900

> It would be much simpler to require that the CGN supports hairpinning.
I suppose that a carrier has dozens of CGNs and CGNs are placed in each
prefecture.
In this case, a CPE may need to use TURN if CPE wants to communicate the
CPE
which belongs to other CGN.
And if a CPE communicates the CPE which belongs to same CGN,
it is no need to use TURN.

Tomohiro Nishitani
-- 

Tomohiro Nishitani

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 3 Jul 2008 12:02:33 +0300

On Thursday 03 July 2008 11:43:03 ext Tomohiro Nishitani, you wrote:
> > I don't understand this. If the CGN supports hairpinning, there is no
> > need to deploy TURN for hairpinning. And if the CPE does not support
> > hairpinning, adding a TURN server close to the CGN does not really help
> > with it.
> >
> CPE which belongs to other CGN.

If two CPEs are behind distinct CGNs, then it will work like normal Internet.

I don't see the use of TURN here, so long as the CGN are BEHAVE-compliant.

---

From: "Tomohiro Nishitani" <[email-masked]>
Date: Mon, 07 Jul 2008 15:26:16 +0900

Hi,
> I don't see the use of TURN here, so long as the CGN are BEHAVE-compliant.
The description of TURN is infomation about NAT traversal of Carrier
Grade NAT(CGN).
What I want to say is that most of CPEs can use UDP hole punching even if
there is a CGN over CPEs.

Regards,

Tomohiro Nishitani

-- 

Tomohiro Nishitani