Re: Addressing plan exercise for our IPv6 course
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
On Sat, 2010-07-24 at 18:49 +0100, Brandon Butterworth wrote:
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.
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 (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
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
On Sat, 2010-07-24 at 14:07 -0500, Jack Bates wrote:
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.
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On Sat, 24 Jul 2010 18:49:55 BST, Brandon Butterworth said:
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.
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.
On Sat, 24 Jul 2010, Brandon Butterworth wrote:
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.) 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 -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
On Jul 24, 2010, at 10:35 PM, Doug Barton wrote:
On Sat, 24 Jul 2010, Brandon Butterworth wrote:
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
On Jul 25, 2010, at 8:10 AM, Owen DeLong wrote:
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?
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
On Jul 24, 2010, at 11:40 PM, David Conrad wrote:
On Jul 25, 2010, at 8:10 AM, Owen DeLong wrote:
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?
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
The point was more that if the RIRs go away, IANA loses significant funding. Owen
On Sat, 24 Jul 2010, Owen DeLong wrote:
On Jul 24, 2010, at 10:35 PM, Doug Barton wrote:
On Sat, 24 Jul 2010, Brandon Butterworth wrote:
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?
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 -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it?
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.
My point was that as a cost center, IANA depends on funding from other sources. The RIRs are a major source of that funding. Owen
On Jul 25, 2010, at 6:02 PM, Owen DeLong wrote:
My point was that as a cost center, IANA depends on funding from other sources. The RIRs are a major source of that funding.
I guess it depends on your definition of "major". From section 5.1 of ICANN's draft FY11 budget (http://www.icann.org/en/financials/proposed-opplan-budget-v1-fy11-17may10-en... if you care): Registry $32,647,000 Registrar $29,159,000 RIR $823,000 ccTLD $1,600,000 IDN ccTLD $780,000 Meeting Sponsorships $500,000 Total $65,509,000 So the RIRs contribute 1.25% of ICANN's budget. Regards, -drc
On Jul 25, 2010, at 11:54 AM, David Conrad wrote:
On Jul 25, 2010, at 6:02 PM, Owen DeLong wrote:
My point was that as a cost center, IANA depends on funding from other sources. The RIRs are a major source of that funding.
I guess it depends on your definition of "major". From section 5.1 of ICANN's draft FY11 budget (http://www.icann.org/en/financials/proposed-opplan-budget-v1-fy11-17may10-en... if you care):
Registry $32,647,000 Registrar $29,159,000 RIR $823,000 ccTLD $1,600,000 IDN ccTLD $780,000 Meeting Sponsorships $500,000 Total $65,509,000
So the RIRs contribute 1.25% of ICANN's budget.
Regards, -drc
Correct, now, what portion of ICANN's budget is related to the NRO sector? My bet is that it's less than 1.25%. I suppose you can make domain owners pay for address administration if you want to make address administration free, but, that seems a bit backwards to me. Owen
Owen,
Correct, now, what portion of ICANN's budget is related to the NRO sector?
Read the ICANN budget. ICANN does not budget things that way. You asked "explain how the numbers side of IANA pays for anything when the RIRs stop funding it?" Doug and I, who have a bit of knowledge on the subject, have told you IANA does not "pay for anything". ICANN is a signatory to a contract with the US Department of Commerce that requires ICANN to provide the IANA functions, of which numbers allocation is one. Failure to perform any of the functions would be interpreted by DoC as a breach of contract. If the NRO did not contribute the (currently) 1.5% (which they have withheld in the past), ICANN would still be required to perform the number allocation function (as they did even when the RIR contribution was withheld). There is _no_ linkage between the contributions made by any stakeholder and the operation of the IANA functions contract. In the case of coordinating ULA assignments, I have no doubt IANA staff at ICANN _could_ provide the function quite easily since most of the infrastructure and processes are already in place for other services ICANN provides as part of the IANA functions contract. The question of whether or not the community, including folks from the RIR community and the IETF, want ICANN to perform that service is entirely different, and highly non-technical. 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.
On Jul 25, 2010, at 8:42 AM, Jack Bates wrote:
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)
On Sun, 25 Jul 2010 09:01:33 +0200 David Conrad <drc@virtualized.org> wrote:
On Jul 25, 2010, at 8:42 AM, Jack Bates wrote:
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.
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
On Sun, 25 Jul 2010, Jack Bates wrote:
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 -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
On Sun, 2010-07-25 at 01:42 -0500, Jack Bates wrote:
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.
"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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On (2010-07-25 17:32 +1000), Karl Auer wrote:
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. 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. -- ++ytti
On Sun, 25 Jul 2010 11:40:19 +0300 Saku Ytti <saku@ytti.fi> wrote:
On (2010-07-25 17:32 +1000), Karl Auer wrote:
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.
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.
-- ++ytti
On Sun, 25 Jul 2010 11:40:19 +0300, Saku Ytti said:
On (2010-07-25 17:32 +1000), Karl Auer wrote:
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.
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.
On (2010-07-25 10:28 -0400), Valdis.Kletnieks@vt.edu and Mark Smith wrote 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. -- ++ytti
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.
Yes, but if this prosecutor does this a million times, he's bound to be right at least once. Yes, a good businessperson takes risks. They also do everything possible to mitigate those risks, such as background checks on employees, lightning rods and grounding systems and insurance on the electronics in the building, buy generators and fuel contracts or source an emergency workplace. Yes, a crazy employee may get through a background check, but if the question is the presence of an attempt and prevention, then what is the risk mitigation for ULA? Best Regards, Nathan Eisenberg
On Sun, 2010-07-25 at 16:19 +0000, Nathan Eisenberg wrote:
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.
Yes, but if this prosecutor does this a million times, he's bound to be right at least once.
Hm. Would you hire a prosecutor who was, on average, right once in a million times?
Yes, a good businessperson takes risks. They also do everything possible to mitigate those risks, such as background checks on employees, lightning rods and grounding systems and insurance on the electronics in the building, buy generators and fuel contracts or source an emergency workplace. Yes, a crazy employee may get through a background check, but if the question is the presence of an attempt and prevention, then what is the risk mitigation for ULA?
Choose a random ULA prefix. Done. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On Sat, 24 Jul 2010 22:35:07 PDT, Doug Barton said:
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.)
The same way that companies are making money selling people credit reports they are legally able to get for free. Sorry, but you asked. ;)
participants (11)
-
Brandon Butterworth -
David Conrad -
Doug Barton -
Jack Bates -
Karl Auer -
Mark Smith -
Nathan Eisenberg -
Owen DeLong -
Randy Bush -
Saku Ytti -
Valdis.Kletnieks＠vt.edu