Eventually ARIN (or someone else will do it for them) may create a site
...
Did you mean something like this maybe ?:
Q.E.D.
The RFC seeks to avoid a registry so we end up with the potential for
many as a result. May as well have had ARIN do it officially in the
first place so there'd only be one.
brandon
The RFC provides for two address ranges in fc00::/7, one for random
prefixes (fc00::/8), the other reserved for later management (fd00::/8).
Sixxs "manages" prefixes from within the random one, there is as yet
nothing set up to properly manage the other one. Dunno why ARIN should
necessarily manage it; or any particular RIR for that matter.
The "random" one allows for swift, bureaucracy-free self-allocation. The
more important it is to you that your allocation be unique, the more
careful you will be to choose a truly random one. The chance that any
random prefix will conflict with any chosen prefix is very, very small.
The chance that two conflicting prefixes would belong to entities that
will ever actually interact is even smaller. Makes it an interesting
question as to whether the managed range is really necessary at all.
Regards, K.
Karl Auer wrote:
The "random" one allows for swift, bureaucracy-free self-allocation. The
more important it is to you that your allocation be unique, the more
careful you will be to choose a truly random one.
If it is that important, you'd prefer a managed solution, not a truly random one.
The chance that any
random prefix will conflict with any chosen prefix is very, very small.
The chance that two conflicting prefixes would belong to entities that
will ever actually interact is even smaller. Makes it an interesting
question as to whether the managed range is really necessary at all.
1) While the chance of conflict is small, it is not non-existent, and when the interaction does occur and a conflict does arise, there may be huge costs involved. Random is fine for small deployments. It is a horrifying prospect for a 500+ subnet network.
2) Managing non-globally routed addressing is easy and doesn't require a lot of overhead. IANA itself could manage it, as it does all other globally unique numbers. First come, first serve. Have a nice day. I enjoy my unique enterprise oid. Why shouldn't I enjoy my own unique non-globally routed address space identifier? There shouldn't be a need for justification of the identifier (or services such as whois), so pawning it off on a RIR seems silly.
Jack
Given our failure rate with registries of AS numbers, IP address blocks, and
routing table entries, and the fact we have no special reason to believe that
we'll be able to sprinkle Magic ULA Dust all over it and avoid all the failure
modes of registries, we're probably better off just randomly generating them
and just hope for no collisions.
If two (or four, or ten, or a thousand) ULA prefixes are chosen
randomly, the chance that any will conflict with any others is far, far
less than the chance that your staff will make a terrible, disastrous
mistake that puts you out of commission for weeks. And if you happen to
have contingency plans for that, they will do just fine for dealing with
a ULA conflict.[1]
And of course, to be an actual problem the conflicting prefixes have to
be in use by entities whose networks actually interact. Within an
administrative domain, uniqueness can be guaranteed anyway.
Winning a lottery is *far* more likely[2] than that a randomly chosen
prefix from the ULA range will conflict with any other prefix in the
same range, randomly chosen or not.
Regards, K.
[1] A ULA conflict is generally not going to require instant remedial
action. People planning interaction at a network level will (one
hopes!) do basic stuff like checking what prefixes are in use on
the two networks.
[2] Depending on the number of "players" in each "game", anything from
hundreds of times more likely to millions of times more likely.
So, back when ULA was first proposed, some of us said (sometimes privately) that there are only 2 rational options:
1. Do it; with a persistent, guaranteed unique, global registry.
2. Don't do it.
Option 2 was a non-starter since there was too much critical mass. The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.)
So given the overwhelming force pulling at this thing from both directions, you end up somewhere in the middle where no one wants to be.
And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins.
Doug
Eventually ARIN (or someone else will do it for them) may create a site
...
Did you mean something like this maybe ?:
Q.E.D.
The RFC seeks to avoid a registry so we end up with the potential for
many as a result. May as well have had ARIN do it officially in the
first place so there'd only be one.So, back when ULA was first proposed, some of us said (sometimes privately) that there are only 2 rational options:
1. Do it; with a persistent, guaranteed unique, global registry.
2. Don't do it.Option 2 was a non-starter since there was too much critical mass. The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.)
For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it?
So given the overwhelming force pulling at this thing from both directions, you end up somewhere in the middle where no one wants to be.
And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins.
Except in the case of ULA, hitting the jackpot is actually losing.
Owen
None of the "sides of IANA" pay for anything. There is no binding between what parties pay and what the ICANN staff who perform the IANA function do. In fact, those staff do not have any knowledge of whether any organization has paid anything (other than what they might hear incidentally).
The (zero dollar) IANA functions contract has 3 major functions, of which allocating blocks of addresses to the RIRs (and at the direction of the IETF) is one. Failure to perform that function would be interpreted as breach of contract, regardless of whether the RIRs pay anything to ICANN or not.
Regards,
-drc
Doug Barton wrote:
having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.)
whois. what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2.
And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins.
This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad.
Doug Barton wrote:
having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.)
whois.
what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry).
With the exception of a routing registry (which I wasn't aware was an address allocation requirement), these services are provided by ICANN as part of the IANA functions contract. Out of curiosity, why do you think providing whois, POC management/validity, and even a routing registry requires a large staff?
I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2.
As you note, ICANN already provides something like this as part of the protocol parameter function of the IANA functions contract for private enterprise numbers (OIDs).
This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds.
I remember arguments like that about why Token Ring was going to win over Ethernet 
Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad.
Indeed. I have stories...
Regards,
-drc
(who no longer works for ICANN)
whois. what did I win? IANA can handle very basic assignments, but
hasn't the staff for large support or extra services (whois, POC
management/validity, routing registry).
routing registry not necessarily needed from address registry.
and i am sure even the icann/iana could do the combined rir work for
half the combined rir budgets, especially with the insane budgets of
the more inflated rirs.
randy
Doug Barton wrote:
having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.)
whois. what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2.
You misunderstood. The correct answer to ULA was "Don't do it (or, more correctly, do IPv6 PI instead)."
And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins.
This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad.
Now that sounds like something it would have been easy for IANA to do. See, you have tension on this topic even in your own line of reasoning.
Doug
David already answered more eloquently than I could, so I'll simply add that what he said applied when I was there as well. The IANA is, and always has been a cost center. You don't want to live in an IANA fee-for-service world.
Doug
"No matter what the odds"? A good business person weighs the odds
carefully and takes calculated risks.
The chance of a conflict if you choose a random ULA prefix is lower than
just about any other risk an enterprise would even bother considering.
There is much more chance of an employee going postal, of a massive
lightning strike, of a disastrous fire or flood, of a two-week power
outage, than there is of a ULA prefix conflict, and all those things
will cause far more real damage than a ULA prefix conflict.
The risk of a ULA prefix conflict is for *all practical purposes* zero.
It is a far lower risk than almost anything else you probably have
contingency plans for. Not only that, but *even if the event comes to
pass*, it is merely an inconvenience. Not only that but it is an
inconvenience that can be detected in plenty of time and planned for and
mitigated with relative ease.
There may be good arguments against ULA, but the risk of prefix conflict
is not one of them. Please let's stop behaving as if a ULA conflict is
some kind of accident waiting to happen.
If an expert stood up in court and said "the chances that this
fingerprint is the defendant's are a million to one", and the prosecutor
then said "Aha! So you admit it's *possible*!" we would rightly scorn
the prosecutor for being an innumerate nincompoop. Yet here we are
paying serious heed to the idea that a ULA prefix conflict is a real
business risk.
Sheesh, if we professionals can't get a grip on what these tiny, tiny
probabilities really *mean* then how is anyone else going to?
Regards, K.
http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^1000000+((2^40)-1000000)!)+
It wouldn't puke nice graph with 'n', it did try, but never finished.
So if there are million assigned ULA's there is 36.5% chance of collision, if
formula is right.
If operator fscks-up their residential DSL product, lets say the assign all the
/128 user could want, but from single shared /64 subnet, not routing dedicated
/48 to each customer. Users who need to route, will want solution and some
vendor will step in, providing router which will auto-assign ULA + NAT66, will
that vendor sell million copies of said CPE?
But I don't think it is interesting to discuss the random chance of collisions,
as human factor will guarantee collisions, many people will assign fd::/48 to
get short and memorable addresses in their network. (You've made your bed, now
lie in it.)
If your IT staff includes personnel who've done painful renumbering due to M&A,
there is good chance they'll allocate random, otherwise they'll likely opt for
short and memorable network, as they did with RFC1918.
Just because we get IPv6, doesn't mean people will get sudden burst of insight
in design and engineering.
> Doug Barton wrote:
>> having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.)
> whois.> what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry).
With the exception of a routing registry (which I wasn't aware was an address allocation requirement), these services are provided by ICANN as part of the IANA functions contract. Out of curiosity, why do you think providing whois, POC management/validity, and even a routing registry requires a large staff?
> I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2.
As you note, ICANN already provides something like this as part of the protocol parameter function of the IANA functions contract for private enterprise numbers (OIDs).
> This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds.
I remember arguments like that about why Token Ring was going to win over Ethernet
+1 +1 +1
(Was quite happy when I was able to have an 10Mpbs ethernet pulled from
the floor below when my gov dept. was merged with another gov dept. and
I was moved to their IT section - and they were using 4Mbps token ring)
Of course being in business is a gamble in itself. They gamble on
future profits occurring when they spend on product or service
development, government regulation staying stable, cost bases that
aren't going to dramatically change, and possibly currency values
staying fairly stable (GFC type events being the ones that out bad
gamblers). I doubt businesses will be all that uncomfortable with IPv6
ULA collision odds that are worse than winning the lottery.
The same way that companies are making money selling people credit
reports they are legally able to get for free.
Sorry, but you asked. 
> The risk of a ULA prefix conflict is for *all practical purposes* zero.
http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^1000000+((2^40)-1000000)!)+
It wouldn't puke nice graph with 'n', it did try, but never finished.
So if there are million assigned ULA's there is 36.5% chance of collision, if
formula is right.
That's duplication, not collision. Collision only occurs when two ULA
domains want to interconnect, and have duplicate routes they would like
to exchange.
Here is what the RFC says about odds -
3.2.3. Analysis of the Uniqueness of Global IDs
The selection of a pseudo random Global ID is similar to the
selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
[RTP]. This analysis is adapted from that document.
Since Global IDs are chosen randomly (and independently), it is
possible that separate networks have chosen the same Global ID. For
any given network, with one or more random Global IDs, that has
inter-connections to other such networks, having a total of N such
IDs, the probability that two or more of these IDs will collide can
be approximated using the formula:
P = 1 - exp(-N**2 / 2**(L+1))
where P is the probability of collision, N is the number of
interconnected Global IDs, and L is the length of the Global ID.
The following table shows the probability of a collision for a range
of connections using a 40-bit Global ID field.
Connections Probability of Collision
2 1.81*10^-12
10 4.54*10^-11
100 4.54*10^-09
1000 4.54*10^-07
10000 4.54*10^-05
Based on this analysis, the uniqueness of locally generated Global
IDs is adequate for sites planning a small to moderate amount of
inter-site communication using locally generated Global IDs.
If operator fscks-up their residential DSL product, lets say the assign all the
/128 user could want, but from single shared /64 subnet, not routing dedicated
/48 to each customer. Users who need to route, will want solution and some
vendor will step in, providing router which will auto-assign ULA + NAT66, will
that vendor sell million copies of said CPE?But I don't think it is interesting to discuss the random chance of collisions,
as human factor will guarantee collisions, many people will assign fd::/48 to
get short and memorable addresses in their network. (You've made your bed, now
lie in it.)
That bed was called "site locals", and the prefix was fec0::/10. If two
separate organisations choose to make ULAs effectively site locals, and
then join their ULA domains, then they deserve the pain they'll get
because they haven't followed the RFC4193 formula.
At the end of the day you can't stop people doing stupid things unless
you take away the variables that they can set. If people are arguing
that ULA specs won't be followed correctly, then any other IPv6 spec
variable may also not be set correctly by the same person. Ultimately
that means that incompetent networking people are running the network.
I don't think you can use that as a valid reason to dismiss ULAs, and
then not use it to dismiss the whole of IPv6 *and* IPv4.
Bzzt! Wrong, but thank you for playing.
If there exists some screwed-up network design that *interconnects* 1M networks
that are all *advertising* ULAs there's a 36% chance of collision. It's a
subtle but important difference. You only care about a collision if (a) you
and some site in Zimbabwe both chose the same ULA prefix *AND* (b) you wish to
set up a private interconnect with them and talk with them *using the ULA
prefix*. Very important 'and' there.
On the other hand, today if you interconnect *3* private networks that use NAT
you have like a 90% chance of collision. And yet, people manage to do this all
the time. So ULAs give a way to make it literally a million times easier - and
THOSE SAME PEOPLE WHO DO THIS WITH NAT ADDRESSES ALL THE TIME ARE WHINING ULA
IS UNWORKABLE.
Geez guys, give me a break.
similarly:
> http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^1000000+((2^40)-1000000)!)+
>
> So if there are million assigned ULA's there is 36.5% chance of collision, if
> formula is right.Bzzt! Wrong, but thank you for playing.
Point I was trying to convey is that you should not assume ULA to be
globally unique. Visibility of IP can extend past routing, for example
someone could use x-forwarded-for and assume rfc4193 to be as unique as any
other IPv6 address.
I personally have no beef with ULA and I don't mind that it can't be
trusted to be globally unique identifier. It'll still allow well planned
enterprise networks to avoid renumbering in M&A.