Subject: Re: IPv6 NAT?

From: John C Klensin <[email-masked]>
Date: Tue, 19 Feb 2008 08:20:59 -0500

--On Monday, 18 February, 2008 16:33 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> While it is surely a factor, I believe the dominant driver
>> for NAT is  addressing autonomy.
> 
> For enterprise networks, certainly, coupled with multihoming.
> But absolutely not for SOHO networks, where the dominant driver
> is having address space for a LAN.

Brian,

I suggest that it isn't that simple.  The following drivers are,
IMO, very important for SOHO networks.  I won't try to judge
"dominant" but suggest that the first is very important to those
ISPs who provide connectivity and support to SOHO networks and
that, in many cases, they and not the end-user are the customer
for both equipment and addressing architectures.

(1) With NATs, every SOHO network (or at least every SOHO
network an ISP can claim with a straight face to support) has
exactly the same topology and addressing architecture.  That
makes customer support much cheaper because one does not have to
figure out how to parameterize the little scripts from which
people select and read.

(2) Security and address-hiding.   While we know that the
advantages of this via NAT are not significant, that hasn't
prevented the marketing hype and the selling on NATs --or NATs
plus a little packet inspection and lightweight versions of
other firewall functions-- on that basis.    If one accepts the
belief that any marketing strategy that works is unlikely to be
discontinued, this motivation for NATs won't go away.  Worse, if
we figure out how to eliminate it for IPv6, its effectiveness
for IPv4 networks will impede the deployment of IPv6.

(3) LAN configuration.  While IPv6 autoconfiguration may be a
better solution, the available user-interface and user-useable
tools for managing LANs with NAT, DHCP, and MAC addresses are
far superior to anything we have available and well-documented
for NAT-less, multiple-address-per-host IPv6.  That won't change
until the boundary devices change and due consideration is given
to the knowledge, skills, and patience of the typical "network
manager" of the SOHO network.   This is probably a non-issue as
long as all of the machines on the LAN are pure clients but, as
Keith points out, pure-client machines are fairly rare and
becoming more rare.  Certainly, as soon as one installs the
first on-LAN file server or printer, one either has to face
configuration issues or resource discovery protocols that tend
to work poorly (or at least to be confusing) as soon as there
are more than one device of a given type.

(4) Multihoming.  While it may not be general or obvious yet,
I'm seeing a slowly growing trend toward wanting to attach SOHO
networks to two (occasionally more) ISPs, whether on a
load-sharing or a fallover basis.  This is done in the hope that
both ISPs won't be incompetent on the same day and in
recognition that two "residential" connections are typically
still a lot cheaper than one "business" connection, even when
the latter comes with real support and an SLA.  There are
relatively inexpensive and relatively easy-to-manage devices on
the market that support dual connections.  They all use NATs,
even when the addresses facing one or both WANs are public.

There may be others, and probably are, but dismissing these as
unimportant is a way to become irrelevant, not to either get rid
of NATs or to encourage IPv6 deployment.

   john

_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 Feb 2008 15:11:16 +0100

On 19 feb 2008, at 14:20, John C Klensin wrote:

> exactly the same topology and addressing architecture.

Is this important? The external address(es) are still different.

> discontinued, this motivation for NATs won't go away.

There are three options:

1. Port overloading NAT
2. 1-to-1 NAT
3. Stateful firewall
4. Nothing

It looks like you're talking about 1., while most people assume that  
IPv6 requires 3. Also, IF NAT is deployed in IPv6, it's not a given  
that it's 1. rather than 2.

Personally, I'm happy with 4.

> are more than one device of a given type.

Untrue. The only problem I've ever had with stateful autoconfiguration  
is a delay when the initial router solicitation wasn't sent or  
received. With DHCP for IPv4, I've had problems on numerous occasions.  
Also, NAT is completely orthogonal to address configuration.

Service discovery still has room for improvement, but generally, it  
works quite well. The IPv6 equivalent of http://192.168.1.1/ to  
configure some piece of equipment isn't fully formed yet, but it  
certainly doesn't require NAT, even if it requires stable addressing  
and more sane service discovery can't be used for some reason.

> even when the addresses facing one or both WANs are public.

Really? I've never seen such a box. NAT of course completely breaks  
multihoming because your sessions die when there is a rehoming event.  
I'd much rather run shim6, which requires nor supports NAT.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Dan York <[email-masked]>
Date: Tue, 19 Feb 2008 09:40:49 -0500

> Is this important? The external address(es) are still different.

Sure, but the home internal networks are identical.  So Homeowner A  
calls up the ISP support and is having a problem getting a machine to  
work with the wireless router provided by the ISP.  So the ISP tech  
says "on a working machine, point your browser to 192.168.10.1 and...."

A while later Homeowner B calls in with a similar problem. The ISP  
tech says "on a working machine, point your browser to 192.168.10.1  
and..."  Same with Homeowners C, D, E and so on.

The variables are reduced to the smallest number so that the tech  
support issues can be reduced to as few as possible. The responses to  
those issues can then be scripted so that call center folks with  
minimal knowledge of the subject can assist (or the entire support  
operation can be outsourced to some remote call center).

So for those ISPs that do this, using NAT to have identical home  
networks is a beautiful thing.  Keeps their costs low and hopefully  
their customer satisfaction high.  (Of course, probably exactly  
*none* of those of us on this list have such an ISP since we all like  
to mess with our own networks.)

Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 Feb 2008 16:05:40 +0100

> calls up the ISP support and is having a problem getting a machine  
> to work with the wireless router provided by the ISP.  So the ISP  
> and...."

> and..."  Same with Homeowners C, D, E and so on.

I'm not buying that this is so important that it's worth having a box  
rewrite EVERY address in EVERY packet for.

If you really want this, you can simply create a loopback interface  
with address fc00::1 on it and users can type "http://[fc00::1]/" (ok,  
so the brackets are annoying, but no NAT helps against that) and the  
users can connect to that address regardless of what the addresses  
used on the LAN are.

If the box runs a DNS resolver and mechanisms to inform hosts about  
the resolver address, you can avoid the whole address typing thing.

And of course the use of a proper service discovery mechanism is  
highly recommended.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Tue, 19 Feb 2008 15:25:52 -0000

> I'm not buying that this is so important that it's worth 
> having a box rewrite EVERY address in EVERY packet for.
> 
> If you really want this, you can simply create a loopback 
> interface with address fc00::1 on it and users can type 
> "http://[fc00::1]/" (ok, so the brackets are annoying, but no 
> NAT helps against that) and the users can connect to that 
> address regardless of what the addresses used on the LAN are.
> 
> If the box runs a DNS resolver and mechanisms to inform hosts 
> about the resolver address, you can avoid the whole address 
> typing thing.
> 
> And of course the use of a proper service discovery mechanism 
> is highly recommended.

If nobody writes all of this up into a set of guidelines
for implementors of SOHO IPv6 gateways, including some more
details on a proper service discovery mechanism, then it isn't
going to happen. Implementors will just go with the tried and 
true technique of rewriting EVERY address in EVERY packet because
that is what the experts suggest.

If you want to let them know that the real experts suggest something
different, then at minimum, an RFC should be published. However I'm
beginning to believe that we need more than just a few good RFCs 
with guidelines for IPv6 gateways and middleboxes. We probably also
need some books, magazine articles, conference presentations etc.
to back it up. And the presentations need to be at conferences like
this one <http://www.date-conference.com/> not at the IETF meetings.

And this one <http://www.realtimelinuxfoundation.org/>
and this <http://www.embedded.com/>

--Michael Dillon

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 19 Feb 2008 09:30:25 -0600

Hi, Iljitsch,

I'm confused...

From: "Iljitsch van Beijnum" <[email-masked]>

> users can connect to that address regardless of what the addresses

Were you thinking that the loopback interface would be on the "working 
machine" Dan mentioned, or the inner interface on the LAN router device (in 
my case, 192.168.10.1 would be my wireless router plugged into my cable 
modem) that is having connectivity issues on its outer interace?

Because I'm almost sure the second case is what Dan's talking about...

Thanks,

Spencer

---

From: John C Klensin <[email-masked]>
Date: Tue, 19 Feb 2008 10:58:21 -0500

--On Tuesday, 19 February, 2008 16:05 +0100 Iljitsch van Beijnum
<[email-masked]> wrote:

>> Sure, but the home internal networks are identical.  So
>> Homeowner A   calls up the ISP support and is having a
>> problem getting a machine   to work with the wireless router
>> provided by the ISP.  So the ISP   tech says "on a working
>> machine, point your browser to 192.168.10.1   and...."
> 
>> A while later Homeowner B calls in with a similar problem.
>> The ISP   tech says "on a working machine, point your browser
>> to 192.168.10.1   and..."  Same with Homeowners C, D, E and
>> so on.

Exactly

> having a box rewrite EVERY address in EVERY packet for.

Certainly you are entitled to that opinion.  As Dan suggests,
you probably don't have such a network or a need for it because
you, like many of the rest of us, like to fuss with
configurations or at least know how.  I would guess, just
judging from your notes to this list, that it has been a very
long time since you have called your ISP looking for help that
turns out to be about configuration of your LAN (probably as
long as it has been for me, i.e., never).  

However, in much of the world, profit margins for ISPs in the
residential and SOHO business are sufficiently thin that a
single support call can wipe out a few month's of profits from
that account and one that actually requires getting someone with
knowledge on the phone can wipe out a year or more.   If one is
that ISP and has to make a choice between avoiding
	
		* the costs of even a few more support calls
		
	and
	
		* the costs of a box (whose cost is incurred by the
		user, not the ISP, or immediately passed on to the user)
		and some reduced performance in the user's connection
		(which, at worst, might induce the user to buy more
		bandwidth)

	the question of whether this is "so important" or even
	"important enough" is an absolute no-brainer: the
	standardized NAT configuration provides nothing but an
	upside for you (the ISP) and no downside that you care
	at all about.

Sorry, life is hard sometimes and overall network rationality
doesn't help much.

> address regardless of what the addresses used on the LAN are.

I'm not sure this helps in any useful way, since the concern
isn't reaching the home host but another host/ server (even if
only a local server) on the same LAN.  

See the aside below, but, if our recommendation for moving from
IPv4 to IPv6 involves training a user who has gotten used to
typing, e.g., "http://10.0.0.5", or maybe just "10.0.0.5", to
type http://[fc00::1]/" we will have inserted another stumbling
block on the way to IPv6 deployment.

> about the resolver address, you can avoid the whole address

Sure.  And I continue to be surprised that the current crop of
"home/SOHO router"  boxes don't automagically support local DNS
with a fixed set of addresses, local names, and SRV records, as
well as a LAN-boundary full-service resolver and cache.   But it
hasn't happened, which may or may not tell us something else
that we should be worried about.
 
> And of course the use of a proper service discovery mechanism

Of course.  I'd also like a new pony.

Seriously (and this is the aside referred to above), I think we
are going to be in big trouble wrt IPv6 deployment at the
residential and SOHO sides of the market unless we figure out
how to provide local DNS services _and_ very strongly discourage
the use of numeric addresses in any application protocol.  We've
already got guidance against literal address use out there, but
we keep writing notes --if only to each other-- that say "no
problem, just type this increasingly-complicated address".  In
actual practice (i.e., regardless of what the standard says
about what is permitted) we have already pretty much deprecated
address literals in email addresses.  I believe that the HTTPbis
effort should deprecate their use in URLs and that we should be
moving toward deprecating their use in URIs entirely.

There is some strangeness about all of this "the user and
application should figure out how to work with and manipulate
literal addresses" stuff vis-a-vis the original decisions to
adopt what became IPv6.  To some extent, the applications folks
were told that, as long as they used names and called on TCP,
the transition to IPv6 would be largely transparent to them and
their applications and they signed off on IPv6 on that basis.
Now we are coming along and saying, effectively, that
applications have to be able to apply fairly complex algorithms
--algorithms that require some network topology knowledge-- to
sort out which addresses they are expected to use and that end
users are going to need to type IPv6 addresses (and maybe
understand their structure and other idiosyncrasies) to make
applications work well.  IMO, if IPv6 deployment is dependent on
either of those conditions, we might as well stop having this
discussion because it just won't happen.

      john

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 Feb 2008 17:50:03 +0100

On 19 feb 2008, at 16:25, <[email-masked]>  
<[email-masked]> wrote:

> going to happen.

Well, I was working in that direction:

http://psg.com/lists/v6ops/v6ops.2008/msg00086.html

However, I'm not getting the type of feedback that I need (i.e., from  
people running IPv6 ISP networks or building IPv6 CPEs, arguably,  
those people may not exist) so I hesitate to proceed.

> Implementors will just go with the tried and

Hm, in my book, suggesting that automatically disqualifies the  
suggester as an expert.

On 19 feb 2008, at 16:30, Spencer Dawkins wrote:

> Because I'm almost sure the second case is what Dan's talking about...

Yes, and that's what I'm talking about, too. I sometimes forget that  
not everyone spends their days configuring routers  :-)  where  
loopback interfaces have a very different function than they do on  
hosts. Since you're sending all your packets to the router, the  
packets addressed to the router's FC00::1 address, which is tied to  
the loopback interface simply because loopback interfaces never go  
down, will be processed locally so you get to manage the router.  
Obviously this only works for your default gateway, and, as I said  
before, a good service discovery mechanism is still a very good idea.

> Certainly you are entitled to that opinion.

How nice.

> As Dan suggests,

Right, how would my ISP know how my LAN is configured?

Also, as a general rule I avoid support calls because they are  
invariably a waste of time.

> knowledge on the phone can wipe out a year or more.

And you think this works in FAVOR of NAT?

The whole point of avoiding support calls is that everything works  
without trouble in the first place. Telling someone how to type in a  
URL to get at their device configuration is something you should avoid  
at almost any cost, because best case, it wastes time, worst case the  
user simply can't do it. I'm not kidding here.

My current ISP (who forces me to use IPv4 NAT) lets me manage my port  
mappings through their website. Much smarter: if I were to call them,  
they could easily look inside their own system and fix things, rather  
than tell me to go into the box and do it.

> block on the way to IPv6 deployment.

Hence the need for a decent service discovery mechanism.

I was merely illustrating the fact that there are MANY ways to arrive  
at the desired result that do not require NAT. They're not all  
especially great, but so far, nobody has been able to show how having  
NAT makes this better. Without service discovery or a DNS or external  
connectivity, you would still have to type a URL like above.

> the use of numeric addresses in any application protocol.

Allow me to take exception to the "numeric" part. Everyone knows how  
to type numbers. Even people who use languages that use different  
character sets. Even most people that aren't really literate can  
handle numbers. They can be unambiguously pronounced and are very  
easily kept in canonical form. You really can't do better than  
numbers, it's text that's always a mess.

> In

Microsoft is way ahead of you: Internet Explorer doesn't take literal  
IPv6 addresses. I fail to see how the inability to do something that  
you may not want to do all that often (for good reasons) is a good  
thing, though. It's much better to make things such that users don't  
HAVE to type addresses. Such as having a good service discovery  
mechanism.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Dan York <[email-masked]>
Date: Tue, 19 Feb 2008 12:08:49 -0500

> than tell me to go into the box and do it.

DY> Yes, you will undoubtedly get better customer service from ISPs  
who provide management of the SOHO endpoints (whether or not that is  
through a "managed services" offering or just their default  
operational style).  I would expect most smart ISPs are moving in  
that direction.  But there will certainly be those out there who don't.

DY> For those who don't manage the remote router/gateway, having an  
identical address pool for each location could be a useful way to  
minimize support issues.

DY> Forgetting about ISPs, for a moment, let's think about equipment  
vendors.  If you think of all the zillion Linksys (or D-Link or  
whomever) home gateways... all of which are probably using  
192.168.0.1 or whatever is the default address block. The fact that  
they are all identical makes *their* technical support issues much  
easier to address.  And in this case they probably have no way to  
manage those devices remotely.

> connectivity, you would still have to type a URL like above.

DY> I don't know that any of us are saying that "having NAT makes  
this better".  I'm saying that having NAT is a *reality* in the  
corporate network environment and I personally expect that it will  
continue to be used in those environments  after the IPv6 transition.  
(For reasons I've previously expressed.)

DY> So, in my view, the IETF has the option of addressing how to  
properly do NAT for IPv6 for those people out there who may wish to  
do so - or NOT addressing IPv6 NAT and letting equipment vendors and  
customers make it up as they go along.

Regards,
Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Feb 2008 10:59:25 +1300

> users can connect to that address regardless of what the addresses  

I think we had this conversation recently and the answer was to make
the CPE's link-local URL something like http://[fe80::1]/. That's actually
fewer characters for the help desk to dictate than 192.168.10.1

The default case can be made automatic, as far as I can see, without
blocking the potential for non-default cases. All the issues John Klensin
mentioned need to be handled. We should take note of this:

On 2008-02-20 04:25, [email-masked] wrote:
...
> details on a proper service discovery mechanism, then it isn't

Hopefully the starting point will be in v6ops.

   Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 19 Feb 2008 17:22:12 -0600

Hi, Iljitsch,

>>> with address fc00::1 on it and users can type "http:// [fc00::1]/" (ok,
> Yes, and that's what I'm talking about, too. I sometimes forget that  not 
> everyone spends their days configuring routers  :-)  where  loopback 
> interfaces have a very different function than they do on  hosts. Since 
> you're sending all your packets to the router, the  packets addressed to 
> the router's FC00::1 address, which is tied to  the loopback interface 
> simply because loopback interfaces never go  down, will be processed 
> locally so you get to manage the router.  Obviously this only works for 
> your default gateway, and, as I said  before, a good service discovery 
> mechanism is still a very good idea.

Ah - thanks. Since we were talking about the user's view from a host, I was 
off in RFC 3330-land.

Thanks,

Spencer, who was thinking of

   127.0.0.0/8 - This block is assigned for use as the Internet host
   loopback address.  A datagram sent by a higher level protocol to an
   address anywhere within this block should loop back inside the host.
   This is ordinarily implemented using only 127.0.0.1/32 for loopback,
   but no addresses within this block should ever appear on any network
   anywhere [RFC1700, page 5].