Subject: RE: globally unique site local addresses

From: "Michel Py" <[email-masked]>
Date: Fri, 22 Nov 2002 22:14:53 -0800

Mark,

> Mark Smith wrote:
> Michel, maybe my mind isn't lateral enough, but I
> can't think of an example of anybody who would want
> to pay for guaranteed globally unique site local
> addresses. Usually people seem to be happy with
> "good enough and free" verses "perfect and not-free".
> Are there any examples you might be able to give ?

Any organization that is serious about using site-locals. Two examples
comes to mind:
- Corporate mergers (avoids the renumbering pain found today when the
two corporations were using 10.0.0.0)
- VPN connections.

As Brian Carpenter mentioned earlier, globally unique site locals are
not good for IPv6 NAT, so let's figure them out.

Michel.

--------------------------------------------------------------------
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: Mark Smith <[email-masked]>
Date: 23 Nov 2002 17:59:39 +1100

> not good for IPv6 NAT, so let's figure them out.

Absolutely agree. I've experienced the both the VPN and network 10
addressing situation concurrently with IPv4, in addition to having to
come up with bodgey solutions, I spent two months just saying to my self
"customers should just get registered address space, and make my life
(and theirs') a whole lot easier."

Globally unique site locals would fix a lot of the issues I had with
trying to work out how I might use site-locals in large IPv6 network.

My question was in the context of following Pekka's almost globally
unique site locals model. I like the property of his model where there
is a very remote possibility of site-local address space collision. 

Lack of absolute guarantees of globally unique site local addressing is
a bit of a "stick" that will prevent people from trying to use their
globally unique site locals for global communications, as per Brian
Zill's concerns.

I also like the fact that his model doesn't require any interaction with
a registry of some sort, and any associated costs ie. his model is "good
enough and free", rather than "perfect and not-free".

Thanks,
Mark.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 23 Nov 2002 09:40:38 +0200

> two corporations were using 10.0.0.0)

Ah, yes. The corporate merger case... at the MERGER time they are
desperate and willing to spend money, but it is already too late.
We need a solution that is good enough and free for the time when
the network addressing gets DECIDED. Often, this is done when the
companies were small start-ups and they have a single-address uplink
and some network of devices internally.

My thinking is that Pekka's statistically unique site local approach
is the right solution here. Also, let's take a look at the requirements
posted by Margaret:

 >        - persistent addresses to put in configuration files,
 >                security filters, etc.

Given a MAC/vendor id/company name string -based approach we
can do this with Pekka's approach.

 >        - addresses that can be used in intermittently connected
 >                sites and remain valid

CAn do this too.

 >        - addresses that survive ISP renumbering

Yes.

 >Without the use of ambiguous addresses.

Yes.

 >        - work properly when two organizations merge

Yes.

 >        - be possible to associate with an administrative
 >                entity to which they are registered

I tend to think this is not a requirement. Might even be
harmful. But yes, this is doable as well. Say, we could
REQUIRE that the address is a hash of the MAC or the
company name. So at least you could show that your address
is yours, though it doesn't prevent others from claiming that
as well (given the small number of bits). Optional registry
is doable as well, but like I said above that may not be
desireable.

Finally, I'd like to add a requirement: We need addresses that
a group of nodes can come up all by themselves without the
participation of humans. Pekka's addresses can do this too.

Jari

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Nov 2002 12:10:15 +0200

On Sat, 2002-11-23 at 09:40, Jari Arkko wrote:
> participation of humans.

Exactly. The ability to get a prefix immediately without being forced to
follow some kind of a registration procedure is an important property.

As long as site locals are non-routable, administrators of "non-serious"
networks (and those that are just plain lazy) will simply pick a prefix
and go with it. The solution must be such that it can be implemented in
a router stack and applied automatically. I'm sceptical even about the
willingness of network admins to voluntarily apply a hash function just
to get a quasi unique prefix, unless the protocol stack does it for
them.

This means that what we really need a site-local prefix
autoconfiguration specification similar to the link-local address
autoconfiguration.

	MikaL

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 23 Nov 2002 23:02:35 +0100

> two corporations were using 10.0.0.0)

Following the discussions from the WG meeting I would rather say that 
this points to one of the disadvantages of site scopes. Now we are 
trying to get around those with even more complexity...

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 23 Nov 2002 23:18:26 +0100

> (and theirs') a whole lot easier."

Good point!

> trying to work out how I might use site-locals in large IPv6 network.

Uhm, why not go with what you proposed above instead?

- kurtis -

---

From: Mark Smith <[email-masked]>
Date: 24 Nov 2002 10:17:17 +1100

> Uhm, why not go with what you proposed above instead?

As I understand it, the goal we are trying to achieve with site-locals
(whatever model you follow), is to have locally controlled and assigned
address space, independent of the global address space your provider
gives you.

I agree, if your global address space assignment from your provider is 
stable enough, and you don't have a requirement for addressing
independence, you could simplify your network even further, and not use
site-locals in any form at all. 

Using site-local and global addressing concurrently provides separation
of internal verses external connectivity, which then allows external
connectivity (and the associated global prefixes) to be changed, with
(or at least this appears to be the goal) no impact on internal
connectivity.

What I think the new (pseudo?)globally unique site-local addressing
models are doing is extending the scope of internal communications from
a site (geographical or otherwise), to potentially global ie. they are
saying that the potential for internal communications may be global, so
let's create a separate address space with global uniqueness, but only
for use with internal communications.

For actual external communications, use existing publicly routable
global addressing.

Once all the organisations connected to the IPv6 Internet have globally
unique site-local addresses, an illogical progression would be for them
all to connect themselves up via backdoor connections - to the point
where the actual Internet could be switched off :-)

However, they will face the same route table explosion / aggregation
problems that the real Internet already has, as well as the associated
security problems, and will probably leave global connectivity up to the
people who make it their business to do it properly - ISPs. 

Mark.

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 23 Nov 2002 20:37:26 -0500

Hi Mika,

>autoconfiguration specification similar to the link-local address

There was a Zero Configuration (zerouter) BOF held in Atlanta
that dealt with the subject of how prefixes can be automatically
delegated to routers.  I agree that it is something we need to
enable plug-n-play multi-subnet networking.  And, even though
we're not currently planning to pursue this in IPv6, there
may be a zerouter WG coming that will deal with it.

Margaret