ietf
[Top] [All Lists]

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

2003-03-28 14:24:35


--On Friday, 28 March, 2003 14:54 -0500 Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)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




<Prev in Thread] Current Thread [Next in Thread>