Subject: global-local draft and FD00/8 space

From: Andrew White <[email-masked]>
Date: Wed, 06 Aug 2003 13:50:18 +1000

Particularly focusing on the FD00/8 space...

I'll raise my sole dissention up front:

3.2.2 and 3.2.3 are unnecessarily prescriptive for local addresses.  Since
the goal is simply to get something which is 'good enough' unique, all you
need is a mechanism for choosing a number that no-one else is likely to be
using.

For /48, hashing from an EUI-48 is currently good enough, although you are
compressing 48 bits into 40 so it could possibly cause problems when the
EUI-48 space is saturated.

For /64 (ie by-subnet numbering), you can fit a full EUI-48 with some bits
to spare.

Operationally, the requirement is that the generated /64 prefix is unique
compared to anything that else that a given node will see.  Global
uniqueness is a sufficient but not necessary criterion.

Notice also that any two autoconfigured addresses are guaranteed to be
unique, since the EUI-64 interface identifier will be dissimilar even if the
/64 routing component is similar.  Breaches of the EUI allocation
notwithstanding.

My ultimate observation is that I fail to see how a FD00::/8 address with
site filtering differs in any meaningful way from an FEC0::/10 address, with
two exceptions:

(1) FEC0::/10 currently seems to allow overlapping disjoint scopes (ie an
address is ambiguous at a particular node except for scope id).  However,
many implementations seem to ignore this and assume a single scope.

(2) FEC0::/10 does not mandate uniqueness generation for subnet prefixes. 
This is a weakness, so don't deploy it without it.

Do I therefore object to FD00::/8?  Not at all.  Paint your wheel blue
rather than red if you like - I just want the functionality and two extra
bits can't hurt.  If redefining a chunk of the world is necessary to remove
scope specifiers from local addressing, go for it.

Though I will point out that once we ignore overlapping ambiguous scopes
neither FEC0::/10 or FC00::/7 addresses make any difference to application
writers.  You are still left with two broad classes of addresses:  those
which promise to be filtered, and those which you can't tell.  Unless we
allow only one address per node an application writer MUST assume that any
arbitrary source-destination pair may fail while another may succeed.

And as demonstrated previously, in the absence of other information the
local-local pair with longest prefix match is your most likely candidate for
a working connection.

-- 
Andrew White
--------------------------------------------------------------------
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: 06 Aug 2003 15:24:11 +0930

Hi Andrew,

> EUI-48 space is saturated.

As I see it, the problem is not so much that a hash of UI-48s wouldn't
be adequate for this purpose, the issue is that net admins / end users
would want to know which one of their 10, 100, 1000 or 10 000 etc.
EUI-48s in their network is best to use for this purpose.

Obviously it doesn't matter, but providing an explicit procedure to
generate the 'good enough' unique number that doesn't depend on one of
the EUI-48 values embedded in a device, will eliminate questions about
which is the best EUI-48 address to use from IPv6 mailing lists /
discussion forums, support lines etc, and possibly this mail list, even
when there is no best EUI-48 to use.

It also prevents people from making up an EUI-48 when they don't know
how to find out an EUI-48 from one of their devices. In that case, the
range of selected EUI-48s will become very predictable - I'd suggest we
would encounter a number of 00:00:00:00:00:00s, 11:11:11:11:11:11s, and
00:00:00:00:00:01s, in addition to the various, novel hexisms that
exist, such as my favorite, "ba:db:ad:c0:ff:ee"

Regards,
Mark.

---

From: Aidan Williams <[email-masked]>
Date: Wed, 06 Aug 2003 18:07:44 +1000

>when there is no best EUI-48 to use.
Doesn't exactly the same issue present itself with birthdays?
eg: Which is the best birthday to pick?  Mine or a descendents?
And all the unix guys will pick 1/1/1970.. ;-)

Having a procedure that can avoid asking the user to type anything in at all
(ie one that reads and EUI from a device) sounds like a good thing to me.

Using an EUI-48 also doubles the number of "unique" bits that are input
to the hash algorithm.  Birthdays are rounded to the day, regardless of
whether we represent them in 64bit NTP format.

The current time of day counter doesn't seem to me like it will generate
all that many unique bits either -- two (or more) routers configured around
the same time will have a whole lot of bits in common.

- aidan

---

From: Mark Smith <[email-masked]>
Date: 06 Aug 2003 18:37:32 +0930

> eg: Which is the best birthday to pick?  Mine or a descendents?

I don't think so, everybody has a favorite birthday - their own :-)

> And all the unix guys will pick 1/1/1970.. ;-)

Unfortunately, there are some unix guys whos' birthday IS 1/1/1970 !

I'm not familiar with the resolution of NTP, but I'd suspect it would be
something like milliseconds.

I'd think it is pretty unlikely that two people, at separate sites, with
the same birthday, were executing this algorithm at the same
millisecond.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2003 11:20:39 +0200

Andrew, you don't seem to see the *ambiguity* of FEC0::/10
prefixes as a major problem in itself, but operational experience
with 10/8 suggests that ambiguity is actually a bigger pain than
NAT in some scenarios (VPNs between two Net 10 networks, for
example). The virtue of Bob's proposal is that it eliminates this
ambiguity while conserving the perceived value of SLs.

As for being too prescriptive, I think it's important to specify an
algorithm that will give good enough results when applied blindly.
Are you arguing for a SHOULD here?

   Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Aidan Williams <[email-masked]>
Date: Wed, 06 Aug 2003 19:30:08 +1000

>something like milliseconds.
Sure, but nobody is going to type their birthday in to the millisecond.  
w.r.t the time stamp, part of it (the seconds part) is likely to be 
quite correlated between sites, and the lower part (micro-seconds) is 
more likely to be a randomly distributed number.

Now we could just go random and invoke RFC1750 and be done with it (a la 
NUSLA).
Unfortunately, people seem to implemented random number generators 
really badly.

>the same birthday, were executing this algorithm at the same
It is even less likely that the MAC address that came from an ethernet 
card will be the same in both sites..

- aidan

---

From: Mark Smith <[email-masked]>
Date: 06 Aug 2003 19:38:07 +0930

> card will be the same in both sites..

Ok, I think you might have missed the point of my original email, so
I'll try to re-state it :

1) If people have lots of choices, they would rather not make a choice,
particularly when they don't have the knowledge to make a value judgment
as to what the "best" choice is.

In this case, there is no value judgment to be made, but with say 100 -
1000 (or many more) EUI-48 addresses to choose from (remember, each
switch has a EUI-48 address per port), it will *feel* like there is a
value judgement to be made. And that will confuse them.

Too many choices can almost be as bad as not enough.

2) Even if you automate the process of generating a local range address
using a EUI-48 MAC address, which device do you perform it on ? For
example, with 200 routers, and multiple Internet connections (ie. so you
can't say the "Internet" router is the one to get an EUI-48 from),
again, you can have too many choices. Which router / interface is the
"right" EUI-48 source ?

3) Alternatively, if there was a manual EUI-48 entry prompt, to allow
people to select an arbitrary EUI-48 from their set, if they don't know
how to find out an EUI-48 address, and / or don't understand the value
in selecting a IEEE assigned EUI-48, they will enter 00:00:00:00:00:00,
or 11:11:11:11:11:11, etc.

These are people / technology issues, not just technology issues.

Bob's use of a ntp time stamp and the operator's birthday as the hash
input avoids these problems.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: 06 Aug 2003 19:48:36 +0930

On Wed, 2003-08-06 at 18:50, Brian E Carpenter wrote:

but operational experience
> example).

Combining the two is worse ... I spent two months _solid_ working to 
"productising" NAT with IPsec VPNs, in conjunction with Internet access
(eg NAT to VPN destinations, but not to Internet destinations; NAT to
Internet destinations, but not VPN destinations, NAT to both, but
1-to-Many to Internet, 1-to-1 to VPN, etc., etc,).

My advice to everybody is don't ever go down that rat-hole.

I still have nightmares...

Regards,
Mark.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 06 Aug 2003 11:25:25 -0400

>the same birthday, were executing this algorithm at the same

And even if they were, what do you think the chance is that their
companies will ever acquire each other, requiring them to merge
their private address space? :-)

Margaret

---

From: Aidan Williams <[email-masked]>
Date: Thu, 07 Aug 2003 10:42:03 +1000

>Too many choices can almost be as bad as not enough.
I'm pretty sure I get your point, I just don't buy it.
This isn't a complex decision for the user and software can help greatly.

>again, you can have too many choices. Which router / interface is the
It doesn't matter which one, software can pick one from the box you are 
performing the configuration on.

>or 11:11:11:11:11:11, etc.
Why would there be an EUI-48 entry prompt?  There is a need to 
configure/propagate around the hashed prefix that resulted from the 
computation, exactly as in the birthdate approach.

>input avoids these problems.
I don't think there are any "problems" with using an EUI-48 as an input 
to the hash that are avoided by the birthdate.  And it has the 
advantages of being able to be performed automatically, and of providing 
"good uniqueness" of bits.

Another approach might be to hash the admin's phone number.  (Ideally we 
could staple a whole phone number into the prefix, which would be cute 
from a debugging point of view.  Unfortunately with 41 bits we only get 
12 digits.)

- aidan

---

From: Aidan Williams <[email-masked]>
Date: Thu, 07 Aug 2003 10:55:51 +1000

> their private address space? :-)

Actually, this risk is exactly why I would like to make the selection 
algorithm for bits in the FD/8 space as bulletproof as possible.  In a 
previous life, I have spent too much time in the house of pain merging 
and renumbering networks that were behind IPv4 NATs when companies 
acquired each other.  Little companies do that quite a lot.  I also have 
little faith in user supplied input, and not a lot of faith in the 
implementation quality of an arbitrary random number generator.  Hence I 
would like to see local address disambiguation make use of any "good 
quality unique bits" we already have lying around, like EUI-48s.  I 
don't think that is a hard thing to do, so why don't we?

- aidan