RE: [BEHAVE] Can we have on NAT66 discussion?

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: Re: [BEHAVE] Can we have on NAT66 discussion?

Well yes, that is precisely the reason I beleive that we need to take a look at a higher level and decide on one single answer to questions such as:

 

* What describes the boundary between the network and the inter-network?

* How does a client endpoint connect to a service endpoint?

* How does a sevice endpoint advertise its existence at the network border?

 

I know that I can give clear and concise answers to these questions, but I think many who argue against the concept of NAT prefer not to think about them.

 

The single answer to the service endpoint discovery problem in my view is that it is a DNS infrastructure problem and no other infrastructure should be involved, certainly not IP. By infrastructure here I am taking account of the fact that we might in theory replace the DNS protocol, but only if the result was transparent at a logical level.

 

Many of the problems with NAT result from the fact that we have protocols such as FTP that use the IP address and port to pass a pointer to a service endpoint - yuk!

 

Another set of problems come from the fact that by default a NAT box will block incomming connections. This is in many cases exactly the intended outcome, but not always. It would be really nice if there was actually a practical, interoperable video conferencing system that works peer-to-peer through NAT at both ends.

 

---

From: Scott Brim [mailto:swb@xxxxxxxxxxxxx]
Sent: Thu 11/13/2008 11:51 AM
To: Hallam-Baker, Phillip
Cc: Mark Townsley; Eric Klein; Routing Research Group Mailing List; Behave WG; v6ops@xxxxxxxx; ietf@xxxxxxxx
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?

On 11/13/08 10:06 AM, Hallam-Baker, Phillip allegedly wrote:
>
> I beleive that the question would not arise If we had a coherent
> Internet architecture
> 
> The idea that an application can or should care that the IP address of a
> packet is constant from source to destination is plain bonkers. It was
> no an assumption in the original Internet architecture and should not be
> an assumption that any application should rely on.

That's not the problem.  The issue is location.  Once we have
established a session then how the packets are labeled for network layer
purposes doesn't matter much (modulo security) but how do we get
communications set up in the first place?  Suppose I want to reach
"foo".  Who do I ask to find a locator for him?  Split DNS works fine
when there are just two states, inside and outside -- a DNS server can
be configured to know how to respond in each case.  But if you were to
sprinkle NATs all over the Internet there would be no place that could
give a confident answer about how I, over here, should name foo in the
network layer in order to get a packet to him, and have that answer get
to me in the correct form.  So it is very important to understand where
we think it might be safe to put what kinds of NATs.

swb

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf