Subject: RE: "unique enough" [RE: globally unique site local addresses]

From: "Michel Py" <[email-masked]>
Date: Thu, 21 Nov 2002 19:52:35 -0800

Kurtis,

> Kurt Erik Lindqvist wrote:
> Uhm, if they are truely unique, the only difference to
> global addresses is that they won't be routed - right?
> Now, what is the difference between that and using
> global unicast address space that you do not announce?

From the enterprise point of view the difference is that when a hacker
(or your own staff) screws up the BGP filtering, it will not go far
unless all ISPs in the Internet mess it up at the same time.

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: "Christian Huitema" <[email-masked]>
Date: Sun, 24 Nov 2002 12:31:47 -0800

> It is actually my (weak) understanding that taking more inputs 
> does not actually result in more "uniqueness", at least for 
> random number generation. 
> Does anyone know how that works for hashing? 

This is well explained in RFC 1750, Randomness Recommendations for Security, D. Eastlake, S. Crocker,
J. Schiller, December 1994. In short, you need to make sure that the various strings you are hashing provide you the desired level of entropy -- would be 38 bits in this example.

-- Christian Huitema

---

From: "Michel Py" <[email-masked]>
Date: Mon, 25 Nov 2002 08:24:12 -0800

>> Michel Py wrote:
>> My $0.02 about the hash/random/collision issue:
>>  It's a non-issue.

> Pekka Nikander wrote:
> I would agree with you, but only if I shared the same
> view of the GUPI prefix usage.

This much is clear.

  That is, if GUPIs are really used only by
explicit administrator action in big corporations, then fine.
But unfortunately I don't believe so.

> The prefix generation happens only one time for the site. Collisions
> would not be detected until two sites merge or establish a VPN
> connection.

Agreed.  Though, I can vision dynamic "sites" that are created
and dismissed fairly often.  OTOH, if we decide to define a GUPI
address space, we can formulate the usage guidelines so that
they should not be used in such a case, and that a still
another type of addresses are needed for such "sites".

> The site gets its GUPI /48 prefix once, then the network administrator
> configures all routers within the site with subnets that fit in that
> prefix. This could be automated, but the fact of the matter is that
> there needs to be a router somewhere that seeds this prefix. If what
you
> are talking about is automatic subnet number generation, this would be
a
> zeroconf issue.

Agreed.  But I can also see a "semi-automatic" case; a SOHO or non-IT
company configuring their network, and pushing a "button" to generate
a site prefix for their network.  Most probably they would not want
to pay the *trouble* of registering their prefix; still the fee might
be a non-issue for them.

A site note:  The reason for the registration fee is to discourage
prefix hoarding.  The fee can be lower than the trouble needed for
registering a single prefix.  (When registering multiple prefixes,
the trouble for the subsequent prefixes is much lower than in the
beginning, since learning is a big part of the initial trouble.)

> Besides the fact that making site-locals too easy is bad, I don't see
> why obtaining the prefix should be generated by a router. It is clear
> that the first thing the network administrator would do is to write
down
> the /48 s/he will be using, and would be the one requesting the prefix
> in the first place.

Hmm.  I would agree that this is the case today, more or less.
But, iff small sites become common, the situation would be different.

If I remember correctly, one of the design goals in the whole IPv6
standardization has been minimization of human intervention.  That's
the reason why we have address autoconfiguration, that's the reason
why we have been developing router renumbering etc.  Or am I mistaken?

Thus, I think that *if* we create these GUPI prefixes, their creation
should be semi-automatic.  Not fully automatic since they are not
always needed.  But, sure, we can start with a completely manual
process and revise it later, if people feel that there is some
danger is such a semi-automatic creation.

> Also, whatever the random/hash algorithm is chosen and published, it
> also is clear that the first thing that the network administrator
would
> do is to go to the web to find if someone has already written an
applet
> that would do the job.

There will be "sites" that do not have Internet access at the time
they want to configure their prefix.  Either they will hand pick one,
most probably causing unnecessary collisions, or the process should
be semi-automatic, with built-in assistance in routers or in router
configuration software.

--Pekka Nikander

---

From: "Michel Py" <[email-masked]>
Date: Mon, 25 Nov 2002 16:17:38 -0800

Tim,

>> Michel Py wrote:
>> As I mentioned before, we MUST NOT encourage the use of
>> site-locals for people that don't understand their
>> limitations, and this certainly applies to the SOHO
>> example you used.

> Tim Chown
> So how do I print to my net printer in between connections
> to my ISP when I get a different prefix each time I connect?
>  I want some kind of addresses to use locally equivalent to
> Net10. Not for NAT, but to communicate internally while
> offline.

This is a perfectly valid use of site-locals, my point was that we
should not generalize the use when there are alternative methods. To
some extent, site-locals are too easy. If you _choose_ to use them, OK.
But a router MUST NOT offer site-locals as a default.

>> Let me emphasize again that none of this stuff goes anywhere is there

>> is no default enforcement of non-routability along the lines that Bob

>> Hinden, Christian Huitema and myself have contributed, and I have not

>> heard many comments about that part.

> Indeed.  I'm a little confused that GUPI = site-local, nothing
> really new only we're (in PekkaS's method) just "randomising"
> which site-local is used, so all the bad things of site-locals
> remain

I hear that lots of the issues have something to do with ambiguity. By
making site-locals globally unique (GUPI) we remove ambiguity and take
some of the problems out.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 26 Nov 2002 07:57:23 -0800

Pekka,

> Pekka Nikander wrote:
There is just one thing that I want to repeat:
If you give people something that is globally unique and
stable, that is, something that looks, smells and tastes
as globally unique stable identifiers, they will start to
use them as such, sooner or later.
We should not underestimate the desirability of such
identifiers in the face of changing prefixes.
Not all innovation is limited within the IETF.

I totally agree with you, that's why I insist so much on enforcing
non-routability of these addresses by having both the default black hole
that Bob suggested and the default BGP discard that I suggested a while
ago. Without these, GUPI would be transformed into PI before we know it
and the routing table will explode.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Sat, 30 Nov 2002 19:24:18 -0800

> Margaret Wasserman wrote:
> Do you really think that it is realistic to just tell
> everyone to use provider-assigned addresses throughout
> their network?

No. Scores won't buy it. Let's not forget that one of the reasons behind the considerable success of NAT, despite its huge annoyances, it because NAT does provide some of the PI perks. PA is good for dial-up users and home/soho setups. Bigger, you find NAT, because for many the no-sweat ISP switch is worth more than the NAT-induced problems.

In my experience, the number one reason for going to RFC1918/NAT is an ISP change. The ISP pulls out of a market or tanks, the customer looks at my proposal for renumbering, chokes at the bottom line, and says "make sure we don't have to go through this again next time the ISP bellies up". Welcome to NAT.

Having two of the tier-1 ISPs in bankruptcy does not help this feeling.

> We've been getting feedback from network administrators that
> they need a form of local addressing that allows their
> internal numbering, firewall configuration, etc. to be
> independent of their ISP-provided addresses.

Network administrators want three things:

1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites.

2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). This is GUPI.

3. Global network layer PI identifiers. Although this is not directly linked to the multihoming issue, it is likely that a scalable multihoming solution would provide it.

I do not envision a large-scale deployment of IPv6 without providing all three. Also, it would be a hell of a good idea if 2. could migrate to 3.

> It is my belief that if we ignore this problem, and simply
> limit site-locals to disconnected networks (a la RFC 1918
> addresses), then IPv6 NAT will arise to allow sites to
> separate internal addressing from external addressing.

Agreed. And we should not underestimate the danger of this, as there is a lot of working v4 NAT code out there and transforming v4 NAT code into v6 NAT code is a lot less work that writing NAT from scratch 5 years ago. Most of the ALGs issues have been sorted out already.

> What we really need is a better way to solve this problem,
> one that doesn't have the problems of site-local addresses.
> And, that's why we're discussing GUPI addresses.

Agreed. Unfortunately, one of the main issues with GUPI addresses is managing the risk they end up being a mess in the global routing table, à la IPv4 swamp. So far, the lack of a multihoming solution has been a strong enough disincentive to kill GUPI attempts in the egg before they were even born.

Any GUPI proposal will have to address this.

Michel.