IPv6 fc00::/7 — Unique local addresses

Mailman List Mirror (Read Only)
1

<IPv6 newbie>

According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an fc00::/7 address includes a 40-bit pseudo random number:

"fc00::/7 — Unique local addresses (ULA's) are intended for local communication. They are routable only within a set of cooperating sites (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing prefix intended to minimize the risk of conflicts if sites merge or packets are misrouted into the Internet. Despite the restricted, local usage of these addresses, their address scope is global, i.e. they are expected to be globally unique."

I am trying to set up a local IPv6 network and am curious why all the examples I come accross do not seem to use the 40-bit pseudorandom number? What should I do? Use something like fd00::1234, or incorporate something like the interface's MAC address into the address? It'd make the address quite unreadable though.

Thanks,
Jeroen

2

Use the cool tool at http://www.sixxs.net/tools/grh/ula/ to generate a ULA, then use it for local-scope stuff. Slick.

3

<IPv6 newbie>

According to IPv6 address - Wikipedia
an fc00::/7 address includes a 40-bit pseudo random number:

"fc00::/7 — Unique local addresses (ULA's) are intended for local
communication. They are routable only within a set of cooperating sites
(analogous to the private address ranges 10/8, 172.16/12, and 192.168/16
of IPv4).[12] The addresses include a 40-bit pseudorandom number in the
routing prefix intended to minimize the risk of conflicts if sites merge
or packets are misrouted into the Internet. Despite the restricted,
local usage of these addresses, their address scope is global, i.e. they
are expected to be globally unique."

I am trying to set up a local IPv6 network and am curious why all the
examples I come accross do not seem to use the 40-bit pseudorandom
number? What should I do?

Use a pseudo random number, not follow bad examples. Where are these
examples? I'd be curious as to what they say regarding why they haven't
followed the pseudo random number requirement.

Use something like fd00::1234, or incorporate
something like the interface's MAC address into the address? It'd make
the address quite unreadable though.

DNS (including dynamic DNS, multicast DNS, and DNS service discovery) is
intended to be used far more often in IPv6 than it was in IPv4. It was
never going to be that possible to expand the size of the address space
significantly without trading off 'rememberability'.

The best way to understand ULAs is to read the RFC. It'd probably take
about 15 to 20 minutes, and is quite readable (as are most if not all
RFCs)

Unique Local IPv6 Unicast Addresses
http://tools.ietf.org/rfc/rfc4193.txt

You may also wish to subscribe to the ipv6-ops mailing list for IPv6
focused operations discussions.

http://lists.cluenet.de/mailman/listinfo/ipv6-ops

Regards,
Mark.

4

Use a pseudo random number, not follow bad examples. Where are these
examples? I'd be curious as to what they say regarding why they haven't
followed the pseudo random number requirement.

> Use something like fd00::1234, or incorporate
> something like the interface's MAC address into the address? It'd
make
> the address quite unreadable though.
>
Unique Local IPv6 Unicast Addresses
http://tools.ietf.org/rfc/rfc4193.txt

[snipped a bunch of stuff above].

According to the RFC:

3.2

   The local assignments are self-generated and do not need any central
   coordination or assignment, but have an extremely high probability of
   being unique.

3.2.1. Locally Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM]. Section 3.2.2 describes a
   suggested algorithm. It is important that all sites generating
   Global IDs use a functionally similar algorithm to ensure there is a
   high probability of uniqueness.

   The use of a pseudo-random algorithm to generate Global IDs in the
   locally assigned prefix gives an assurance that any network numbered
   using such a prefix is highly unlikely to have that address space
   clash with any other network that has another locally assigned prefix
   allocated to it. This is a particularly useful property when
   considering a number of scenarios including networks that merge,
   overlapping VPN address space, or hosts mobile between such networks.

5

> <IPv6 newbie>
>=20
> According to IPv6 address - Wikipedia
=20
> an fc00::/7 address includes a 40-bit pseudo random number:
>=20
> "fc00::/7 =E2=80=94 Unique local addresses (ULA's) are intended for local=
=20
> communication. They are routable only within a set of cooperating sites=20
> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16=
=20
> of IPv4).[12] The addresses include a 40-bit pseudorandom number in the=20
> routing prefix intended to minimize the risk of conflicts if sites merge=
=20
> or packets are misrouted into the Internet. Despite the restricted,=20
> local usage of these addresses, their address scope is global, i.e. they=
=20
> are expected to be globally unique."
>=20
> I am trying to set up a local IPv6 network and am curious why all the=20
> examples I come accross do not seem to use the 40-bit pseudorandom=20
> number? What should I do?

Use a pseudo random number, not follow bad examples. Where are these
examples? I'd be curious as to what they say regarding why they haven't
followed the pseudo random number requirement.

Here is a real life example of the use of ULA's. I used the following
command to get the 40 random bits in the prefix (92:7065:b8e).

dd if=/dev/random bs=5 count=1 | od -t x1

The border router is configured to block ULA traffic, gif0 is the
external interface on the border router.

// ULA border filter
add unreach admin all from any to fc00::/7 via gif0
add unreach admin all from fc00::/7 to any via gif0

If your OS supports it. You configure the address selection rules
to prefer your ULA prefix when talking to your ULA prefix and then
to prefer non ULA to non ULA over general ULA to general ULA. That
way you use ULA addresses for internal communication and non ULA
addresses for external communication.

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  ether e8:06:88:f3:4f:9c
  inet6 fe80::ea06:88ff:fef3:4f9c%en0 prefixlen 64 scopeid 0x4
  inet6 fd92:7065:b8e::ea06:88ff:fef3:4f9c prefixlen 64 autoconf
  inet6 2001:470:1f00:820:ea06:88ff:fef3:4f9c prefixlen 64 autoconf
  inet 192.168.191.240 netmask 0xffffff00 broadcast 192.168.191.255
  media: autoselect (10baseT/UTP <half-duplex>)
  status: active

6

The ULA /48s are hoped to only be globally unique, but this only has
a good chance of happening
if all users pick good random numbers as required, which will
often be 'hard to read'.
should any two networks pick non-random numbers, they could easily
conflict, breaking expectations.

My suspicion is that in the future it is going to happen routinely,
esp. if ULA becomes to IPv6 what
RFC1918 space is to IPv4, with most end user networks implementing
NAT66 to translate "private"
/48 ULAs to their site's "public" /48 assignment from their ISP.

I can imagine generic $50 IPv6 broadband routers getting
distributed en-masse that hardcode all bits 0
ULA NAT66 by default, and expect the user to change the LAN IP subnet
/ NAT config from the defaults,
sometime while they're setting it up, probably at the same time they
change the admin password.

You know... the type of router a residential user plugs in, and they
"just work",
and if the user forgets to follow any setup or config directions,
just pulls an IP via DHCP and
sticks with some insecure defaults.

But it would still be a big improvement from what is available with V4.

7

Hi Jeroen,

According to IPv6 address - Wikipedia an
fc00::/7 address includes a 40-bit pseudo random number:

"fc00::/7 — Unique local addresses (ULA's) are intended for local
communication. They are routable only within a set of cooperating sites
(analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of
IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing
prefix intended to minimize the risk of conflicts if sites merge or packets
are misrouted into the Internet. Despite the restricted, local usage of
these addresses, their address scope is global, i.e. they are expected to be
globally unique."

I am trying to set up a local IPv6 network and am curious why all the
examples I come accross do not seem to use the 40-bit pseudorandom number?
What should I do? Use something like fd00::1234, or incorporate something
like the interface's MAC address into the address? It'd make the address
quite unreadable though.

RFC4193 specifies a suggested algorithm to do it:

The section 3.2.1 also states that
"Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM]. Section 3.2.2 describes a
   suggested algorithm. It is important that all sites generating
   Global IDs use a functionally similar algorithm to ensure there is a
   high probability of uniqueness."

I'm not sure where did you find the examples you've mentioned. If it's
just a documentation example - seems to be fine. If someone is doing
it in real networks - that's just not right..

8

Deepak Jain wrote:

According to the RFC:

3.2.1. Locally Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM]. Section 3.2.2 describes a

Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick.

All thanks for the information. I'll be using the "40 bit pseudo random thing" since it seems to be the smart thing to do, using the SIXXS tool. One may hope that something will become the "official" way to generate these numbers (perhaps the above mentioned tool).

Someone advised me to use GUA instead of ULA. But since for my purposes this is used for an IPv6 LAN would ULA not be the better choice?

Thanks,
Jeroen

9

> Use a pseudo random number, not follow bad examples. Where are these
> examples? I'd be curious as to what they say regarding why they haven't
> followed the pseudo random number requirement.
>
> > Use something like fd00::1234, or incorporate
> > something like the interface's MAC address into the address? It'd
> make
> > the address quite unreadable though.
> >
> Unique Local IPv6 Unicast Addresses
> http://tools.ietf.org/rfc/rfc4193.txt
>

[snipped a bunch of stuff above].

According to the RFC:

3.2

   The local assignments are self-generated and do not need any central
   coordination or assignment, but have an extremely high probability of
   being unique.

3.2.1. Locally Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM]. Section 3.2.2 describes a
   suggested algorithm. It is important that all sites generating
   Global IDs use a functionally similar algorithm to ensure there is a
   high probability of uniqueness.

   The use of a pseudo-random algorithm to generate Global IDs in the
   locally assigned prefix gives an assurance that any network numbered
   using such a prefix is highly unlikely to have that address space
   clash with any other network that has another locally assigned prefix
   allocated to it. This is a particularly useful property when
   considering a number of scenarios including networks that merge,
   overlapping VPN address space, or hosts mobile between such networks.

----

Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique.

The chance of collision is dependent on both the randomness of 40 bits
*and* how interconnected the ULA domains are. You'll have to sin a lot to be that unlucky.

Here's the table from the RFC showing the odds of collision based on interconnectedness -

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.

Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick.

One thing I'm not keen on that sixxs have done is to create a voluntary
registry of the non-central ULAs. By creating a registry, I think some
people who use it will then think that their ULA prefix is now
guaranteed globally unique and is theirs forever. If there ever was a
collision, those people are likely to point to that completely
voluntary registry and say "I had it first" and are likely to refuse
to accept that the voluntary registry has no status or authority over
the random ULA address space.

There also doesn't seem to be any limiting of the number of prefixes.
In an isolated network, which is where ULAs are supposed to be used,
it's far less of a problem, because the only time the chance of
collision occurs is if you interconnect with somebody else's ULA
domain. However, as this sixxs registry implies it is a global one, and
therefore there is a single instance of the fd::/8 address space,
limiting the number of prefixes that are assigned would seem to me to
be good idea. When I see examples such as -

fddd:7927:58e::/48 Steven Sorel Deticon Networks http://deticon.net
fd85:5d1d:c00b::/48 Steven Sorel Deticon Networks http://deticon.net
fda1:9347:699f::/48 Steven Sorel Deticon Networks http://deticon.net
fd41:eda2:4b7b::/48 Steven Sorel Deticon Networks http://deticon.net
fd58:fe0f:8706::/48 Steven Sorel Deticon Networks http://deticon.net
fd6a:3128:2a1d::/48 Steven Sorel Deticon Networks http://deticon.net
fdb0:8025:2463::/48 Steven Sorel Deticon Networks http://deticon.net

or 458 752 subnets, and http://deticon.net isn't reachable via IPv6 or
IPv4 (and hasn't been for quite a while - I checked a few months ago
when I discovered the registry), it seems to me that people have
already misunderstood what it's purpose is, and that the database is
already polluted with invalid entries that can't be verified for
existence, and which also can't be expired via some invalidation
mechanism, such as lack of payment of annual fees.

Regards,
Mark.

10

> <IPv6 newbie>

> these addresses, their address scope is global, i.e. they are expected to b
e
> globally unique."

The ULA /48s are hoped to only be globally unique, but this only has
a good chance of happening
if all users pick good random numbers as required, which will
often be 'hard to read'.
should any two networks pick non-random numbers, they could easily
conflict, breaking expectations.

My suspicion is that in the future it is going to happen routinely,
esp. if ULA becomes to IPv6 what
RFC1918 space is to IPv4, with most end user networks implementing
NAT66 to translate "private"
/48 ULAs to their site's "public" /48 assignment from their ISP.

Way to much "IPv4 think" here. Just use multiple prefixes. It
just works. You talk to the external world using the prefix your
ISP provides and you talk to your internal machines using the ULA
prefix you choose. No need for NAT66.

You move to a new ISP the machines just add a AAAA record to the
DNS for themselves and remove the old AAAA record.

I can imagine generic $50 IPv6 broadband routers getting
distributed en-masse that hardcode all bits 0
ULA NAT66 by default, and expect the user to change the LAN IP subnet
/ NAT config from the defaults,
sometime while they're setting it up, probably at the same time they
change the admin password.

Or just have the CPE generate a ULA prefix correctly and write it
to NVRAM so you don't need to re-generate it. The internal prefix
/ addresses *WILL* leak. We know this from our experiences with
RFC 1918 addresses. Any CPE vendor that fails to generate random
ULA prefixes should be shot.

11

Deepak Jain wrote:

According to the RFC:

3.2.1. Locally Assigned Global IDs
  Locally assigned Global IDs MUST be generated with a pseudo-random
  algorithm consistent with [RANDOM]. Section 3.2.2 describes a

Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick.

All thanks for the information. I'll be using the "40 bit pseudo random thing" since it seems to be the smart thing to do, using the SIXXS tool. One may hope that something will become the "official" way to generate these numbers (perhaps the above mentioned tool).

I believe the above mentioned tool uses the OFFICIAL way documented in the RFC.

There is an official way to do it. It is documented in the RFC.

Someone advised me to use GUA instead of ULA. But since for my purposes this is used for an IPv6 LAN would ULA not be the better choice?

IMHO, no. There's no disadvantage to using GUA and I personally don't think ULA really serves a purpose. If you want to later connect this
LAN to the internet or something that connects to something that connects to something that connects to the internet or whatever, GUA provides
the following advantages:
  + Guaranteed uniqueness (not just statistically probable uniqueness)
  + You can route it if you later desire to

Since ULA offers no real advantages, I don't really see the point.

Owen

12

Which is part one of the three things that have to happen to make ULA
really bad for the internet.

Part 2 will be when the first provider accepts a large sum of money to
route it within their public network between multiple sites owned by
the same customer.

Part 3 will be when that same provider (or some other provider in the
same boat) takes the next step and starts trading routes of ULA space
with other provider(s).

At that point, ULA = GUA without policy = very bad thing (tm).

Since feature creep of this form is kind of a given in internet history,
I have no reason to believe it won't happen eventually with ULA.

Owen

13

Or just have the CPE generate a ULA prefix correctly and write it
to NVRAM so you don't need to re-generate it. The internal prefix
/ addresses *WILL* leak. We know this from our experiences with
RFC 1918 addresses. Any CPE vendor that fails to generate random
ULA prefixes should be shot.

Any CPE vendor that refuses to implement any special provisions
whatsoever for ULA and leave that entirely to the user with strong
discouragement should be applauded.

Owen

14

> <IPv6 newbie>

> these addresses, their address scope is global, i.e. they are expected to be
> globally unique."

The ULA /48s are hoped to only be globally unique, but this only has
a good chance of happening
if all users pick good random numbers as required, which will
often be 'hard to read'.
should any two networks pick non-random numbers, they could easily
conflict, breaking expectations.

Do you realise that one of the reasons why the ID is random is to
discourage global routing of them, so they don't aggregate well?
They're for internal addressing. The only time some of your local ULA
address space would be seen externally to your network is via a backdoor
connection to e.g. a business partner via a VPN. ULAs should never and
are prohibited from appearing in the global route table. The probably
shouldn't also appear in a multilateral peering fabric.

To make it clear, as it seems to be quite misunderstood, you'd have
both ULA and global addressing in your network. For internal
destinations ULA addresses are used. For global destinations, global
addresses are used. ULAs serve the purpose of providing an internally
stable address space independent of your upstream transit
provider's global address space, assuming you have one. In IPv4, RFC1918
served this purpose, although not as well, as it couldn't be used
concurrently with a global address space (one of the differences
between IPv4 and IPv6 is proper, by-design, support for nodes having
multiple valid addresses), and also required NAT when interconnecting
two overlapping RFC1918 address domains.

15

Hi Owen,

>
>>> Use a pseudo random number, not follow bad examples. Where are these
>>> examples? I'd be curious as to what they say regarding why they haven't
>>> followed the pseudo random number requirement.
>>>
>>>> Use something like fd00::1234, or incorporate
>>>> something like the interface's MAC address into the address? It'd
>>> make
>>>> the address quite unreadable though.
>>>>
>>> Unique Local IPv6 Unicast Addresses
>>> http://tools.ietf.org/rfc/rfc4193.txt
>>>
>>
>> [snipped a bunch of stuff above].
>>
>> According to the RFC:
>>
>> 3.2
>>
>> The local assignments are self-generated and do not need any central
>> coordination or assignment, but have an extremely high probability of
>> being unique.
>>
>> 3.2.1. Locally Assigned Global IDs
>>
>> Locally assigned Global IDs MUST be generated with a pseudo-random
>> algorithm consistent with [RANDOM]. Section 3.2.2 describes a
>> suggested algorithm. It is important that all sites generating
>> Global IDs use a functionally similar algorithm to ensure there is a
>> high probability of uniqueness.
>>
>> The use of a pseudo-random algorithm to generate Global IDs in the
>> locally assigned prefix gives an assurance that any network numbered
>> using such a prefix is highly unlikely to have that address space
>> clash with any other network that has another locally assigned prefix
>> allocated to it. This is a particularly useful property when
>> considering a number of scenarios including networks that merge,
>> overlapping VPN address space, or hosts mobile between such networks.
>>
>> ----
>>
>> Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique.
>
> The chance of collision is dependent on both the randomness of 40 bits
> *and* how interconnected the ULA domains are. You'll have to sin a lot to be that unlucky.
>
> Here's the table from the RFC showing the odds of collision based on interconnectedness -
>
> 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.
>
>
>> Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick.
>>
>
> One thing I'm not keen on that sixxs have done is to create a voluntary
> registry of the non-central ULAs. By creating a registry, I think some
> people who use it will then think that their ULA prefix is now
> guaranteed globally unique and is theirs forever. If there ever was a
> collision, those people are likely to point to that completely
> voluntary registry and say "I had it first" and are likely to refuse
> to accept that the voluntary registry has no status or authority over
> the random ULA address space.
>
Which is part one of the three things that have to happen to make ULA
really bad for the internet.

Part 2 will be when the first provider accepts a large sum of money to
route it within their public network between multiple sites owned by
the same customer.

That same customer is also going to have enough global address
space to be able to reach other global destinations, at least enough
space for all nodes that are permitted to access the Internet, if not
more. Proper global address space ensures that if a global destination
is reachable, then there is a high probability of successfully reaching
it. The scope of external ULA reachability, regardless of how much
money is thrown at the problem, isn't going to be as good as proper
global addresses.

For private site interconnect, I'd think it more likely that the
provider would isolate the customers traffic and ULA address space via
something like a VPN service e.g. MPLS, IPsec.

Part 3 will be when that same provider (or some other provider in the
same boat) takes the next step and starts trading routes of ULA space
with other provider(s).

At that point, ULA = GUA without policy = very bad thing (tm).

Since feature creep of this form is kind of a given in internet history,
I have no reason to believe it won't happen eventually with ULA.

So I'm not sure I can see much benefit would be of paying a
huge amount of money to have ULA address space put in only a
limited part/domain of the global route table. The only way to
have ULA = GUA is to pay everybody on the Internet to carry it, and
that is assuming that everybody would be willing to accept the money
in the first place. That'd be far more expensive than just using GUA
addresses for global reachability.

Regards,
Mark.

16

Jeroen,

I see it like this:

You can pick anything in fd00::/8 that you want, but if you don't
follow the random selection rules in the RFC then it's *your fault*
when you go to connect a VPN to someone else who picked the same
network.

Also, the DNS is your friend, even more so with IPv6 than with IPv4.

Regards,
Bill Herrin

17

Right. Just like to multihome with IPv6 you would have both PA addresses from provider #1 and PA addresses from provider #2 in your network.

Only nobody wants to do that either.

Matthew Kaufman

18

In message <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com>, Owen DeLong write
s:

>=20
>>> Use a pseudo random number, not follow bad examples. Where are these
>>> examples? I'd be curious as to what they say regarding why they =
haven't
>>> followed the pseudo random number requirement.
>>>=20
>>>> Use something like fd00::1234, or incorporate
>>>> something like the interface's MAC address into the address? It'd
>>> make
>>>> the address quite unreadable though.
>>>>=20
>>> Unique Local IPv6 Unicast Addresses
>>> http://tools.ietf.org/rfc/rfc4193.txt
>>>=20
>>=20
>> [snipped a bunch of stuff above].=20
>>=20
>> According to the RFC:=20
>>=20
>> 3.2
>>=20
>> The local assignments are self-generated and do not need any =
central
>> coordination or assignment, but have an extremely high probability =
of
>> being unique.
>>=20
>> 3.2.1. Locally Assigned Global IDs
>>=20
>> Locally assigned Global IDs MUST be generated with a pseudo-random
>> algorithm consistent with [RANDOM]. Section 3.2.2 describes a
>> suggested algorithm. It is important that all sites generating
>> Global IDs use a functionally similar algorithm to ensure there is =
a
>> high probability of uniqueness.
>>=20
>> The use of a pseudo-random algorithm to generate Global IDs in the
>> locally assigned prefix gives an assurance that any network =
numbered
>> using such a prefix is highly unlikely to have that address space
>> clash with any other network that has another locally assigned =
prefix
>> allocated to it. This is a particularly useful property when
>> considering a number of scenarios including networks that merge,
>> overlapping VPN address space, or hosts mobile between such =
networks.
>>=20
>> ----
>>=20
>> Global ID in this case means the 40 bit pseudo random thing. The =
point here is, we are all supposed to pick our own poison and pray that =
we are unique.
>=20
> The chance of collision is dependent on both the randomness of 40 bits
> *and* how interconnected the ULA domains are. You'll have to sin a lot =
to be that unlucky.
>=20
> Here's the table from the RFC showing the odds of collision based on =
interconnectedness -
>=20
> The following table shows the probability of a collision for a range
> of connections using a 40-bit Global ID field.
>=20
> Connections Probability of Collision
>=20
> 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
>=20
> 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.
>=20
>=20
>> Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. =
Anyway, the SIXXS tool seems pretty slick.
>>=20
>=20
> One thing I'm not keen on that sixxs have done is to create a =
voluntary
> registry of the non-central ULAs. By creating a registry, I think some
> people who use it will then think that their ULA prefix is now
> guaranteed globally unique and is theirs forever. If there ever was a
> collision, those people are likely to point to that completely
> voluntary registry and say "I had it first" and are likely to refuse
> to accept that the voluntary registry has no status or authority over
> the random ULA address space.
>=20
Which is part one of the three things that have to happen to make ULA
really bad for the internet.

Part 2 will be when the first provider accepts a large sum of money to
route it within their public network between multiple sites owned by
the same customer.

They can do that without needing to pay. They just setup tunnels
between the sites.

Alternatively the ISP provides virtual circuits between the sites
for a small on going fee to cover the additional administrative
costs and bills on the aggregate traffic across all the circuits
to each site. The ISP doesn't need to accept ULA routes to cross
connect the sites.

It's not like ISP's don't provide virtual circuits today to cross
connect parts of companies. Or companies don't run VPN tunnels
between sites today.

19

Part 2 will be when the first provider accepts a large sum of money to
route it within their public network between multiple sites owned by
the same customer.

Is this happening now with RFC 1918 addresses and IPv4?

Part 3 will be when that same provider (or some other provider in the
same boat) takes the next step and starts trading routes of ULA space
with other provider(s).

Is this happening now with RFC 1918 addresses and IPv4?

If not, do you predict that it will soon, and if so, why?

Matthew Kaufman

20

So you speak for everybody? I can do that too. Nobody wants to run NAT
anymore either.