On 19 feb 2008, at 16:25, <michael.dillon@xxxxxx> <michael.dillon@xxxxxx> 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@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf