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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 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).



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]