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