ietf
[Top] [All Lists]

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

2008-11-13 16:16:41
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(_at_)employees(_dot_)org]
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(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf