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