Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

Bill Manning <bmanning@ISI.EDU> Fri, 28 March 2003 21:35 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 QAA19936; Fri, 28 Mar 2003 16:35:16 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18z1iG-0000JZ-00 for ietf-list@ran.ietf.org; Fri, 28 Mar 2003 16:48:36 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18z1gP-0000FG-00 for ietf@ran.ietf.org; Fri, 28 Mar 2003 16:46:41 -0500
Received: from boreas.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19655 for <ietf@ietf.org>; Fri, 28 Mar 2003 16:30:59 -0500 (EST)
Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h2SLXHQ21647; Fri, 28 Mar 2003 13:33:17 -0800 (PST)
From: Bill Manning <bmanning@ISI.EDU>
Message-Id: <200303282133.h2SLXHQ21647@boreas.isi.edu>
Subject: Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
In-Reply-To: <95119875.1048868495@p3.JCK.COM> from John C Klensin at "Mar 28, 3 04:21:35 pm"
To: john-ietf@jck.com
Date: Fri, 28 Mar 2003 13:33:17 -0800
Cc: moore@cs.utk.edu, Valdis.Kletnieks@vt.edu, oran@cisco.com, ietf@ietf.org
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

 John, mixed bag of nasties here.  Routing, addressing, and (of course)
 the DNS.  More fun than should be legal on a friday afternoon.

 Routing: there is a varient here. Think about routing table slots.
 If I get one, does it matter what the length of the prefix that I
 put in it?   There are other abstraction methods besides aggregation,
 at least thats what some smart people are telling me.

 The other bits will have to wait.


% 	* 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
% 
% 


-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).