RE: Thinking differently about the site local problem (was: RE: site l

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?
> ...