Subject: My thoughts on local-use addresses

From: Jason Hunt <[email-masked]>
Date: Sat, 26 Apr 2003 02:04:20 -0400

I decided I will come out of "lurk mode" and try to express my thoughts
about local-use addresses.  I have been following the thread on the IETF
general mailing list regarding site-local addresses.  The following
things may have already been discussed, as I only just recently
subscribed to the IPNG mailing list.

I think all unicast addresses should be "global", instead of having
any scopes at all.  I believe this would promote the whole E2E concept.

Local-use addresses seem to be redundant.  Why would one need to address
a host on the same site or same link using an address other than its'
global address?  (Sorry if that is confusing)  One scenario I thought of
is back-end servers (ie: database servers) that do not need to be
globally accessible, but other front-end servers (ie: web servers) need
to communicate with these back-end servers.  This is what a private
address space would be for, and you would likely have multiple
interfaces on seperate networks (one public, one private) to segregate
the traffic.

I suggest that:

a) The site-local and link-local address scopes be abandoned.  As I
stated above, I believe they are redundant and therefore not needed.  If
you want to address all of the hosts at your site or on your link, why
not use multicast?  Are there any practical cases where one would use
these scopes instead of global addresses that a private space or
multi-cast would not solve?

b) I believe that RFC 2462 (IPv6 Stateless Address Autoconfiguration)
already deals with this, but I will mention it anyways; the link-local
address space (or possibly some other space) be used as a fall-back for
auto-configuration purposes.  If a host is not configured with a static
address, and does not have DHCP client capabilities or the host does not
receive a response from a DHCP server, then an auto-configured
address could be assigned to the interface.  I think this would make it
so that "it just works" if someone wants to plug a bunch of IPv6 hosts
on to a LAN and use some type of neighbor disocvery mechanism to let the
hosts find each other and start communicating.

c) The link-local address space (or, again, some other space) be made
available as private address space.  It would for use by administrators
of networks that are not planning to be connected to the Internet but
still need an address space to use.  Is this not the intention of RFC
1918 addresses as well?  Is there any reason to not provide a private
addres space?  I don't want to start discussions about NAT because
that's not what it the private address space will always be used for.

Comments and constructive critisism are appreciated.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jason Hunt <[email-masked]>
Date: Sat, 26 Apr 2003 12:42:55 -0400

I've done a bit more thinking regarding my previous post.  I am going to
restate the things that I suggested, in case my previous message left
anything un-clear.

I would like to suggest that:

- The idea of scopes be removed from unicast addresses.  Why add the
  complexity of scopes?  Is it not better to keep things simple?

- The link-local address space (FE80::/10), or some other space, be
  available as "private use" address space, similar to what RFC 1918 is
  to IPv4.  I realize that the current definition of the local-use
  addresses already provides this, but since I am suggesting to change
  that definition it seemed necessary to make this point.

- All interfaces be required to have at least one unicast address
  assigned to them, instead of being required to have a link-local
  address in addition to any other addresses.  If an interface is not
  configured with an address, and the host is unable to obtain an
  address from a DHCP server (or some other dynamic configuration
  protocol) for that interface, then the interface will be auto-
  configured with an address from the above-mentioned "private use"
  space (FE80::/10 or otherwise).  

Can anyone point out any practical scenarios for scoped addresses to
be required, which could not be dealt with by having a "private use"
address space available?  After reading the discussion on site-local
addresses, I think that unicast address scopes may be un-necessary.  If
I happen to be mis-understanding something, I welcome any explanations
or pointers to previous discussions.

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Apr 2003 13:02:11 -0400

Jason,

we need to get rid of site-locals.  merely renaming them as private use
addresses wouldn't solve any of their problems.  there's no advantage to
moving to IPv6 if it repeats the RFC 1918 mistake.

Keith

On Sat, 26 Apr 2003 12:42:55 -0400

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Apr 2003 13:35:30 -0400

On Sat, 26 Apr 2003 13:31:27 -0400
Jason Hunt <[email-masked]> wrote:

> On Sat, Apr 26, 2003 at 01:02:11PM -0400, Keith Moore wrote:
> What is wrong with having addresses available for private use on
> networks that do not intend on being connected to the Internet? 

in principle, nothing.  but experience has shown that most of those networks
do end up being connected to the Internet, while still keeping those addreses,
and that applications are expected to cope with that.

>  What are your thoughts about link-local addresses? 

v6 link-locals are mostly harmless as long as they're only used for 
router discovery and similar things.  applications should not use them.

v4 link-locals have been touted as suitable for general-purpose use, and 
that's just wrong.

---

From: Jason Hunt <[email-masked]>
Date: Sat, 26 Apr 2003 13:31:27 -0400

What is wrong with having addresses available for private use on
networks that do not intend on being connected to the Internet?  I
suppose that if they are not going to be connected to the Internet, then
really they could just use whatever space they feel like, since it
should not affect any one else unless they do go to connect with other
sites.

Keith, do you have a draft or something you have been working on?  For
the most part I think that I do agree with your arguments against
site-local addresses.  What are your thoughts about link-local
addresses?  Do you want to get rid of all the local-use address space,
which I suppose really means abandoning the idea of scoped addresses all
together?

---

From: Arien Vijn <[email-masked]>
Date: Sun, 27 Apr 2003 11:54:39 +0200

> and that applications are expected to cope with that.

Ehm... What experience? You are referring to experiences with RFC1918
addresses in the IPv4-world, aren't you? But... Do you or anybody already
have have similar experiences with regards to site-locals?

Indeed, RFC1918 addresses are frequently used behind NAT-boxes. And these
NAT-boxes do create all kinds of troubles. That is the main problem isn't
it? 

For that matter will it be the same with regards to IPv6 site-locals? I
think not. Because the most important reason for NAT is the lack of
available IPv4 address space. I know there are more reasons why people use
NAT. But this is by far the most important one. Because for many many
end-users and small companies, it is very hard, if not impossible or at
least expensive to get more than one IPv4 address.

This is not the case in IPv6. ISPs typically provide their customers with a
/48 of globally unique address space... Well, my home-ISP does. Do you
really think I thought one minute of NATing IPv6?

In other words: NAT makes networking complex, it breaks the end-to-end
model, creates unwanted site-effects and it is not really needed with enough
available address space. Therefore I do not think that site-locals will be
used in the same fashion as RFC1918 addresses are mostly used today.

Having said that, NAT might be a quick and dirty hack to satisfy the needs
for:
  - address stability, due to the lack of easy renumbering;
  - multihoming;
  - (obscurity). 

Especially renumbering-issues might also be a reason for using NAT nowadays.
Just because renumbering is too much pain in IPv4. Somehow addresses have to
be configured at many different places. Implementers might be more
thoughtful with regards to IPv6.

Ironically, multihoming is typically a requirement of non-NAT users
nowadays. They might become the new NAT-adepts if the market comes with
means to do it via NAT and there is no good alternative.

Obscurity (some seem to call it security) is just an implementation matter
as well. Really don't want to discuss this.

In any case, I do not think that deprecating site-locals will take away the
NAT-threat. Neither does it bring us closer to alternatives. At least
site-locals are easily recognisable so coping with becomes a possibility.

Arien

---

From: "Mario Goebbels" <[email-masked]>
Date: Mon, 28 Apr 2003 11:32:07 +0200

> in principle, nothing.  but experience has shown that most of 
> those networks do end up being connected to the Internet, 
> while still keeping those addreses, and that applications are 
> expected to cope with that.

It would be still nice to have some sort of private addressing for backend
servers. Using link local addresses does work for a small network, but we're
running our database servers on different subnets (connected by routers)
than the webservers. Though continuing to use IPv4 would work, but it's not
what I would want to do on longterm.

-mg

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Apr 2003 14:04:39 +0300 (EEST)

> what I would want to do on longterm.

Why not just use global IPv6 addresses, a part of the /48 prefix, for 
that -- and just not route that particular piece?  That's what we do and 
it works fine.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Mario Goebbels" <[email-masked]>
Date: Mon, 28 Apr 2003 13:31:03 +0200

> > > in principle, nothing.  but experience has shown that 
> most of those 
> > > networks do end up being connected to the Internet, while still 
> > > keeping those addreses, and that applications are 
> expected to cope 
> > > with that.
> > 
> > It would be still nice to have some sort of private addressing for 
> > backend servers. Using link local addresses does work for a small 
> > network, but we're running our database servers on 
> different subnets 
> > (connected by routers) than the webservers. Though 
> continuing to use 
> > IPv4 would work, but it's not what I would want to do on longterm.
> 
> Why not just use global IPv6 addresses, a part of the /48 
> prefix, for that -- and just not route that particular piece? 
>  That's what we do and it works fine.

Just not route? You mean using a filter on outgoing traffic, right?

-mg

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Apr 2003 16:56:27 +0300 (EEST)

> Just not route? You mean using a filter on outgoing traffic, right?

Example: if you're using 3FFE:FFFF:1::/48 in your site, you could
designate e.g. 3FFE:FFFF:1:F000::/52 as your "interconnect" block.  In
your site's border routers (at least), you would install a discard route
to 3FFE:FFFF:1:F000::/52.  Now, you'd just use 3FFE:FFFF:1:F000::/64 ... 
3FFE:FFFF:1:FFFF::/64 in the private networks just as you chose.

You could also filter out outgoing traffic (to the Internet) with source
addresses belonging to that /52, but that would not be required.

Hope this clarifies what I had in mind..

---

From: Robert Elz <[email-masked]>
Date: Mon, 28 Apr 2003 22:44:23 +0700

Date:        Mon, 28 Apr 2003 16:56:27 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Hope this clarifies what I had in mind..

You described one, of many, methods of filtering traffic.   If
traffic filtering was all that was required, that will work fine
(though personally I prefer explicit packet access lists, it is
clearer what is happening and why).

On the other hand, if tomorrow you wake up and find a message from
your provider telling you that 3ffe:ffff:1::/48 is now your neighbour,
and 3ffe:ffff:2::/48 is you, you have a problem.

If you keep using 3ffe:ffff:1 for your servers, then nothing in your
net can communicate with your neighbour, as the routes are all inwards,
not outwards.   If you stop, and switch to 3ffe:ffff:2 then all your
server communications break for some period (your boss misses out on
getting his paycheck on time, and you get fired).

On the other hand, if your servers were using site local addresses,
as Mario suggested, then none of this would affect them.

kre

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Apr 2003 19:52:20 +0300 (EEST)

> clearer what is happening and why).

Yes, I prefer it too.  Personally I'd recommend using both, for defence in 
depth.
 
> and 3ffe:ffff:2::/48 is you, you have a problem.

That would be a good chance to switch ISP's.  Just doing something like 
taht one morning is not really acceptable.
 
> getting his paycheck on time, and you get fired).

Well, renumbering is a difficult issue.
 
> as Mario suggested, then none of this would affect them.

Mario's particular scenario was internal links in private networking (like
NFS, backup traffic etc.) -- not about addressing in general in the site.

My sessions last for a long time -- even months -- but I'm not mad if they
drop because now and then (once in a couple of years or so -- a
semi-reasonable renumbering period) a renumbering happens.

Now, if we need mechanisms to cope for renumbering every day, every week
or every month -- we're talking about entirely different kind of
requirements.  IMO, it's best not to try that problem yet, first -- or we
end up with nothing (I fear).

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 13:58:32 -0400

> > we need to get rid of site-locals.  merely renaming them as
> > private use addresses wouldn't solve any of their problems.
> > there's no advantage to moving to IPv6 if it repeats the RFC
> > 1918 mistake.

> Hyperbole does not serve either the community, or one's own 
> position, well in this situation or others like it. 

John,

If I understand what you are calling hyperbole I would instead call it
the 10,000 meter view.  That is, I don't see a significant market for
IPv6 if it doesn't support applications that cannot be run on NATted
IPv4.  Yes, there may still be some small advantage of IPv6 for some
groups of users if this doesn't happen, but not for the Internet
community as a whole.   So "no advantage" can be taken as an
exaggeration, but the intent was to avoid getting bogged down in
detail about exactly what minor advantages there might be and why
they're unlikely to create enough incentive for any widespread adoption
of IPv6.

And no, I don't think that reducing the number of NATs by 25-50% would
create a significant advantage to moving to IPv6.  In order to create a
significant advantage, there need to be so few NATs in IPv6 that
application developers can write applications that will fail in the
presence of NATs without fear of losing a significant number of
customers.

I agree that there's a requirement for PI addresses, and perhaps, for PI
addresses that don't require RIR allocation.  Various solutions have
been proposed, but we seem to be unable to evaluate them or choose
between them because we're too busy arguing about whether the v6 network
should be saddled with the baggage from v4.  

The discussion about SL also seems to be couched in those terms, as well
as being confused by efforts to conflate different notions of scope that
are better understood separately.  IMHO, those who think that hosts or
apps should have to bear the burden of picking which address or
interface to use in order to get packets to their destination need to
explain (a) where the hosts or apps get the information necessary to
make those choices in a reliable and timely fashion, and probably (b)
how to provide a usable endpoint identifier under those conditions that
can be passed between hosts at arbitrary locations.  Until then, I'm not
convinced that the v6 assumptions about multihoming are workable.  Which
further leads me to conclude that we still haven't figured out a way to
make IP routing scale in a practical sense.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Apr 2003 11:28:05 -0700 (PDT)

> make IP routing scale in a practical sense.

It seems to me that what needs to be answered
first is whether we are already resigned to
dealing with that problem with mobility,
renumbering, and multihoming. There's good reason
to want to use a local prefix rather than mobile
IP for new communiation if possible since it more
cleanly eliminates the dog leg through the home
agent. Likewise, there's pretty good reason to
want to renumber. Neither of these have a very
strong policy component though: the host wants to
do this for efficiency and/or continued
communication. So I'd say that there's pretty good
motivation for hosts to want to at the very least
deal with more than one globally routable address.

Multihoming is similar, obviously, but also
introduces an element of policy to the discussion:
it would be nice to prefer one path over others;
having -- somehow -- hosts know the policy would
be one way to achieve that. Have we just gone to
hell in a hand basket? This strikes me as part of
what is getting discussed with site-locals. Is
selection based upon policy -- and hence knowing
finer grained properties of IP prefixes -- the
road to hell? It sure seems to drag a lot more
baggage into the discussion than with the mobility
and renumbering problems when you start talking
about policy. Keeping prefix knowledge on hosts
opaque would certainly be one way to draw a line
in the sand. This has implications with both
site-locals (bad) and multihoming (policy-based
selection bad).

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Apr 2003 11:28:05 -0700 (PDT)

Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 15:16:48 -0400

>  > IMHO, those who think
>  > that hosts or apps should have to bear the burden of picking which
>  > address or interface to use in order to get packets to their
>  > destination need to explain (a) where the hosts or apps get the
>  > information necessary to make those choices in a reliable and
>  > timely fashion, and probably (b) how to provide a usable endpoint
>  > identifier under those conditions that can be passed between hosts
>  > at arbitrary locations. 
> 
> It seems to me that what needs to be answered first is whether we are
> already resigned to dealing with that problem with mobility,
> renumbering, and multihoming. 

If we're resigned to dealing with an intractable problem, maybe we need
to rethink that assumption.  But it's not clear that either mobility or
renumbering presents the same kind of challenge.  In the case of
mobility I think it's fairly simple to decide whether to use a home or
in-care-of address as the source address, and this can be dictated by
the application.  In the case of renumbering then both old and new
prefixes should be valid for a considerable overlap period, which would
make the choice less critical except for apps that maintain
associations for a very long time (say, for several weeks).  As for
"multihoming" - these days people mean different things when they say
that, so I can't tell for sure what you mean.  But I think the
assumption that having multiple prefixes for a site and advertising
multiple addresses for hosts through DNS will provide sufficient
redundancy in network access to that site, across all or most
applications, is dubious at best.

> There's good reason to want to use a
> local prefix rather than mobile IP for new communiation if possible
> since it more cleanly eliminates the dog leg through the home agent.

Taken in isolation, that's certainly true.  But it presumes several
things, one of which is that a sending host can tell which of several
prefixes is the best to use.  (or if not the best, which ones are more
likely to work well than others).  It's easy to construct cases where
it's possible for the sending host to do this; somewhat more difficult
to construct a convincing argument that this can be done in general.

For instance, I spent some time investigating an idea which I'll call
"relative addresses" - the idea being that if source and destination
absolute/global addresses share enough bits of a common prefix the
sending host can assume they're on the same network, it can substitute
that many bits of "relative address prefix" for the global prefixes in
those addresses, the local network will route the traffic to the same
destination, and the addresses don't need to change when the network's
global prefix changes.  The idea has some nice properties.  In
particular, this is an optimization between hosts and the network -
applications can use it explicitly if they wish, but they don't have to
be aware of it to benefit from it.  There's no need to advertise the
"relative addresses" in DNS or in referrals between apps because they
can automatically be inferred by hosts.  And it would even work well
in conjunction with mobile IP-like mechanisms for forwarding and/or
redirecting traffic to PI prefixes - since local traffic would bypass
such mechanisms completely.

However - at least in its current incarnation, it doesn't work if a
network has multiple prefixes that aren't available to the same set of
hosts.  In other words, just because a source and destination share *a*
common prefix doesn't mean that the conversion from absolute to relative
address is invertable - the substitution of a single common prefix
can create an address that is ambiguous even within the local site.
(But I'm still working on the idea...)

Ketih

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Apr 2003 13:43:56 -0700 (PDT)

Keith Moore writes:
 > to rethink that assumption.  

Well, that's what I'm trying to tease apart
here: what's tractible, and what's intractible.
If the entire problem space is intractible,
then we probably have some pretty big problems.
It's not clear to me that it is though... read on.

 > But it's not clear that either mobility or
 > the application.

I'd say it's the stack, (for MIP at least) but
that's a small point.

 > As for
 > that, so I can't tell for sure what you mean.  

Nothing exciting: two different interfaces, two
different prefixes.

 > to construct a convincing argument that this can be done in general.

Correct. Naively, when you're, say, starting a TCP
connection from a mobile node, if one of your
prefixes is bound to a tunnel (eg, a home agent),
you'd almost certainly like to use a CoA prefix
instead... unless you think you might move, and
the router which owns CoA prefix can't be a home
agent for whatever reason.

So it appears that even this fairly simple bit of
policy: "Use CoA prefix on outbound TCP
connections" isn't quite as simple as it first
appears. How on earth do I know if I might move?
Thus, it sort of reduces to "only if the current
router will support mobility in case I move", or
"I'm willing to deal with a loss of connectivity
on some sessions". But, this still seems to not
rely on anything extra about the prefix itself
other than what we already know.

I think that a similar argument can be made for
renumbering. That is, we can finesse the issue
such that end hosts don't have to know any sort of
qualities about the prefix other than either what
it currently knows, or what a real router told it
to believe (eg, the preference).

So I get back to my larger point: is the real
devil here hosts trying to know policy information
about prefixes that we currently have no way (or
desire) to spread around? I mean, I've always
thought that that was a pretty basic part of the
internet architecture, which is one of the reasons
I don't like the implications of scoped addresses.
Abandoning that philosophy pretty much says there
is no practical difference between a host and a
router.

      Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 16:59:30 -0400

>  > If we're resigned to dealing with an intractable problem, maybe we
>  > need to rethink that assumption.  
> 
>  > mobility I think it's fairly simple to decide whether to use a home
>  > or in-care-of address as the source address, and this can be
>  > dictated by the application.
> 

nope, the app.  the stack doesn't know whether the app prefers stability
or efficiency, unless the app tells it which it prefers.  but at least
the app probably has an idea which one is better.

this is fundamentally different than expecting either the host or
the app to choose between multiple source or destination addresses, each
pair imposing apparently (to the host and app) arbitrary constraints on
what the network will pass.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 30 Apr 2003 17:06:07 -0500

Thus spake "Keith Moore" <[email-masked]>
> the app probably has an idea which one is better.

The app developer often doesn't know these things either -- if the app
understands this new API at all, I think it'd most often end up as a user
knob, meaning we could just call it a stack option and leave the app out of
things entirely.

> this is fundamentally different than expecting either the host or the app
> to choose between multiple source or destination addresses, each
> pair imposing apparently (to the host and app) arbitrary constraints
> on what the network will pass.

Which is harder, having the stack give the app a list of source and
destination addresses and then expect the app to figure out which to use, or
have the stack attempt various combinations of source and destination
addresses and just notify the application which one(s) worked?

Something tells me the latter is both easier and more likely to be
implemented correctly.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Apr 2003 22:35:35 -0400

> knob, meaning we could just call it a stack option and leave the app out of

at least some apps do know these things.  a web browser, for instance, 
understands that its TCP connections are ephemeral, and it knows how to 
recover from broken connections.  same thing for an SMTP MTA or a mail
reader.  OTOH an interactive login using ssh is probably better off
using stable addresses, as is an NFS mount.

however if the API exists then nothing prevents the app from having a knob
that lets the user override the default.

> addresses and just notify the application which one(s) worked?

from experience, the delay in the latter case is often unacceptable,
and even if it isn't, the stack often makes the wrong choice for the app.

> Something tells me the latter is both easier and more likely to be

you're simply wrong about that.

Keith