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 18:26:55


--On Friday, 28 March, 2003 15:50 -0800 Tony Hain <alh-ietf(_at_)tndh(_dot_)net> 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






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