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>
|
- Re: site local addresses (was Re: Fw: Welcome to the InterNAT...), (continued)
- Re: site local addresses (was Re: Fw: Welcome to the InterNAT...), Keith Moore
- Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), John C Klensin
- RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Tony Hain
- RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), David R. Oran
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Valdis . Kletnieks
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Keith Moore
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), John C Klensin
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Bill Manning
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Keith Moore
- RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Tony Hain
- RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)),
John C Klensin <=
- RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Tony Hain
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Keith Moore
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), John Stracke
- RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Jeroen Massar
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Bill Manning
- RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Jeroen Massar
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Margaret Wasserman
- Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Bill Manning
- RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Jeroen Massar
- Re: site local addresses (was Re: Fw: Welcome to the InterNAT...), Keith Moore
|
|
|