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

[John C Klensin <[e-mail]>]

--On Friday, 28 March, 2003 15:50 -0800 Tony Hain 
<[e-mail]> wrote:

> John C Klensin wrote:
>> (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.
>
> Note I said:
>>> It is absolutely unreasonable for an ISP to tell their
>>> customer  anything about running their network that is not
>>> directely  related to the customer/provider interface. As
>>> long as the  enterprise traffic over that interface is
>>> related to the  capabilities they are paying for, it is none
>>> of the ISPs  (or IETFs) business what they are doing
>>> elsewhere.
>
> The ISPs do set terms for the customer/provider interface all
> the time, and rightly so. They can not restrict me from
> setting up an 802.11 link to my neighbor, only that my
> neighbor is not allowed to use that for access to the
> provider's network. In a similar vein, the provider is not in
> a position to tell customers what address space they can use
> for purposes that do not interact with the provider interface.
> They can try, and in a monopoly environment will probably
> succeed. That does not mean we can tell ISPs to require that
> people not use any given address space just because the
> provider is supplying another one.

I'm interested in your "not in a position" comment.  Whether it 
is reasonable or not, ISPs include such restrictions in terms 
and conditions of service all of the time.  I have seen 
agreements that prohibit connecting more than one computer to an 
ISP-provided line, agreements that explicitly ban customer-side 
NAT boxes and restrict use to no more than one computer per 
ISP-provided address, and prohibit connecting their interfaces 
to anything resembling a LAN or to a machine that can gateway 
into a LAN.  I've also seen agreements that prohibit any use of 
tunnels into external mail servers or corporate LANs, presumably 
to get the customer to buy a higher-priced "commercial" service 
if anything other than home-type web browsing and associated 
email is to be done with the link.

Now some (or most) of these restrictions impress me, and 
probably you, as unreasonable.  We might choose to apply the 
"see if they can find out that I'm doing it" test to the 
restrictions and ignore them or, at the other extreme, apply the 
"don't sign anything on the assumption that the other party 
won't be able or inclined to enforce it" principle.

We, or more specifically, the upstream ISP or an RIR, can tell 
the ISP that things will go badly for them if they permit 
unroutable addresses to leak into the public Internet.  The only 
difference I can see between what I think is your SL address 
preference and my "unique, but unroutable" one  is that you 
would bind that advice/threat to a particular prefix while I 
would bind it to other indicators of "unroutable address".  The 
reserved prefix approach is less likely to get mucked up by a 
clueless ISP, but I am unconvinced that we should make special 
architectural provisions to make it easier to be in the ISP 
business while being clueless.

>> 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.
>
> Address filtering exists in the network today, and will
> continue. Since that is done as an expression of local
> policies, you are correct the whole discussion is really about
> policy. It is not clear to me what the IETF is in a position
> to do, other than define the operation of a multifacited DNS.
> ;)

And, since I have seen split-horizon DNS implementations fail 
more often than not, I'm not sure I see a cure there either.

Regards,
     john