Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses

From: <[email-masked]>
Date: Mon, 26 May 2003 14:48:14 +0300

Hi Brian,

One small question:

> I agree with kre completely up to this last point. It's more than
> warm fuzzies. It is correct that if I pay 10 Euros for a copy of
> the number "181:8008:7134", there is nothing to stop someone else using 
> it. But in fact, if I get my copy of "181:8008:7134" from a registry that 
> promises never to give anyone else a copy of it, then it's easy to decide 
> who wins if I ever encounter a clash with another copy of 
> "181:8008:7134".

What is the decision making process, though?  How do you 'prove' ownership
of "181:8008:7134"?  

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: Brian E Carpenter <[email-masked]>
Date: Mon, 26 May 2003 16:07:25 +0200

> What is the decision making process, though?  How do you 'prove' ownership

That is indeed the argument for escrowing the identity of the 
"purchaser" of each number, as suggested in Bob's draft. But maybe it
would cost more than 10 Euros to extract an entry from the escrow
archive.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Tue, 27 May 2003 13:42:19 +0700

Date:        Mon, 26 May 2003 16:07:25 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | > > it. But in fact, if I get my copy of "181:8008:7134" from a registry that
  | > > promises never to give anyone else a copy of it, then it's easy to decide
  | > > who wins if I ever encounter a clash with another copy of
  | > > "181:8008:7134".

I should have asked this when you first said that, but how?

You (quite correctly) said "a registry".   If you go spend your 10 Euros
on the number from one registry, and I go spend my 10 Euros from another
registry, and they both issue us the same number, who wins, and why?

How/why is one registry to be preferred over another?   By what legal
fiction would one organisation's right to sell numbers for money be
able to be judged better than anothers?

Note that this is quite different from "routable" numbers, where what
is really being obtained (sold, leased, loaned, whatever) is the right
to have the number installed in one particular instance of the global
routing table - with most people preferring the one that everyone else
is also using (which does nothing to prevent someone else selling the
same right wrt some other routing table - that's just not likely to get
very many customers).

The same is true of domain names, where what is really being "sold" isn't
the name, but the slot in the DNS zone file.

But with numbers that are just numbers and no more than that?

kre

---

From: George Michaelson <[email-masked]>
Date: Tue, 27 May 2003 17:25:49 +1000

On Tue, 27 May 2003 13:42:19 +0700 Robert Elz <[email-masked]> wrote:

>   | > > it. But in fact, if I get my copy of "181:8008:7134" from a registry
>   that| > > promises never to give anyone else a copy of it, then it's easy to
>   decide| > > who wins if I ever encounter a clash with another copy of
>   | > > "181:8008:7134".
> 

Nobody wins. If the registrys reflect current RIR, then this is not supposed to
happen, the freedom to choose one or another should not permit them to both
allocate the same space, and if they can, the system has a bug. Of course, for a
non-RIR registry, I can't say. But, then, you maybe got a telephone number and
not an Internet address. What did you ask for?

> able to be judged better than anothers?

In the current legal fiction, there is some top-level co-ordination that
guarantees the field of [0 .. 2**(129-1)] is divided up into non-overlapping
unique spaces (albeit as a sparce matrix, but none-the-less semi-enforced)

To all intents and purposes, ignoring policy differences, 'legally' routable
'integers' cannot overlap.

Of course, there is no (binding) definition of 'legally' here, but by common
convention, the ones coming down from IANA are disjoint spaces. They do not
overlap, and even under flat /32 allocation, they will not overlap unless there
is a BUG in common registry, which will be fixed on being detected.

Now, if you posit some registry outside that agreement (eg, to hypothicate, lets
imagine RF ID tags, or ENUM E.164 mappings), and by some  awful stuffup that
becomes an overlapping number space in the integer field, which has other
behaviour, your question becomes more important.

But, if we stick to "one IANA to bind them" then under current policy, and
predictable grandfather clause "thats not allowed" is a valid answer.

> same right wrt some other routing table - that's just not likely to get

Yes. But one of the things here, is that current number registries go out of
their way NOT to guarantee routability, but do go out of their way to guarantee
uniqueness in the common space. And a non-trivial number of complaints to
registry reflect peoples concerns to keep that true. (eg when ROUTING registries
collide in routing assertions)

> the name, but the slot in the DNS zone file.

No, that is different. It *looks* the same in this measure, but you must not
collapse the side effects of a zonefile structured tree, with the integer space.
They aren't the same for all purposes.

> But with numbers that are just numbers and no more than that?

These are not 'just' numbers: we polish the inside arc of the zeroes by hand. 

There are numbers, there are unique numbers, and there are uniquely allocated
numbers. The last kind is what you want I think.

I try to tell my son there really is only one number "three" -If I call it into
use to enumerate three pieces of fruit in the bowl, then some poor sod over in
russia has to forget he has three bottles of vodka, and I don't know how many
lumps of yellow sphere I have once an Icelander needs to count herring in
triplicate.

Not suprisingly, he thinks this is potty. But in Internet addressing space,
there really is only one ::3 I think. And, this is a good thing. 

Or, its not the Internet. 

-George

-- 
George Michaelson       |  APNIC
Email: [email-masked]    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Tue, 27 May 2003 09:40:53 +0200

>   | > > who wins if I ever encounter a clash with another copy of

Let's not restart the ICANN wars here over a trivium. Like any other
registry, we make it unique and its authority would come from IANA. 
As Bob's draft says, safeguards are needed to ensure that if it makes
a profit, it would be used for the public good.

> the name, but the slot in the DNS zone file.

Well, I think we also have running code to prove that people value
hanging off the unique root, since despite dire predictions we still
seem to have a single namespace.

> But with numbers that are just numbers and no more than that?

What you get for 10 Euros is *only* the assurance that the same
number hasn't been given to anyone else. If you think that isn't
worth paying for, don't use the service (that's why I believe there
should be a non-registry alternative).  

Another way to look at it is (using my example prefix) that IANA
has delegated FC00::/8 to a particular registry, and that
registry has chosen to sell non-aggregatable /48 prefixes
for 10 Euros each. If they stay in business, fine; if they go
bust, that's fine too.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Tue, 27 May 2003 15:18:01 +0700

Date:        Tue, 27 May 2003 09:40:53 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Let's not restart the ICANN wars here over a trivium.

I don't want to, but someone sure will.   This is exactly why the WG
declined to go down this path way way back when it was first being
discussed (you may remember that it was me who proposed this, a long
long time ago).

  | Like any other
  | registry, we make it unique and its authority would come from IANA.

Sure, we can do that, as we do for the root zones for the DNS.   But,
we know that has competitors - they exist, even though the names they
sell are useless for most practical purposes.

The numbers we're talking about would be just as useful as any others,
as they have no function beyond being numbers.   Anyone can compete.
What's more, with a number space between 38 and 45 bits (depending upon
what eventually happens) lots of people would have lots of opportunity
to get very rich, before anyone even notices that there are any duplications
occurring.

  | As Bob's draft says, safeguards are needed to ensure that if it makes
  | a profit, it would be used for the public good.

It has to make a (BIG) profit - as the price has to be set artificially
high to prevent speculators simply claiming the entire number space, and
then reselling it all later, once it is exhausted.   Even with a 45 bit
number space, that's entirely possible, if the numbers were sold at
anything even approaching the real cost of doing so.

This is exactly what will encourage others to shove in their oar.

  | Well, I think we also have running code to prove that people value
  | hanging off the unique root, since despite dire predictions we still
  | seem to have a single namespace.

What running code?   All the obvious examples are where the uniqueness
is useful for something.

  | What you get for 10 Euros is *only* the assurance that the same
  | number hasn't been given to anyone else.

But how could anyone offer that assurance, when someone else could be
giving out the same number?   Someone with just as much right as the
IANA to allocate meaningless numbers...

The only assurance that anyone could really offer is that they won't
allocate the same number to anyone else.    Is that worth the 10 Euros
when someone else will offer the same thing for 5 ?

  | Another way to look at it is (using my example prefix) that IANA
  | has delegated FC00::/8 to a particular registry, and that
  | registry has chosen to sell non-aggregatable /48 prefixes
  | for 10 Euros each. If they stay in business, fine; if they go
  | bust, that's fine too.

But why does Mr X care what IANA has allocated, he can sell /48's in
FC00::/8 just as easily as the "particular registry" can, and most
likely can sell them a lot cheaper, as he doesn't care if speculators
buy out his whole supply (in fact, X would probably love that, and
even offer a discount, at even 0.01 Euro's per number, 2^40 numbers
adds up to a tidy sum!)

As I said in an earlier message, if we want to pretend that the numbers
are going to be unique, we have to have something that only works if
they are in fact unique.   Here there's nothing.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 27 May 2003 15:26:19 +0700

Date:        Tue, 27 May 2003 17:25:49 +1000
    From:        George Michaelson <[email-masked]>
    Message-ID:  <[email-masked]>

George, I suspect that you haven't been following the whole discussion...
(aside from anything else, it certainly isn't the RIRs that it is
currently expected will allocate these things - though, as in my reply
to Brian, anyone could, and the RIRs might just as well, along with
everyone else, and their dogs, cats, and other miscellaneous pets).

  | What did you ask for?

A number.   It isn't useful as an Internet address (by design), it
is just a number.

  | Yes. But one of the things here, is that current number registries go out of
  | their way NOT to guarantee routability,

OK, I was using shorthand terminology - with regular 'routable' addresses,
the registries make known to whom the addresses are assigned, and then
those who run the routing systems make use of this data (guaranteed or
not by the registries, they do) to determine who gets to advertise routes
to where.   That's fine, and all very useful, and the same will continue
for IPv6 as it has for IPv4 (hopefully with better aggregation).

But that's not what we're talking about here - the issue is numbers that
are deliberately not made available to the routing system, the identities
of the registrants is (as proposed) not generally available to anyone.

  | No, that is different. It *looks* the same in this measure, but you must not
  | collapse the side effects of a zonefile structured tree, with the integer
  | space.  They aren't the same for all purposes.

Of course not - but for this example, they're both cases where the
uniqueness of the number is useful for some purpose, other than being
a unique number.   In the current proposal, there's no other purpose.

  | There are numbers, there are unique numbers, and there are uniquely
  | allocated numbers. The last kind is what you want I think.

The question is why does anyone want that?   What's it useful for?

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 May 2003 13:22:23 +0200

Robert Elz wrote:
...
(deleted lots of agree-to-differ stuff)
...
> they are in fact unique.   Here there's nothing.

Yes there is. As Bob Moskowitz discovered ages ago on ANX, and others have
discovered since, you can't operate VPNs among a set of users of Net 10 
in any reasonable way, and of course the same applies to a set of users 
of FEC0::/10. The problem goes away with unique /48s under FC00::/8.

Now, as a pragmatist, I would probably settle for a pseudo-random
and probably-unique /48, but not everybody will. I can just imagine a
phone call in which I recommend to IBM's chief network architect to use
address space that *probably* nobody else is using.

Do other people think we need a guaranteed-unique mechanism
for limited-scope addresses, or is probably-unique enough?

   Brian

---

From: George Michaelson <[email-masked]>
Date: Tue, 27 May 2003 21:56:02 +1000

> George, I suspect that you haven't been following the whole discussion...

fair call. I do have ipng archives here in front of me, but I dived in.

> everyone else, and their dogs, cats, and other miscellaneous pets).

But like I said, the current experience shows that excluding routability we KNOW
we can use a unitary-rooted process to divide the number field into disjoint
pools to allocate from. We know this works, and although its a self-supporting
circular logic, we mutually trust it and exclude private allocations into the
same space precicely because uniqueness appears to be good, and maintainable.

(and one suspects things like so-bgp or s-bgp, if they happen, will only tend to
 increase enforced/trust state in routing but thats another issue...)

I didn't say 'we will do it' but I did try to say the RIR do stand as an
existence proof. Man-and-his-dog selling snake oil leads to more bad scenarios
than requirement to follow known working practices here surely?

> A number.   It isn't useful as an Internet address (by design), it

numbers have properties. exclude ordering, or any properties on the bitmask and
apart from uniqueness, there isn't much left. are there enough prime numbers in
the space we can all have one to seed our own crypto? I'd say not in the
'relatively large' end of the spectrum. I really think either we do value
uniqueness, and so perpetuate it, or not. Hmm. I'll go with perpetuating it for
now if thats ok. 

> 
>   | Yes. But one of the things here, is that current number registries go out
>   of| their way NOT to guarantee routability,
> 

But the property of uniqueness is preserved, if the processes followed in
allocation preserve the same behaviours, of making <n> RIR look like one
functional body, in as much as a shared pool is allocated with (at least) one
useful condition: ie uniqueness.

> 
>   | No, that is different. It *looks* the same in this measure, but you must
>   not| collapse the side effects of a zonefile structured tree, with the
>   integer| space.  They aren't the same for all purposes.
> 

Come on. We all know technology has failings. routers are going to have to be
configured here. If I heard the sense of the room right at the last two sessions
of IPNG-like discussions at IETF right, people want to be able to know that
their non-routed addresses aren't masking somebody elses routables, if
non-routables are going to exist. They want to be able to apply sane, simple
logic to the decision on what to do. 

> The question is why does anyone want that?   What's it useful for?

Peace of mind. At a lowish cost of adopting processes broadly in line with what
we already know we can do. 

Plus, the ability to defer a decision to change ones mind later on.

-George

---

From: Bob Hinden <[email-masked]>
Date: Tue, 27 May 2003 11:59:05 -0700

Brian,

>for limited-scope addresses, or is probably-unique enough?

My take on the discussion is that we need both.  There are organizations 
who prefer to go to a registry to get some guarantee of uniqueness and 
others who prefer to generate a prefix themselves.

Your earlier suggestion of

>I wouldn't have a problem with a variant of Bob's proposal in which
>(for example) FC00::/8 is followed by a 40 bit ID allocated as Bob
>suggests, and FD00::/8 is followed by a user-assigned 40 bit ID.
>Then FC00::/7 would be the prefix for all limited-scope addresses.

appears to be a reasonable approach where the 40 bit ID under FD00:/8 would 
be selected by running an algorithm that would have to be specified.

There is a clear tradeoff between a longer ID (to allow for better random 
numbers or MAC addresses) and the size of the subnet field.

Before revising the draft, I would prefer to hear from more people on these 
tradeoffs.

Bob

---

From: Brian Haberman <[email-masked]>
Date: Tue, 27 May 2003 15:34:02 -0400

> others who prefer to generate a prefix themselves.

I agree.  There are justifications for both approaches.

> appears to be a reasonable approach where the 40 bit ID under FD00:/8 
> would be selected by running an algorithm that would have to be specified.

Yes.  Not a hard algorithm to come up with either.

> 
> There is a clear tradeoff between a longer ID (to allow for better 
> random numbers or MAC addresses) and the size of the subnet field.
> 
> Before revising the draft, I would prefer to hear from more people on 
> these tradeoffs.

I like Brian C.'s alternative suggestion.

Regards,
Brian

---

From: Zefram <[email-masked]>
Date: Tue, 27 May 2003 20:38:20 +0100

>Before revising the draft, I would prefer to hear from more people on these 

Although I was one of those that suggested a technique that would generate
/56 prefixes, I see great value in arranging for /48 prefixes where
possible, for uniformity with RFC3177.  For randomly-generated addresses
(both centrally allocated and individually allocated), an 8-bit format
prefix and 40 bits of randomness seems like a good tradeoff.  40 bits
seems to be about the amount of entropy we're aiming at, and a handful
of bits either way makes no difference.  An 8-bit format prefix is not
too wasteful of address space.

The case for which I suggested /56 prefixes was generating a prefix
from a MAC-48.  In that case, with 46 effective bits of identifier
to fit into the prefix, we clearly can't get a /48.  It seems like a
valuable technique, but would have to be an exception to the /48 rule.
Of course, any site needing more than eight bits of subnet ID is likely
to have many MAC-48s to play with if they have any at all.

-zefram
-- 
Andrew Main (Zefram) <[email-masked]>

---

From: Robert Elz <[email-masked]>
Date: Wed, 28 May 2003 18:50:14 +0700

Date:        Tue, 27 May 2003 13:22:23 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Yes there is. As Bob Moskowitz discovered ages ago on ANX, and others have
  | discovered since, you can't operate VPNs among a set of users of Net 10 
  | in any reasonable way,

Of course not.

  | and of course the same applies to a set of users of FEC0::/10.

It applies to a set of users under FEC0::/48, yes, certainly.
Whether it applies to FEC0::/10 or not depends upon what the users
have done with the other 38 bits.

  | The problem goes away with unique /48s under FC00::/8.

It would, if they were unique.

  | Now, as a pragmatist, I would probably settle for a pseudo-random
  | and probably-unique /48, but not everybody will.

Anyone who doesn't is deluding themselves, as that's all they're going
to get, without some method of verifying the uniqueness (some that
everyone must use for the number to be useful).

  | I can just imagine a phone call in which I recommend to IBM's chief
  | network architect to use address space that *probably* nobody else is using.

How are you ever going to be able to do better.   Or rather, if you like,
once IBM gets such a number, you leak it to me, and then I'll guarantee
that someone else is using it...

What you're getting here is really just some kind of belief that if there
is a conflict, you have some justification for claiming that my version of
3 is the one true 3, and everyone else is a fraudulent copy (and in the case
above with IBM, mine would be, obviously, but not necessarily all others).

  | Do other people think we need a guaranteed-unique mechanism
  | for limited-scope addresses, or is probably-unique enough?

What people want is nice.   How you actually get a a guaranteed-unique
number is another question, and one I am still looking for an answer to.

That is, without some means of ensuring the number is unique, which to
me, means making use of the uniqueness in some way (ie: non-unique numbers
don't work usefully) I can't see any method at all of actually guaranteeing
uniqueness, as anyone can, maliciously or not, simply make up any number
they like, and use it.   And the number they make up might be the same
number as the number you paid for.   And really, their right to make up
numbers is no less than anyone else's (including IANA, ICANN, ...).

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 28 May 2003 19:03:14 +0700

Date:        Tue, 27 May 2003 21:56:02 +1000
    From:        George Michaelson <[email-masked]>
    Message-ID:  <[email-masked]>

  | But like I said, the current experience shows that excluding routability
  | we KNOW we can use a unitary-rooted process to divide the number field
  | into disjoint pools to allocate from.

Of course we can, that we can do that isn't the question.   The question
here is why I, as a customer, would go pay you 10 Euros for a number
allocated this way, when "Joe's cheap numbers" is selling them at 1000
for 1 Euro ?   What is special about a number allocated by the "blessed
agency" in the case we're discussing?

  | numbers have properties. exclude ordering, or any properties on the
  | bitmask and apart from uniqueness, there isn't much left.

The only property that actually matters to the numbers in question,
the only one that the vast majority of people will ever care about,
is that it is N bits (for some N not yet fully decided, nor does it
matter much what N it is).

Nothing else really matters for most organisations.   Uniqueness is
irrelevant for all but a few, and even those few only really need
the number to be unique among their peers (and perhaps their peers)
that is, perhaps a few thousand sites, maybe 100K, which a random
number in a large enough N bits will almost certainly provide.

Don't misunderstand me, I'd like and prefer unique numbers.   But I
won't be a party to telling people that's what we're providing, unless
we really are providing numbers that are unique (with at least a very
high degree of confidence).   For a "central allocation" method of making
them unique, that means we need a high degree of confidence that the
one central authority is the only one that can ever exist (there needs
to be a reason for that).

  | But the property of uniqueness is preserved, if the processes followed in
  | allocation preserve the same behaviours, of making <n> RIR look like one
  | functional body, in as much as a shared pool is allocated with (at least)
  | one useful condition: ie uniqueness.

George, I know it can be done.   The question is why anyone would bother
to do it - or more correctly, why *everyone* would bother to do it.
All it takes is one exception, and uniqueness is gone.

  | If I heard the sense of the room right at the last two sessions
  | of IPNG-like discussions at IETF right, people want to be able to know that
  | their non-routed addresses aren't masking somebody elses routables,

Yes, of course, that's important.   But all that takes (and what these
various slightly different proposals all provide) is a common prefix
that says "no routable addresses in this block".   So, you can take
that as a given.   My non-routable address doesn't need to differ from
your non-routable address for this to work, unless we happen to want to
use them to communicate.

  | > The question is why does anyone want that?   What's it useful for?
  | Peace of mind.

But from where does that come, when you know that anyuone else who likes
can simply use the same number you are using, accidentally, or maliciously,
and not suffer at all because of that (nor for that matter, do you suffer).

  | Plus, the ability to defer a decision to change ones mind later on.

Change one's mind about what?

kre

---

From: George Michaelson <[email-masked]>
Date: Wed, 28 May 2003 22:42:52 +1000

> agency" in the case we're discussing?

Strong admission checks into routing are going to make Joe's numbers
less useful. Rhetorical questions aside, minor flaws don't stop people using
systems which are 'modelled' as being perfect. Whats special is that the agency
is seen to operate in a public policy/governance space, to not do what Joe does.

Whats special is that for a larger space of routing, the behaviours work 'well
enough'. If you want to deliberately go and break the global routing cloud you
can do that. Sooner or later, you wil be caught. People even went and showed
they could run alternate roots in DNS. But your punters, people who bought a
thousand from Joe for $10 instead of leasing one from an RIR for $100, only do
that once, if they fall into a hole fast enough.

In this matter, there are no bargains. If you seek to avoid or buck the system,
you will pay a cost, in some measure. 

> number in a large enough N bits will almost certainly provide.

Yes. And, if you select a suitable prefix, I don't see any reason not to say
"this prefix is for sites to use random selection methods to get 'nearly unique'
addresses, if you want that. People who don't want to see this can filter it!

> to be a reason for that).

We appear to have reasonably high confidence in that process already. We appear
to have an administrative process for complaints when it breaks down, as well.

I think claiming the percentage of bad against good can only get worse would be
true, but is that enough to decide to do something else? depends on the slope of
the line...

> All it takes is one exception, and uniqueness is gone.

No. this is like 'relatively prime' -if you are *reductionist* then you can't
run an Internet anyway. one exception doesn't break 'practical' uniqueness. 

Nothing can stop somebody sniffing the wire, seeing an address, and deciding to
try and add routes against it. even secured BGP won't be 'total' in that
respect.

We've been living with 'good enough' for a long time, in a lot of different
fields, not just Internet/Networking. How many more than one does it take to
make uniqueness practically useless? I think a HELL of a lot more. 

>   | of IPNG-like discussions at IETF right, people want to be able to know
>   that| their non-routed addresses aren't masking somebody elses routables,
> 
> your non-routable address for this to work, 

> unless we happen to want to use them to communicate.

Big unless. Very big unless.

Now add back VPNs. one block+NAT is less useful than globally unique.

its not about single point decisions. If 2 reasons exist making it
useful isn't that enough? When you argue against one, does the other disappear?

> and not suffer at all because of that (nor for that matter, do you suffer).

Well increasing trust in the routing cloud is a bigger problem. You need an
identity check on the address, out of band, or some other mechanism like strong
admission control to the routing cloud. Both of which either exist, or are in
planning.

I think a significant number of people continue(d) to use Sun's address space
precisely because there is huge locality of reference in most of the network,
and when there isn't the access path is mediated (proxies, caches, indirect
access methods, name-to-address shifts) anyway. People re-using other address
would see local service fine, and have a small percentage of problem in the
wider net which was inexplicable unreachables (for them) and find ways round
them (like proxies) or else debug it, and then fix their addressing model.

> Change one's mind about what?

About needing uniqueness. You can leave the egg whole and break it later, but
its harder to glue it back together if you break it first and change your
mind...

-George

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 28 May 2003 09:29:59 -0700

George Michaelson wrote:
> ...
> >  What is special about a number allocated by 
> the "blessed
> Strong admission checks into routing are going to make Joe's 
> numbers less useful. 

Admission checks by which authority? Remember we are talking about
prefixes which are defined to not exist in the global public routing
system. That makes them completely useful between private routing peers,
until there is a duplication.

> Rhetorical questions aside, minor flaws 
> don't stop people using systems which are 'modelled' as being 
> perfect. Whats special is that the agency is seen to operate 
> in a public policy/governance space, to not do what Joe does.

The IETF does not have a good track record in the policy space. The
numerical registry space is better, but not perfect (how many port
numbers were assigned after the fact???). I believe the root of kre's
concern is that we don't approach the governance space with the
appropriate attitude. We need to admit up front that numbers will never
be absolutely unique, and that some people will want to make up their
own for completely random reasons. All we can do is define a single
rooted registry with a to-be-defined conflict resolution process, and a
space for those who want to do their own thing. We must not define the
business aspects of the registry.

Tony

---

From: George Michaelson <[email-masked]>
Date: Thu, 29 May 2003 05:42:55 +1000

> until there is a duplication.

No, we're talking about a complete system. The strong admission checks are on
the other side, in the global routing cloud, excluding these things. The win for
the private routing cloud is a much lower chance of address collision for
arbitrary non-global connectivity, which for the large corporate sector getting
into trade federations outside of the Internet (banks, manufacturing) would seem
to me to be worth trying to achieve.

> business aspects of the registry.

I can live with that. I think thats a good position to take on this.

Remind me: why isn't this done outside of routing space via flag-bits or
something like multicast ttl scope? I would have thought that was always going
to be faster to process in router/switch/host firmware or close-to-port logic.

If the localization of the address has to be a property of the address, but all
addresses are otherwise flat in routing ACLs then I really don't see what the
advantage is in explicitly adding non-rooted allocation processes.

But I can see why people want the claimed uniqueness to be qualified.

As to 'business aspects' I think thats outside IETF, but some bodies *do* want
to define that. I think preserving the routing cloud as a commons demands it.

cheers
	-George

---

From: Robert Elz <[email-masked]>
Date: Thu, 29 May 2003 20:34:45 +0700

Date:        Wed, 28 May 2003 22:42:52 +1000
    From:        George Michaelson <[email-masked]>
    Message-ID:  <[email-masked]>

  | Strong admission checks into routing are going to make Joe's numbers
  | less useful.

Huh?   My numbers are never going anywhere near anyone's admission
checks, except mine.   If I want to communicate with the world, I will
have, and need, regular global (routable) addresses.

The issue here is not that my numbers aren't unique, as I expressly don't
care, but that someone else thought they were getting a unique number, and
paid for that, and it turns out that their number is just the same as the
one I'm using - that is, they didn't get what they paid for at all.

If you're promising to sell duck eggs, duck eggs better be what you're
providing, just hoping that the eggs you supply never hatch, and so no-one
ever finds out they were emu eggs isn't good enough.

  | If you want to deliberately go and break the global routing cloud you
  | can do that. Sooner or later, you wil be caught. People even went and showed
  | they could run alternate roots in DNS. But your punters, people who bought a
  | thousand from Joe for $10 instead of leasing one from an RIR for $100,
  | only do that once, if they fall into a hole fast enough.

Yes, that's fine - provided that there is something that doesn't work
for the "bogus" number.   Here, for almost everyone, there's nothing at
all that doesn't work for any number they simply invent.

Maybe major corporations will want numbers that don't conflict with
those of other major corporations, just in case they ever do want to
use the things for direct communication.   They'll probably pay whatever
fee is involved.   That's fine.   Just don't try and tell them that the
numbers allocated are "unique", because they're not - except with the
domain of end users who obtained their numbers from the same base source.

For us, as protocol designers, what this means is that no matter what
we do, nothing, anywhere in this space, can ever be assumed to be a
unique number.   In some operational environments the number is likely to
be unique (no-one else who matters is using the same one), which is fine.
But the protocols can *never* assume that.

  | In this matter, there are no bargains. If you seek to avoid or buck
  | the system, you will pay a cost, in some measure.

How?   Exactly what cost am I (on my private network at home) ever going
to suffer because of making up my own number instead of paying for one ?

  | Yes. And, if you select a suitable prefix, I don't see any reason not
  | to say "this prefix is for sites to use random selection methods to
  | get 'nearly unique' addresses, if you want that. People who don't want
  | to see this can filter it!

I expect all of this to be filtered just about everywhere.   Explicit VPN
type setups perhaps excepted (though even there, there's no requirement to
use these non-routable addresses - the sites will also have their global
addresses that they can use, a VPN after all is really just more trusted,
or less filtered, traffic that is known to come from a particular source,
it doesn't have to be using private addressing, and can be simpler if it
isn't).

  | No. this is like 'relatively prime' -if you are *reductionist* then you
  | can't run an Internet anyway. one exception doesn't break 'practical'
  | uniqueness.

If it is the right exception it most certainly does.

  | We've been living with 'good enough' for a long time, in a lot of different
  | fields, not just Internet/Networking. How many more than one does it take to
  | make uniqueness practically useless? I think a HELL of a lot more.

George, the problem is that if we claim that the things are unique, people
are going to start relying upon that.   That is, building protocols that only
work if the numbers are unique.  Or, in other words, one of the problems with
site-local addresses as we have them now is that they're not unique.   This
proposal is supposedly fixing that.   Except it isn't, and we must not fool
ourselves into believing that it is.   Nothing that had problems because
SL addresses weren't guaranteed unique will lave less problems with this
proposal.

That's fine as far as I'm concerned.

  | its not about single point decisions. If 2 reasons exist making it useful
  | isn't that enough? When you argue against one, does the other disappear?

Once again, it isn't that unique numbers aren't useful, it is that we have
no way to make such things.

  | >   | Plus, the ability to defer a decision to change ones mind later on.
  | > 
  | > Change one's mind about what?
  | 
  | About needing uniqueness. You can leave the egg whole and break it later,
  | but its harder to glue it back together if you break it first and change
  | your mind...

That's fine, provided uniqueness exists to begin with.   Here we have it only
if everyone agrees to play by the rules, and do the right thing.   Everyone.

Do you really believe that can possibly happen?   Remember the proposal here
is to have some entity selling up (up to) 2^40 numbers at 10 Eur each.
That's 10,995,116,277,760 Euros (11 US style trillion) available.
And the cost of obtaining the raw materials - 0 Euros.   The only costs are
the distribution costs (the cost of receiving and sending a packet per
number, and a system upon which to run it all), and the billing costs.

We've already seen people in the name space attempting to (and to a small
degree, succeeding) sell names that patently obviously couldn't possibly
work - do you really believe that there won't be similar people selling
numbers, that patently obviously work just fine (all that's needed is that
me and all my friends get our numbers from the same group if we plan on
using them between us)?

Tony Hain <[email-masked]> said:
  | I believe the root of kre's concern is that we don't approach the governance
  | space with the appropriate attitude. We need to admit up front that numbers
  | will never be absolutely unique, and that some people will want to make up
  | their own for completely random reasons.

Yes.  "We need to admit up front that numbers will never be absolutely unique"
Exactly.

But ...

  | All we can do is define a single rooted registry with a to-be-defined
  | conflict resolution process

I'm not sure this is possible (I don't mean technically possible, I mean
politically possible).   From where to we get the power to decide who is
the ultimate authority for numbers ?    As George pointed out, even for
the current (IPv4) routable numbers, the registries don't attempt to
promise that they're useful - it just happens by common consensus that
they are, but if one of the registries allocates you a number, and for
whatever reason it doesn't work, there's nothing really that you can do
about it (if you're really lucky you may get them to refund the fee).

Here, there's nothing requiring uniqueness for the numbers to be useful
(except for those few organisations that want VPNs between them, for which
the only requirement anyway is that none of the organisations involved are
using, or seeing, the same numbers).    I can imagine a VPN with a few
thousand members, much bigger than that, and I suspect that what you have
is just a public internet (that is, with all the same problems, of wanting
to be using topological addressing to make the routing scale sensibly, and
hence not wanting to distribute around "non-routable" numbers anyway).

Brian said that he wanted to avoid another ICANN nightmare (my words, not his).
He didn't say how he planned on doing that.   With 11 trillion Euros
available for someone (over time) there's sure going to be a lot of pressure,
both from organisations that want to get their finger in, and even from
governments who want all of that foreign exchange flowing into their country,
rather that flowing out to some other.   Is the intent here to just slip
this through and hope that no-one notices?

kre

---

From: Hans Kruse <[email-masked]>
Date: Thu, 29 May 2003 20:45:58 -0400

I actually see a lot of value in the /56 proposal;  I really like the 
simplicity of creating the /56 from any MAC-48 in the network.  It 
accomplishes the uniqueness property without requiring central 
registration, and should serve organizations up to considerable size very 
well.  And it readily discourages the notion of "make up a prefix" for 
temporary or (temporarily) disconnected networks.

In the applications I can envision, a /56 should work fine, and an 
organization can "make more" based on additional MAC-48s.

The draft might contain some language like "An organization using this 
method for creating unique network prefixes SHOULD (or MUST?) retain 
physical custody of the network device contain the MAC-48 used to define 
the prefix, for as long the prefix is in use".

The way globally unique /48s based on a central registry are really only 
needed for very large organizations.

> to have many MAC-48s to play with if they have any at all.

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
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: Benny Amorsen <[email-masked]>
Date: 30 May 2003 07:23:32 +0200

> temporary or (temporarily) disconnected networks.

I have been lurking in this discussion by reading it as a newsgroup over
at gmane.org. (I tried to post too, but even though gmane.org said it
was posted, I do not think it reached the mailing list.)

It seems to me that things would be easier by letting people invent
their own numbers by whatever method they prefer. Then, if they care
whether the numbers are unique, they can register the numbers they
picked in one or more registries. This way they can be assured that
other well-behaved people will not use the same numbers, and at the same
time it is clear to everyone that the numbers are not /guaranteed/ to be
unique.

Later when two organisations need to connect to each other directly and
the numbers conflict, I bet the organisation that registered its numbers
has a good chance of being the one not having to renumber...

By the way, I am not very fond of the MAC-address method. If we are into
misusing other registries, we could turn a phone number into hexadecimal
(including the international prefix.) 12 digits can be stored in 40
bit...

/Benny

---

From: Greg Daley <[email-masked]>
Date: Fri, 30 May 2003 16:01:15 +1000

Hi Benny,

Benny Amorsen wrote:
[part snipped]
> (including the international prefix.) 12 digits can be stored in 40

It's not that dumb an idea, it reminds me of
base-85 (RFC-1924) IPv6 addressing notation.

It certainly does solve the uniqueness issue
for any given instant.  What happens if you
're-number' your telephone?

Greg
:)

---

From: Robert Elz <[email-masked]>
Date: Fri, 30 May 2003 16:09:00 +0700

Date:        Fri, 30 May 2003 16:01:15 +1000
    From:        Greg Daley <[email-masked]>
    Message-ID:  <[email-masked]>

  | It's not that dumb an idea, it reminds me of
  | base-85 (RFC-1924) IPv6 addressing notation.

Which is a joke, not an idea (dumb or otherwise)...

  | It certainly does solve the uniqueness issue
  | for any given instant.  What happens if you
  | 're-number' your telephone?

This has the same problem as MAC addresses - it isn't stable (someone
else can quite validly end up with the number that used to be yours).

But, if abusing number spaces to try and gain easier uniqueness is
an aim, then a (less automatic but perhaps still reasonable) method
would be to abuse the IEEE OUI space (instead of the MAC address space).

That is, any organisation with an OUI (22 real bits big) has 18 bits
(256K) of numbers they can allocate however they see fit.   And of
course, organisations that the IEEE allows can go get new numbers.
(The IETF is one such organisation of course, so IANA would have
numbers to allocate).

(This re-use of numbers would not conflict with other uses of the OUI,
it would be in parallel, just as MAC48 and EUI-48 are - it would be
xxx-40 of course, or -45 or something, depending upon prefix length).

Of course, IEEE would probably need to agree to their number space
being abused this way before we could suggest it as a method.

Doing this still doesn't guarantee any kind of uniqueness, all it does
is provide a ready made answer to the "one monopoly organisation"
problem, while similtaneously making it effectively impossible for
anyone to snarf any large fraction of the address space (no need to
prescribe huge fees - like Eur 10).

Even adding in registries, as Benny Amorsen proposed, doesn't really
solve the problems.  To be unique, there'd need to be one overall
registry (perhaps sub-dividing the space to others) - which again means
one monopoly, with no real justification for anyone to be the owner of
that.   Further, it only helps if people actually register (otherwise
there are the same issues as with trade marks, where they can be held,
unregistered, for a very long time, etc - except we have no legislation
or case law to help with consistent reasonable answers to who wins).

Multiple registries just means more places to register, and would create
more confusion if A registers in registry 1, and B registers the same
number in registry 2 (perhaps at about the same time, perhaps not).

To actually get any kind of uniqueness, we need something that fails to
work if the numbers are duplicated anywhere - and as these numbers are
addresses, that really means that addressing has to fail.   I can't see
how that can possibly happen for numbers intended to be used only locally.

kre

---

From: Benny Amorsen <[email-masked]>
Date: 30 May 2003 23:36:40 +0200

On 2003-05-30 at 11:09, Robert Elz wrote:

> that.

The advantage of using multiple registries is that the problems are
obvious to everyone. No one ends up thinking that their number is
guaranteed to be unique. 
As you point out later, the addresses /cannot/ be enforced to be unique.
There were organisations which used 9/8 or 192/8 (not 192.168/16)
addresses for site local addressing in IPv4. An Internet Standard cannot
force people to comply.

I do not think there should be one top-level registry that subdivides
space to other registries. Rather I think each registry should pick
whatever bit of address space they feel like, within a single global
allocation for site-local addresses. If two registries pick the same
address space, too bad. Either they figure out a way to reconcile, or
customers will avoid them. If a registry takes too much space, the other
registries will ignore them.

Either way, anyone can set up their own registry of site-local IPv6
numbers. I think the working group should try to stay out of the fray,
except for setting aside a reasonably large space for it. A /16 would
seem appropriate.

Should site-local addresses end up not being standardised, there is
always 10/8 mapped with 6to4...

/Benny

---

From: Bob Hinden <[email-masked]>
Date: Fri, 30 May 2003 15:26:00 -0700

I don't follow this.  It seems to me that there are two points on the 
allocation spectrum that are useful.  At one end there is a central 
registry for organizations that are willing to pay something and want some 
higher assurance of uniqueness (and a way to reconcile disputes).  At the 
other end is local generation of pseudo-random identifiers.  If people want 
to set up web sites that generate the pseudo-random numbers for this 
purpose, that is fine too.  I don't see any need for something in between 
the two approaches.  The value of a registry is to have a higher guarantee 
of uniqueness.  Other than that they should be generated locally.

Bob

---

From: Hans Kruse <[email-masked]>
Date: Sat, 31 May 2003 16:48:51 -0400

I agree.

--On Friday, May 30, 2003 15:26 -0700 Bob Hinden <[email-masked]> 
wrote:

> registry for organizations that are willing to pay something and want
> some higher assurance of uniqueness (and a way to reconcile disputes).
> At the other end is local generation of pseudo-random identifiers.  If
> people want to set up web sites that generate the pseudo-random numbers
> for this purpose, that is fine too.  I don't see any need for something
> in between the two approaches.  The value of a registry is to have a
> higher guarantee of uniqueness.  Other than that they should be generated
> locally.