Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
John C Klensin <john-ietf@jck.com> Fri, 28 March 2003 21:24 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 QAA19451; Fri, 28 Mar 2003 16:24:35 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18z1Vh-0007wn-00 for ietf-list@ran.ietf.org; Fri, 28 Mar 2003 16:35:37 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18z1V5-0007ug-00 for ietf@ran.ietf.org; Fri, 28 Mar 2003 16:34:59 -0500
Received: from bs.jck.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19314 for <ietf@ietf.org>; Fri, 28 Mar 2003 16:19:18 -0500 (EST)
Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 18z1I7-000KpW-00; Fri, 28 Mar 2003 16:21:35 -0500
Date: Fri, 28 Mar 2003 16:21:35 -0500
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@cs.utk.edu>, "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu>
cc: "oran@cisco.com" <oran@cisco.com>, "ietf@ietf.org" <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: <95119875.1048868495@p3.JCK.COM>
In-Reply-To: <20030328145401.7cb6f1d4.moore@cs.utk.edu>
References: <062101c2f558$fe15e490$ee1a4104@eagleswings> <435659204.1048860031@[10.32.254.184]> <200303281911.h2SJB7FD012199@turing-police.cc.vt.edu> <20030328145401.7cb6f1d4.moore@cs.utk.edu>
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
--On Friday, 28 March, 2003 14:54 -0500 Keith Moore <moore@cs.utk.edu> wrote: >> > Did anybody consider just handing out a /48 (or a bit >> > smaller) automagically with each DNS registration? >> >> Routing Table Bloat. If you can figure out how to do this in >> a CIDR aggregation context, or otherwise work around the >> table problem, the IETF and NANOG will quite certainly >> jointly nominate you for sainthood. ;) > > ...right after you get lynched for heresy. yeah, well... Tony is right -- any registration process costs resources. But, if these addresses are assumed to be not routable, then there shouldn't be any routing table bloat. Put differently, once can conceive of three ways to get addresses: * From an RIR, as PI space * From an ISP, as PD CIDR space. ISPs might sensibly decide to charge less (in money or aggravation) for space which no one intended to route. Or might not: the marketplace is good at sorting out these things, as long as the RIRs are willing to make allocations to ISPs that reflect the desirability of having addresses for isolated networks unique and reflecting the ISPs to which they might ultimately connect. * From some other process, as long-prefix, almost certainly unroutable, isolated space. This process could presumably be designed to be very lightweight in charges and administrative costs. So, while I'm very hesitant about anything that ties addressing (of any sort) to DNS names, I'm not convinced that Dave's suggestion is worth dismissing out of hand. Three additional observations: (i) Tony's response to my note seems, to me, to turn SL largely into a policy problem, not a technical one. We haven't have really good success binding policies into protocols. That doesn't convince me that we should never do so, but it does seem to argue for looking at alternatives, even radical ones. (ii) ISPs impose restrictions on their customers all the time and often even enforce them. Many of us consider some of these to be desirable (e.g., terms and conditions prohibiting spamming) and others less so (e.g., prohibitions against running server or peer-peer protocols over a cable network or address restrictions that force reasonably-architected LANs into NAT arrangements) but the conditions clearly exist. (iii) Yes, if I have an odd address and sufficient money, I can almost certainly convince some ISP to route it. But that ISP's leverage to get its peers to accept any long-prefix addresses it happens to offer and route them may be distinctly limited, especially if, by offering/announcing those addresses, it is violating a well-understood policy against doing such things. (For example, an RIR policy that made PI address allocations much more difficult for ISPs who were guilty of routing table pollution by short prefixes could really focus the attention.) So it seems to me to be plausible to suggest that the right place to prevent routing table explosion (or even "bloat") is in routing decisions and acceptance of announcements, and not in creating special address scopes. I also note that site local addresses open up a whole series of questions about "locality" and scope-range. Perhaps we also need "ISP-local" addresses (routing into one ISP's space, or part of it, but not to that ISP's peers or transit customers) and so on. The one thing that can be guaranteed about that sort of arrangement is an extension of the "pay enough and someone will route it" model will apply: If some ISP sees a potential competitive advantage in offering such a product (and addresses), the product will follow soon thereafter. And, again, I think that this suggests that we had better figures out how to deal with these things on a policy basis, not a protocol-imbedded special address scope one. We are almost certain to have the policy problem anyway and it is not clear that special cases for peculiar address scopes will buy us that much in addition. john
- 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