--On Tuesday, 19 February, 2008 16:05 +0100 Iljitsch van Beijnum <iljitsch@xxxxxxxxx> wrote: > On 19 feb 2008, at 15:40, Dan York wrote: > >>> 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. Exactly > 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. 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. > 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. 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. > If the box runs a DNS resolver and mechanisms to inform hosts > about the resolver address, you can avoid the whole address > typing thing. 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 > is highly recommended. 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 _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf