RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
2003-03-31 15:21:21
Margaret,
I can't disagree with any of this. As others have pointed out,
most of these problems can, and regularly have, occurred when
RFC1918 addresses are used in networks that are also connected
to the public Internet and when private 1918 networks are
interconnected. NATs can be used to solve some of the problems
while introducing other problems of their own. And, with IPv6,
the potential of having several addresses associated with each
of those hosts, some SL and some public, would seem to increase
the overall complexity. All of that is complicated by our not
really knowing how to define "site" (or address-scopes more
generally) in many situations in which enterprise subnets are
nested within other enterprise subnets, sometimes several layers
deep, before the packets emerge into an environment that is
unambiguously "public Internet".
I also find Dave Crocker's argument about what applications can
and cannot be expected to do, and some other correspondence
today, immensely persuasive: if we want applications to start
shuffling around addresses, and having knowledge about which
ones represent what sorts of locality, we are going to need some
fairly major changes to TCP and/or ICMP. There are some
economic issues involved as well: if we make it significantly
more complex to create applications that work acceptably well,
we will reduce one of the factors --the ability to rapidly
develop and deploy new applications-- that has contributed
significantly to the growth of the Internet. If IPv4 offers
that characteristic, and IPv6 does not, or does so even slightly
less well, it will bias decision-makers strongly against IPv6
deployment.
All of those things are excellent reasons for getting rid of SL
and relying on unique addresses. At the same time, there seems
to be ample reason for spaces that are scoped as private or
local by filtering. One example is transparency of internal
networking and connectivity to external prefix changes, another
is outlined below, and I think there are many more.
Consequently the other thing that has become clear to me over
the last several days is that, if we are not going to have SL,
or something else 1918-like, we need to be able to allocate
unique blocks of addresses for private use. It seems to me that
we don't have a plan for doing that. The RIR plans for IPv6
allocations appear to focus on the IPv4 distinction between PI
and PD space and on very large blocks and intensive
justifications for PI space.
In the current IPv4 environment, if I go to my local ISP and say
"I'm going to have a really smart house, and I need an IP
address for every light socket in addition to the dozen or so I
need for traditional hosts, even thought the light sockets won't
be exposed to the public network", the ISP will laugh. Part of
that laughter will come from technologically-odd business
reasons such as the desire to sell me an entirely different (and
more) expensive type of connection if I really need more than
one address. But part of it will come because they know that
they had better not go back to their RIR, looking for more
space, and presenting a model that justifies an additional
allocation on the basis of thousands of electrical fixtures that
are not accessed directly from the public network and that,
indeed, are firewalled off from it by devices that authenticate
commands from the outside and filter out traffic to or from the
fixtures themselves.
As far as I can tell, the announced RIR policies toward IPv6
allocations are basically the same as the IPv4 ones: my ISP is
going to have no incentive, and considerable disincentive, to
give me large blocks of addresses that won't be routed onto the
network. And the ISP is probably the wrong answer anyway. If
one of my reasons for wanting "internal" address space is to
make communications within my LAN robust against changes imposed
by the ISP, or changes of ISP, then having space that the ISP
has the right (obligation?) to take back doesn't help.
So, it seems to me that, while "drop SL" is desirable, it only
half-solves the problem and might create a worse one unless the
other half-problem is solved. It seems incumbent on those who
want to get rid of SL to propose some rational scheme, one which
can be administered at reasonable costs and bureaucracy levels,
for allocating blocks of private-use unique addresses. If we
don't solve that problem, but still take out SL, we will
arguably be encouraging people to "squat" on random addresses
and hope they can keep them from leaking and that they never
conflict with real addresses they want to reach. And
address-squatting for private use is probably the worst of all
of the possibilities --been there, tried that, got killed by it.
Thanks to the several people whose (mostly off-lists) notes have
helped to clarify my thinking about this.
regards,
john
--On Monday, 31 March, 2003 16:08 -0500 Margaret Wasserman
<mrw(_at_)windriver(_dot_)com> wrote:
Hi Tony,
At 11:51 AM 3/31/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
> Of course, in the case of site-local addresses, you don't
> know for sure that you reached the _correct_ peer, unless
> you know for sure that the node you want to reach is in your
> site.
Since the address block is ambiguous, routing will assure
that if you reach a node it is the correct one. This FUD
needs to stop!
I believe that you have misunderstood my point... I'll try to
explain further, although our friends in the applications area
may be able to give better examples.
Let's assume that there is a FooBar server in SiteA. If
another node in SiteA (NodeA) is communicating via a
multi-party application to a node in SiteB (NodeB), and wants
to refer NodeB to the FooBar server in SiteA, what does it do?
If this is IPv6 with site-local addressing, NodeA may be
speaking to the FooBar server using a site-local address.
What happens if NodeA sends that site local address to NodeB?
...
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
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...)),
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...)), Jeroen Massar
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), Keith Moore
Thinking differently about names and addresses, Dave Crocker
RE: Thinking differently about names and addresses, Tony Hain
Re: Thinking differently about names and addresses, Dave Crocker
site locals are bankrupt, Keith Moore
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)), S Woodside
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...)), Michel Py
|
|
|