Subject: RE: [Ietf-behave] Twice NAT _must_ be in-scope

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Dec 2004 08:14:17 -0800 (PST)

I think just removing the statement about Twice-NAT is the way to go.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] 
> Sent: Wednesday, December 08, 2004 22:25
> To: Cullen Jennings
> Cc: Bryan Ford; Audet, Francois [SC100:9T51:EXCH]; Pyda 
> Srisuresh; Behave
> Subject: Re: [Ietf-behave] Twice NAT _must_ be in-scope
> 
> 
> I agree that we need to cover the situation Bryan is talking 
> about, but 
> I have heard this called "cascaded NAT" or "multi-layer NAT" or some 
> equivalent. To answer Cullen's question, I think twice NAT is quite 
> different, as it specifically involves DNS tricks to deal 
> with address 
> collisions between two domains. See section 4.3 of rfc2663. I don't 
> think we need to deal with twice NAT as defined in rfc2663; 
> its really 
> awful and not that common (AFAIK).
> 
> Thanks,
> Jonathan R.
> 
> Cullen Jennings wrote:
> 
> > On 12/8/04 2:06 PM, "Bryan Ford" <baford@xxxxxxx> wrote:
> > 
> > 
> >>Traditional NATs being combined on the Internet in a hierarchical 
> >>fashion. For example, consider the standard scenario: an ISP gets a 
> >>few public IP addresses from its upstream provider, and uses 
> >>Traditional NAT to create lots of private IP addresses for its 
> >>customers.  Many of the ISP's customers, then, 
> **independently and of 
> >>their own volition**, deploy their own Traditional NATs to 
> create home 
> >>networks.  We now have a Twice NAT network scenario, even 
> though all 
> >>of the actual NAT boxes in use are just ordinary Traditional NATs.
> > 
> > 
> > I agree this scenario is definitely in scope but I get confused by 
> > some of the terminology at times. Is this what RFC 2663 would call 
> > twice NAT?
> > 
> > _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Dec 2004 10:38:46 -0800 (PST)

I think that twice-nat as described in 2663 is out of scope of this document. It's like static NAT in that what do you say about it. 

On 12/9/04 8:13 AM, "Francois Audet" <audet@xxxxxxxxxxxxxxxxxx> wrote:

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Dec 2004 13:12:25 -0800 (PST)

Cullen,

Are you saying that Static NATs shoudl be out of scope? If so, I disagree. What
is the reason for taking static NAT out of scope? Many NAT boxes do have an
ability to configure static  address/port mapping. I believe, static NATs
shoudl be within scope.

>From what I can tell, much of the recommendation to NAT vendors centers around
requiring them to maintain address/port binds. I would like all NAT vendors to
carry the theme, whether twice-NAT, NAT-PT or bi-directional NAT. I really dont
see substantial benefit in restricting the discussion scope to traditional
NATs. That is my 2c.

regards,
suresh

--- Cullen Jennings <fluffy@xxxxxxxxx> wrote:

> 
> I think that twice-nat as described in 2663 is out of scope of this
> document. It's like static NAT in that what do you say about it.
> 
> 

=====

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Dec 2004 13:37:41 -0800 (PST)

I don't really know what the definition of static nat is but if static nat
is that a packet that arrives at a particular address/port on the outside of
the NAT gets forwarded to some configured address/port on the inside then I
don't know what to say about this. Yes that exists. Many people implement
it. It's described in other documents. What are NATs doing today with static
port forwarding that we thinks need further clarification? What behavior
would we like to clarify or change? There may very well be clear answers to
this but so far no one seems to have brought them up so that's why Francois
and I had tried to get this document to focus on the non deterministic
properties that were causing application problems.

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 9 Dec 2004 18:25:14 -0800 (PST)

Cullen,

You make a good point. However, BEHAVE recommendations is not all about
static/dynamic port bindings. For example, the UDP behave draft recommends
support for hairpin behavior. The draft also recommends support for IP
fragmentation. Why should static NATs be excluded for these and other such
requirements?

regards,
suresh

=====

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 Dec 2004 13:05:19 -0800 (PST)

> fragmentation. Why should static NATs be excluded for these and other such

Yes I agree with you that various things types of NATs may want to do many
of the same things. I just don't want to take on, in this document,
describing all the things one might want to do on a twice-nat to give
applications the best odds of working. You make a good point that
fragmentation and loopback are examples of things that all NATs might want
to deal with in a similar way. Just trying to take this in small bite size
pieces.

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 10 Dec 2004 17:53:47 -0800 (PST)

Cullen,

May be, you guys went over this before already. If so, my apologies. But, why
not include all NAT types in scope - including Twice-NAT, bi-directional NAT
and NAT-PT. From what I had seens of the documents so far, I believe, all of
the recommendations we set out for tarditional NATs are applicable to other
types of NATs equally well. By includign all NAT types, NAT vendors woudl not
have to be concerned that there are no recommendations for certain types of
NATs on what would constitute a good behavior. I believe, with little extra
effort, we can identify recommendations that would be applicabel across all NAT
types. There will always be boxes that take different NAT incarnations,
depending upon how the box is configured.

Thats my 2c. Thanks.

regards,
suresh 

=====