Subject: RE: site-locals

From: [email-masked]
Date: Thu, 3 Apr 2003 10:34:06 +0300

Elliot,

> Given that if the mechanism exists we know people will develop NAT 
> functionality in order to isolate enterprises from IP address changes, 
> what is the benefit of going forward at all with IP version 6?  A large 
> address space is useless if you only need a small one.  We already have 
> that.

Do you think that people will use the mechanism if it exists - or will they
create such a mechanism if it doesn't exist?

What I mean is that NATs are one of the most successful IETF technologies
of the decade or so (if you consider deployment, use, etc.). Many of us
may not like it, though, however, it seems that NATs have fulfilled a
real need in the market place - some several seem to be:

	1) Provider (ISP) independent addresses
	2) Increase address space
	3) Access Control
	 ... and so forth

Not all of the above reasons will go away with IPv6 - and I am quite sure
that many network administrators will still administer IPv6 networks in
a similar manner as IPv4.  However, I still think that IPv6 will bring many
benefits and hopefully people are capable of learning new paradigms.

So, getting rid of site locals doesn't remove much of the motivation, and
there are no ready solutions to fulfill some real needs; which worries me.
Is it possible that by killing site locals, we set the stage for people to
do something worse? Will people still use FE0C, even if it is deprecated?
Will people pick random prefixes for use as site local / private addresses?
What is the amount of work to depreciate site locals - how many RFCs need
to be updated? I'm not convinced that deprecating site locals really solves 
anything.

John

--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Thu, 3 Apr 2003 12:22:30 +0300 (EEST)

> to be updated? I'm not convinced that deprecating site locals really solves 

The number of RFC's (basically address architecture, which is going
revision anyway) is small compared to existing and future RFC's which
would have to take site-locals into account (e.g. in the routing area).

-- 
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: "Jim Fleming" <[email-masked]>
Date: Thu, 3 Apr 2003 04:37:10 -0600

From: <[email-masked]>
"...NATs are one of the most successful IETF technologies..."
====

NAT did not come from the IETF...the ISOC opposes them...

http://www.spectrum.ieee.org/select/1098/int.html
NATs are a no-no
HEATH: I was going to say that IEEE Spectrum should make it very clear that this group's consensus would appear to be: let's
discourage NATs--I mean the manufacture of them at all--because there is a real need for IPv6.

HUITEMA: It's more than that. There is a real need for security and you can't have security with NATs.

CERF: NAT is a guaranteed spoofing box in effect.

===================================================

NAT is part of the collection of techniques that build on the existing IPv4 header.
That collection is called IPv8...

Jim Fleming
http://www.IPv8.info

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 3 Apr 2003 16:28:21 +0200 (CEST)

> to be updated? I'm not convinced that deprecating site locals really solves 

[Sorry for the long email, but I don't intent to post on this subject
very often, if ever again.]

John,

I think there is a large difference between what is sactioned/blessed/approved
in a standards track RFC, and what folks might actually choose to do on their
own in at least two spaces:

If we have site-locals in an RFC (with some limiting restrictions) I can
envision folks down the road wanting to improve on site-locals by wanting
to write a standards track RFC on how to extend them to be more useful i.e.
by pushing more towards their full glory (which the community clearly does not
want at this point in time). I ask myself what tools the IETF as a community
will have to push back on such a proposal should it arrive.
It is clearly much easier to push back if the IETF can ask "what problem
are you solving" as part of specifying the site-local addresses RFC, but
if site-locals are already specified in an RFC we will not have that 
tool to help the community come to a shared understanding of the goals.

If we have site-locals in an RFC (with limitations) there is likely to be
an larger pressure on vendors to improve their implementations wrt 
site-locals. I can envision well-intentioned customers that would want
multi-sited hosts or routers, and vendors feeling forced to
implement them. This is much less likely if "site-locals" is just an 
undocumented "pick any prefix if disconnected" approach than something 
sactioned.

Of course, if we really want site-locals in their full glory we should
standardize them. But as I said at the mike in SF I don't find any important 
problems that site-locals solve for which we don't have other solutions, which
motivate the added complexity in the routing, DNS, application, etc spaces.

The claimed motivations I've found over the years are:
1. Try to isolate communication within a site from site-renumbering.
2. Serve as a security token to simplify configuration of filtering in
   simple devices.
3. Provide address space to clouds which are disconnected.
4. Provide address space to clouds which are intermittently connected.
(and perhaps I've missed some that are more than mere variants than the above.)
 I embarked on trying to make #1 work a few years back but, with the assumption
that a significant number of nodes will use MIPv6, to make MIPv6 nodes be able
to benefit from this while in their home site yet function when they move
outside their home site, the complexity flew through the roof. And the
philosophical point about "aren't we here to make global communication work?"
made me personally drop that pursuit.

For #2 we have bellovin/zill prefix option extensions which provide
a strict superset of what one could do with site-locals in this area.
(Folks might want to debate whether #2 is a good idea or not, but that
debate is independent of whether site-locals or bellovin/zill advertisements
are used for this. I'm only here to state that site-locals
are not needed to solve this problem should we wish to solve it.)

For #3 any (random) prefix suffices - there is no need to designate a prefix
in the addressing architecture for this. Whether a particular domain uses 
fec0::/10 or dead::/16 doesn't matter AFAIK - in any case they need to
renumber  should they connect to the Internet *or* connect privately to some
other  previously isolated/disconnected site.

I think #4 (which I didn't talk about at the mike) is a red herring.
Perhaps the issue is a restatement of #1 (due to the ISP implicitly forcing a 
renumbering each time the site connects) in which case the points about #1
applies. And note that making site-locals help with #4 (and #1) involves
having nodes be configured with both globals and site-locals i.e. it
brings in most (but not all) of the complexities of the full-fledged site-local
support.

Note that the community seems to have an unrelated desire to get "PI space"
for free - and in some cases site-locals seem to be confused with some form
of PI space or stepping stone to PI space.
There is some work (in and around multi6, ipv6mh, and hip) that is
looking at two space systems (identifier and locator separation)
that can hopefully provide something of similar look and feel as PI addresses.
Yes, this is no small task. But I sure hope we can spend energy on that
longer term and harder problem than continuing to delude ourselves that
site-local addresses have benefits with justify their added complexity.

So let's not ask what deprecating site-locals solve - let's ask what problems
site-locals solve. They were added to the addressing architecture at a time
when there was little if no wide-spread understanding of the larger 
implications. I hope we have learned some from the discussions over the
last few years (on ipng and zeroconf as well to some extent) so that 
we can try to do this cost/benefit analysis.

Respectfully,
   Erik

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 3 Apr 2003 09:43:23 -0800

Erik Nordmark wrote:
> ...
> I think #4 (which I didn't talk about at the mike) is a red 
> herring. Perhaps the issue is a restatement of #1 (due to the 
> ISP implicitly forcing a 
> renumbering each time the site connects) in which case the 
> points about #1 applies. And note that making site-locals 
> help with #4 (and #1) involves having nodes be configured 
> with both globals and site-locals i.e. it brings in most (but 
> not all) of the complexities of the full-fledged site-local support.

It is not a red herring. Input sent to me for the requirements doc:

Research ships at sea intermittently connect via INMARSAT, or when in
port, the shipboard network is connected to shore via Ethernet. Of
utmost importance is that the systems on board the ship all function,
providing data collection and analysis without interruption. Static
addressing is used on most intra-ship network components and servers.
It's quite expensive to operate a research ship, so eliminating points
of failure is important. Scientists on board collaborate with colleagues
back home by sharing of data and email. Private address space is
employed for several reasons: 1) it provides the ability to allocate
significant address space to each ship without needing to worry about
how many computers will be on a given cruise. 2) it provides separate
address space for each ship. 3) it simplifies filtering to ensure
shipboard traffic is not permitted to transmit out or bring up expensive
satellite links. 

Granted the larger address space argument goes away, but this is an
example of a network that attaches intermittently, and via different
providers. Yet the requirement is that the internal communications not
be interrupted, ever. Telling a network like this that they have to
invalidate any current prefix and renumber everything into the current
provider space is a non-starter. Giving them the option to add the
current provider's prefix to those nodes needing external connectivity
is the appropriate approach. 

> 
> 
> Note that the community seems to have an unrelated desire to 
> get "PI space" for free - and in some cases site-locals seem 
> to be confused with some form of PI space or stepping stone 
> to PI space. 

The confusion derives from the fact that some want PI space for
connected networks, while others want PI space for disconnected ones.
The requirements for those are somewhat different. Space for
disconnected networks must be freely available, or people will pick
random numbers because those don't require approval or payment. A
registry costs money to run, so there is no reasonable way to get
registered values for free, and the IETF can't pick up the tab.

> There is some work (in and around multi6, 
> ipv6mh, and hip) that is looking at two space systems 
> (identifier and locator separation) that can hopefully 
> provide something of similar look and feel as PI addresses. 

This approach does not solve the problem that the connected PI community
wants solved. They are looking for isolation from the costs of
renumbering. What we are finding is that the multi-prefix per host model
mitigates the host part of that cost, but the configuration of the
infrastructure also has a high manual labor cost. The two space system
makes it much more difficult for the infrastructure to figure out what
is going on in order to apply the appropriate policies to the intended
identifier. On top of that, the costs for manually reconfiguring the
infrastructure don't go away.

> Yes, this is no small task. But I sure hope we can spend 
> energy on that longer term and harder problem than continuing 
> to delude ourselves that site-local addresses have benefits 
> with justify their added complexity.

The problem at the moment is that those who are looking at the
application development complexity are refusing to acknowledge the
operational complexity caused by the lack of alternatives. Yes there are
promises that someday we might solve a few of the problems, but until
every requirement is met it is irresponsible of the WG to remove an
architectural component that people are using in the current IPv4
network.

Tony

> 
> So let's not ask what deprecating site-locals solve - let's 
> ask what problems site-locals solve. They were added to the 
> addressing architecture at a time when there was little if no 
> wide-spread understanding of the larger 
> implications. I hope we have learned some from the 
> discussions over the last few years (on ipng and zeroconf as 
> well to some extent) so that

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 03 Apr 2003 14:07:58 -0500

While I think it would be great to design a mechanism that would
allow smooth operation of intermittently connected nodes whose
global addressing potentially changes at each re-connect, I do
not believe that we want to impose a costly and complex solution
on _all_ IPv6 nodes so that a few of them can work properly in
this unusual situation.

Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 4 Apr 2003 13:38:28 +0200 (CEST)

> It is not a red herring. Input sent to me for the requirements doc:

But this case is exactly the same as what I categorized as #1 in my list - 
isolating communication local to the site from site renumbering. The only added
twist is that site renumber occurs when the site attaches and detaches from
the Internet.

> port, the shipboard network is connected to shore via Ethernet.

Looking at your resarch ship case a bit more in detail it occurs
to me that even using site-locals plus globals while connected doesn't
necessarily protect the local communication. The introduction of the 
global prefix/addresses when the ship is connected might very well
trigger different address selection behaviors in the stack or in the
applications. Thus it seems like the robustness provided by site-locals
only apply to communication established (and addresses selected)
before the global prefix is introduced. Later communication is subject
to any bugs or poor interaction in the address selection domain - something
that is bound to have some corner cases due to its complexity.
(Note that this is a property that applies to #1 in my list that I've
previously not realized.) While the effect of this probably is less than
the effect of renumbering the ships network each time it attaches to the
Internet, it still doesn't isolate the ships internal network from
being attached to the Internet when site-locals are used as you propose.

So if I were to design this ship I'd use neiether renumbering at
attachment time nor site-locals. Instead I'd have the research ship get
a stable prefixe (a few /64's might suffice) from the organization that runs 
it which are globally unique and can be used whether the ship is connected
or disconnected. This completely isolates the addressing of the ship internals 
from whether it is connected or disconnected; the only difference is the when
disconnected off-ship destinations are unreachable. When it gets connected
tunnel(s) need to be established back to the research organization in order
for routing to work. Such tunnels could be cobbled up today with some existing
tunnel establishment mechanism, and the Nemo WG is working on an IETF standard
for such tunnel establishment. So if you want internal stability you have to
pay by having less efficient routing - going bidirectionally over the tunnel
to "home" - no free lunch.

If you believe in Mobile IPv6 route optimization you might also
believe that the Nemo work can be extended to provide route optimization
to/from correspondent nodes in the Internet at large (by reusing the
MIPv6 approach). I personally think the utility of this remains to
be proven, but if it is it would help with the routing inefficiencies caused
by routing.

So once again, this is not a case where I think site-locals help.

   Erik

---

From: Mike Saywell <[email-masked]>
Date: Fri, 4 Apr 2003 13:15:53 +0100

> being attached to the Internet when site-locals are used as you propose.

I think site-locals could be used here, with a single rule that they're
simply the least preffered prefix used in address selection.

Whilst the boat is in a port, it receives a global prefix which is
advertised on appropriate subnets.  Before leaving port the prefix
is deprecated (but not removed), thus there would be no break in
communications.  It can be removed several days later safely when it's
no longer in use.

This doesn't just apply to huge boats, what about a private yacht?
This is another zero-conf issue, it has all the same problems as the
research boat (getting connectivity via different providers depending
on which port they're at) except that the owner may not have his own v6
prefix, or even know what IPv6 is!

Finally I don't agree with your tunnelling solution at all (sorry it
got <snipped>) .  I would rather NAT and have a 10ms RTT insetad of 200ms,
and if I would NAT here (I hate NAT!) then I think lots of other people
would too.  Tunnels are complicated NAT is easy...

So I would argue that in this case deprecation of Site-locals *encourages*
NAT, now there's something you don't hear every day! :-)

Mike

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 4 Apr 2003 18:27:30 +0200 (CEST)

> communications.  It can be removed several days later safely when it's

Tony's requirements seemed to say that ship-local communication must never
break. I took that to mean imply in your example that the deprecated
prefix can never be invalidated. And that would cause problems when
the boat arrives in another port.

> prefix, or even know what IPv6 is!

Give specific requirements the way Tony did for the research ship and we
can analyse the options.
His requirement was that ship-local communication not be impacted
by the ships connection and disconnection to the Internet.
What requirements do you have in mind for the yacht?

> would too.  Tunnels are complicated NAT is easy...

I think we have to agree that we disagree on that one.

  Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 04 Apr 2003 10:22:05 -0800

I tend to agree with Erik on the research ship case; since the ship is
a rather large and coherent entity (most likley owned by an even larger
organization) it makes sense for it to have one or several globally
unique prefix assignments that can be used whether/not the ship has a
connection to the global Internet. But, I still havn't seen a solution
proposal for ad-hoc networks of individuals that come together for
arbitrary purposes and wish to form a network.

For example, if Bob, Ted and Alice find themselves in a common space
with no proximity to an Internet access point, they should be able to
form a network and have persistent communications that survive even
if an Internet access point is later encountered. But, since Bob, Ted
and Alice are just private individuals, it seems unlikely that any
would own a globally unique prefix - so how do they decide on a
common prefix to use that supports communications even in the
intermittently-connected case?

I have seen at least one IEEE 802.11 product vendor that solves this
problem at the MAC layer by choosing the MAC address of the first
node to join the network as the I-D to use for the IBSS (i.e., the
ad-hoc network "cluster"). When two nodes come together for the first
time, there is some sort of tie-breaking to decide whose MAC address
will be used. When multiple IBSS's merge (e.g., when John and Sue join),
the I-D of one IBSS is chosen as the I-D of the merged IBSS. When, an
IBSS partitions (e.g., when John and Alice leave) new I-D's are chosen.

But, this all seems too dynamic of a model to adopt for choosing
network-layer addresses in which stable addresses are needed both
regardless of the underlying topology dynamics and without a
provider-assigned prefix. How do we solve this?

Fred
[email-masked]

---

From: Greg Daley <[email-masked]>
Date: Mon, 07 Apr 2003 10:32:50 +1000

Hi Erik and Mike,

This work is obviously related to NEMO.
If people have real requirements for network mobility,
they can certainly take them there.

Currently the base NEMO solution provides stable addresses
from a home domain and provides tunneling to the home net.
There are people who believe that long latencies
from tunneling to this network are prohibitive for real time
applications, and aim to gain route optimization analogous
to that provided in MIPv6.

I don't think there needs to be talk of either site-local
or NAT in this context, unless the NEMO work cannot
provide adequate solutions.

Greg