RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
"David R. Oran" <oran@cisco.com> Fri, 28 March 2003 19:03 UTC
Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12370; Fri, 28 Mar 2003 14:03:13 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18yzKC-0001v4-00 for ietf-list@ran.ietf.org; Fri, 28 Mar 2003 14:15:36 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18yzJS-0001tF-00 for ietf@ran.ietf.org; Fri, 28 Mar 2003 14:14:50 -0500
Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12139 for <ietf@ietf.org>; Fri, 28 Mar 2003 13:59:11 -0500 (EST)
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2SJ1UPt009645; Fri, 28 Mar 2003 11:01:31 -0800 (PST)
Received: from [10.32.254.184] (stealth-10-32-254-184.cisco.com [10.32.254.184]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id ACS51058; Fri, 28 Mar 2003 11:01:29 -0800 (PST)
Date: Fri, 28 Mar 2003 14:00:31 -0500
From: "David R. Oran" <oran@cisco.com>
To: alh-ietf@tndh.net
cc: 'The IETF' <ietf@ietf.org>
Subject: RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Message-ID: <435659204.1048860031@[10.32.254.184]>
In-Reply-To: <062101c2f558$fe15e490$ee1a4104@eagleswings>
References: <062101c2f558$fe15e490$ee1a4104@eagleswings>
X-Mailer: Mulberry/3.0.3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
Did anybody consider just handing out a /48 (or a bit smaller) automagically with each DNS registration? --On Friday, March 28, 2003 10:36 AM -0800 Tony Hain <alh-ietf@tndh.net> wrote: > John C Klensin wrote: >> Tony, >> >> I've been trying to get my mind around the various issues here, >> and I keep getting back to the same place, so I think I need to >> embarrass myself by making a proposal that I find frightening. >> >> Let's assume, as I think you have suggested, that SL is all >> about local addresses and filtering, and not about some special >> prefix that applications need to recognize. I'm still not sure >> I believe that, but let's assume it is true and see where that >> takes us. >> >> Let's also remember the long path that got us to CIDR and 1918. >> Our original position was that anyone using TCP/IP (v4) should >> have unique address space. I remember many discussions in which >> people were told "don't just grab an address on the theory that >> you would never connect. Our experience has been that, sooner or >> later, you might connect to the public network, or connect to >> someone else who has used 'private' (or 'squatter') space... >> unique addresses will save you, and everyone else, a lot of >> trouble". In that context, 1918 and its predecessors came out >> of two threads of developments: >> >> * we were running short of addresses and wanted to >> discourage unconnected (or hidden) networks from using >> up public space and >> >> * we hoped that, by encouraging such isolated networks >> to use some specific address ranges, those ranges could >> be easily and effectively filtered at the boundaries. >> >> We can debate how well either really worked, or what nasty >> side-effects they caused, but probably it makes little >> difference in the last analysis except to note that, no matter >> what we do, leaks happen. >> >> Now one of the problems IPv6 was supposed to solve was "too >> little address space" or, more specifically, our having to make >> architecturally bad decisions on the basis of address space >> exhaustion. I hope we have solved it. If we haven't, i.e., if >> the address space is still too small, then the time to deal with >> that issue is right now (or sooner), before IPv6 is more broadly >> deployed (and it better be variable-length the next time, >> because, if we are conceptually running short of space already, >> it would be, IMO, conclusive proof that we have no idea how to >> specify X in "X addresses will be enough"). >> >> But suppose we really do have enough address space (independent >> of routing issues). In that context, is site local just a >> shortcut to avoid dealing with a more general problem? Should >> we have a address allocation policy that updates the policies of >> the 70s but ignores the intermediate "we are running out" steps? >> Should I be able to go to an RIR and ask for unique space for an >> isolated network, justify how much of it I need, and get it -- >> with no promises that the addresses can be routed (and, >> presumably, without pushing a wheelbarrow full of dollars/ >> euros/ yen/ won/ yuan/...)? > > The problems with this theory are that a registry costs money to run, > and it requires an organization to expose their business plan (never > mind figuring out who is really qualified to judge the validity of any > given justification). Even when the big bad US Gov. was picking up the > tab, there were cost control measures that required someone to validate > the request (I was one such sanity checker). If we create a space that > requires registration, it will become a simple -biggest wallet gets the > most space- arrangement, because it is in the financial interest of the > registry to accept all requests. The only push back to that is to set > the price per prefix high enough that the registry doesn't need more > cash to run, but that, and the recurring nature of those costs, will > cause people to avoid the registry and use random numbers. The other > point in this is that you can't force people to register until there is > a technical reason for it, like making routing work. > >> >> Of course, this takes us fairly far onto the path of having to >> think about multihomed hosts, not just multihomed LANs, but, as >> others have pointed out, the notion of multiple addresses (or >> multiple prefixes) for a given host (or interface) takes us >> rather far down that path anyway. Figuring out which address to >> use is a problem we need to solve, with or without SL, or the >> whole idea of multiple addresses on hosts, especially dumb >> hosts, is going to turn out to be a non-starter. And, as Louis, >> Noel, and others have pointed out, it is hard. But, if we can >> find a solution, even one that is just mostly locally-optimal >> and that fails occasionally, then it seems to me that your >> position ultimately gives no advantages to a reserved site-local >> form over unique, but non-routable, addresses. The advantages >> of the latter appear obvious, starting with being able to >> identify the sources of address leaks and the notion that >> routability is a separate negotiation with providers (and their >> peers and other customers) and not an RIR responsibility. > > Leaks are a multifaceted problem. On one hand it might facilitate > tracking the source of the leak, but on another it makes it impossible > for everyone to know that this specific prefix is supposed to be > filtered. While it might be nice to believe that defining a space as > non-routable means it won't be routed, reality is that ISPs that want to > survive will do what the paying customer says. The only defense against > route-for-hire table bloat is the technical infeasibility created by > ambiguity. > >> >> That would leave another topic which I consider separate: >> whether we ought to create some number of 1918-like addresses >> that organizations that are really isolated (not connected even >> with other prefixes) can use without needing to have a >> negotiation with an RIR. The answer, I think, is probably >> "yes", but it really is a policy question, not a technical one. >> And, on the above model, an ISP offering service (and prefixes) >> to an enterprise could be expected to insist that the enterprise >> not be using any of those isolated addresses in their local >> environment. > > It is absolutely unreasonable for an ISP to tell their customer anything > about running their network that is not directely related to the > customer/provider interface. As long as the enterprise traffic over that > interface is related to the capabilities they are paying for, it is none > of the ISPs (or IETFs) business what they are doing elsewhere. > > That said, I do have a draft that globally preallocates space in an > unabmiguous way > (http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-03.txt). > This would allow use without the need to register, and if organizations > merged there would be no collision. As a side effect, when those values > were leaked into the global routing system, they can be proxy aggregated > at least at the transcontinental level. The text is currently focused at > the multi-homing problem, but it could easily be reworded. > >> >> I obviously don't understand all of the issues here well enough. >> But the traffic of the last few days has left me with the strong >> impression that SL may be an answer to the wrong question. If >> so, is the suggestion above closer to the right question? >> >> And, unfortunately, since this approach involves a change in the >> advice the IETF gives the RIRs, it probably does belong on the >> IETF list and not that of a WG. > > Eventually if policy needs to change, then yes. At this point though I > believe the fundamental issue is really about people coming to grips > with the concept that unlike IPv4, > > - all IPv6 nodes will have multiple addresses per interface. - > > Once that is understood, the noise about the cost of renumbering goes > away because that is simply the act of adding a prefix to the nodes that > care to use it. If one chooses to take the old one away at some point, > that is fine. But that step is not mandatory, which significantly > reduces the costs associated with flash cutovers. This also means that > sites that want to filter can use different prefixes for global vs. > local access and only those nodes needing global access would configure > the global prefix. As you noted earlier, it really doesn't matter what > the local use prefix is for this purpose, the only reasons for the > ambiguous one is the lack of need to register it (pay and/or expose your > business case), the ability to keep those values out of the global > routing table, and for applications that care to look, a hint that there > is a filter somewhere in the network. > > Tony > > > > _______________________________________________ > This message was passed through ietf_censored@carmen.ipv6.cselt.it, which > is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on > what to pass are made solely by Raffaele D'Albenzio. ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com
- RE: site local addresses (was Re: Fw: Welcome to … Michel Py
- Re: site local addresses (was Re: Fw: Welcome to … Ted Hardie
- Re: site local addresses (was Re: Fw: Welcome to … David Conrad
- Re: site local addresses (was Re: Fw: Welcome to … Ted Hardie
- Re: site local addresses (was Re: Fw: Welcome to … David Conrad
- Re: site local addresses (was Re: Fw: Welcome to … Ted Hardie
- Re: site local addresses (was Re: Fw: Welcome to … Andrew Newton
- Re: site local addresses (was Re: Fw: Welcome to … Daniel Senie
- RE: site local addresses (was Re: Fw: Welcome to … Christian Huitema
- Re: site local addresses (was Re: Fw: Welcome to … Stephen Sprunk
- Re: site local addresses (was Re: Fw: Welcome to … Harald Tveit Alvestrand
- RE: site local addresses (was Re: Fw: Welcome to … Jeroen Massar
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Matt Crawford
- "...handwaving arguments that "something bad migh… Jim Fleming
- RE: site local addresses (was Re: Fw: Welcome to … Christian Huitema
- Re: site local addresses (was Re: Fw: Welcome to … J. Noel Chiappa
- Re: site local addresses (was Re: Fw: Welcome to … Margaret Wasserman
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Charles E. Perkins
- RE: site local addresses (was Re: Fw: Welcome to … Tony Hain
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Tim Chown
- RE: site local addresses (was Re: Fw: Welcome to … Margaret Wasserman
- RE: site local addresses (was Re: Fw: Welcome to … Tony Hain
- RE: site local addresses (was Re: Fw: Welcome to … Margaret Wasserman
- RE: site local addresses (was Re: Fw: Welcome to … Christian Huitema
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Keith Moore
- RE: site local addresses (was Re: Fw: Welcome to … Michel Py
- Re: site local addresses (was Re: Fw: Welcome to … Eliot Lear
- RE: site local addresses (was Re: Fw: Welcome to … Michel Py
- Re: site local addresses (was Re: Fw: Welcome to … Tim Chown
- Re: site local addresses (was Re: Fw: Welcome to … Matt Crawford
- Re: site local addresses (was Re: Fw: Welcome to … Matt Crawford
- Doing "real" work Charles E. Perkins
- RE: Thinking differently about the site local pro… Tony Hain
- RE: site local addresses (was Re: Fw: Welcome to … Tony Hain
- RE: Thinking differently about the site local pro… David R. Oran
- Re: Thinking differently about the site local pro… Valdis.Kletnieks
- Re: Thinking differently about the site local pro… Keith Moore
- Re: site local addresses (was Re: Fw: Welcome to … Kurt Erik Lindqvist
- Re: site local addresses Ole Troan
- Re: Thinking differently about the site local pro… John C Klensin
- RE: Thinking differently about the site local pro… Jeroen Massar
- Re: Thinking differently about the site local pro… Bill Manning
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Bill Manning
- RE: Thinking differently about the site local pro… Jeroen Massar
- RE: Thinking differently about the site local pro… Tony Hain
- RE: Thinking differently about the site local pro… John C Klensin
- RE: Thinking differently about the site local pro… Tony Hain
- Re: site local addresses (was Re: Fw: Welcome to … Tim Chown
- Re: site local addresses (was Re: Fw: Welcome to … Kurt Erik Lindqvist
- Thinking differently about the site local problem… John C Klensin
- Re: Thinking differently about the site local pro… Margaret Wasserman
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Bill Manning
- RE: Thinking differently about the site local pro… Jeroen Massar
- Re: Thinking differently about the site local pro… John Stracke
- Re: Thinking differently about the site local pro… John C Klensin
- Re: Thinking differently Bill Manning
- Re: Thinking differently Jaap Akkerhuis
- Re: Thinking differently Bill Manning
- Re: Thinking differently Randy Bush
- Re: Thinking differently about the site local pro… Eric A. Hall
- Evolution in action (Re: Thinking differently) Harald Tveit Alvestrand
- Re: Evolution in action (Re: Thinking differently) Pekka Savola
- Re: Evolution in action (Re: Thinking differently) John C Klensin