nanog mailing list archives
Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
From: Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>
Date: Thu, 22 Apr 2010 07:30:51 +0930
On Wed, 21 Apr 2010 09:11:38 -0700 David Conrad <drc () virtualized org> wrote:
On Apr 21, 2010, at 7:56 AM, Christopher Morrow wrote:yes... for those less willing to search: "Unique Addresses are Good" ... This does seem to be pretty much exactly my point (their point I suppose)Yup. Back in the day, the folks who ran the RIRs (at the time) were a bit distressed at that IAB statement as we had seen the writing on the wall and were telling customers that due to the limited nature of IPv4, if you didn't want to connect to the Internet, you should use private addressing. It was a bit of a "War of RFCs" (1597, 1627, 1814, 1918). My impression, which may be wrong, is that the primary driver for ULA-C is to avoid the administrative/cost overhead with entering into a relationship with the RIRs, particularly if there is no interest in connecting (directly) to the Internet. I guess I don't really see the harm...
That's not what I recollect when the site-local/ULA discussions were going on in 2002. Specifically, ULA-Cs were to address the concern of some people that the statistical possibility of collisions was too high, and therefore they wanted to be assured of global ULA uniqueness via central registry. The chance of collision is quite low - from RFC4193, section 3.2.3, " 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." with 'connections' meaning backdoor links. Traditional, non-ULA-Cs would do the job your talking about fine. Regards, Mark.
Current thread:
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01], (continued)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Daniel Senie (Apr 20)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Mark Smith (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Randy Bush (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Christopher Morrow (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Daniel Senie (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Christopher Morrow (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] David Conrad (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Christopher Morrow (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] David Conrad (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] bmanning (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Mark Smith (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Valdis . Kletnieks (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Christopher Morrow (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Daniel Senie (Apr 20)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Owen DeLong (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Mark Smith (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] bmanning (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Christopher Morrow (Apr 21)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] David Conrad (Apr 22)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Bill Bogstad (Apr 22)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] Christopher Morrow (Apr 22)
- Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01] bmanning (Apr 22)