ietf
[Top] [All Lists]

Re: ISP support models Re: IPv6 NAT?

2008-02-19 09:51:06
On 19 feb 2008, at 16:25, <michael(_dot_)dillon(_at_)bt(_dot_)com>  
<michael(_dot_)dillon(_at_)bt(_dot_)com> wrote:

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.

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
true technique of rewriting EVERY address in EVERY packet because
that is what the experts suggest.

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


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



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.

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...

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.

On 19 feb 2008, at 16:58, John C Klensin wrote:

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

Certainly you are entitled to that opinion.

How nice.

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).

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.

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.

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.

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.

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.

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.

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
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.

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
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>