RE: (ngtrans) Joint DNSEXT & NGTRANS summary

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

NAT is here and will stay irregardless of what the IETF might want.

The principal benefit of NAT to many businesses is that it is a very
effective means of cutting off approximately 80% of network security
problems at a stroke. Less functionality is precisely what these users want.


On the home user front the popularity of NAT is increasing as people
discover that a $100 box from Frys allows them to plug four computers into
the home network instead of one.


Rather than demanding that the network change to match the protocols it is
time to accept the fact that for the next twenty years at least NAT is going
to be a part of the infrastructure and look for ways in which that mode of
use can be supported without denying the end user a substantial degree of
functionality.

Since the only part of a TCP/IP session that needs the external address is
the initial setup, why not design protocols that allow that part to be
delegated to a third party 'connection server'? After all any personal
presence type protocol will need some form of static server since the user
will hop between devices even if the devices themselves had static
addresses. The trick would be to find some way to get the NAT boxes to
cooperate.

		Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Wednesday, August 08, 2001 9:15 AM
> To: alh-ietf@tndh.net
> Cc: ngtrans@sunroof.eng.sun.com; namedroppers@ops.ietf.org;
> ipng@sunroof.eng.sun.com; dnsop@cafax.se
> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary 
> 
> 
> alh-ietf@tndh.net said:
>   | Or accept the reality that enforcing PA as the 'only' 
> approach is  in
>   | direct conflict with the ultimate goals of the consumer.  
> 
> The ultimate goals of the consumer are surely to have a 
> stable internet
> connection that works, and allows all available services.
> 
> Or for many perhaps at an even higher level, to make lots of 
> money however
> it can be made, and care about very little else.
> 
> Very few ultimate consumers care at all about renumbering, 
> except to the
> extent that it interferes with one of the above real goals.   
> They care
> even less about the format of DNS resource records of course.
> 
> If renumbering is forced, and that causes problems, and NAT 
> seems to allow
> those problems to be avoided, then NAT is what people will 
> do.  Once NAT
> is seen as an inappropriate solution (which it will be once 
> people start
> wanting most of their systems to be available as servers, not 
> just clients,
> for at least some protocols) then they'll look to find 
> something else that
> works.   Geographic based addresses, with their likely 
> increased costs might
> be the solution.
> 
> Of course, if we can keep on working and get renumbering to 
> work so easily
> and cleanly that it ceases to be any kind of real cost, then perhaps
> enforcing PA won't be seen as being in direct conflict with 
> anything any
> more - as no-one (at the ultimate consumer level) will even notice it
> happening.
> 
> That's what we should be working towards, what's more, it should be an
> attainable target - there's nothing so complex about configuring an IP
> address that it needs to be seen as some kind of black art, to be done
> once and never repeated.  The only real problems are that with IPv4 we
> allowed the IP addresses to be configured everywhere, we assumed they
> were a fixture (more permanent that even a domain name, as they have
> essentially no vanity value) - and that has made the update process
> absurdly difficult.   We just need to make sure that everyone is aware
> that the only places an IPv6 address should ever be written are in the
> DNS zone files and in router configs for networks (and there, 
> in a form
> that router renumbering can update).   Anywhere else you're 
> ever tempted
> to enter an IPv6 address we need to find an alternative.
> 
> kre
> 
> 
> 
> to unsubscribe send a message to 
> namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
>

Phillip Hallam-Baker (E-mail).vcf