Why do IPv6 unique local addresses have to have a /48 prefix?
According to RFC 4193, unique local addresses will always have a prefix of FD00::/8
.. but according to Wikipedia:
The block fd00::/8 is defined for /48 prefixes, formed by setting the forty least-significant bits of the prefix to a randomly generated bit string.
Is this enforced, and if so why? What stops me from having a prefix of /32
or /16
etc?
ip network ipv6 protocol-theory networking
New contributor
add a comment |
According to RFC 4193, unique local addresses will always have a prefix of FD00::/8
.. but according to Wikipedia:
The block fd00::/8 is defined for /48 prefixes, formed by setting the forty least-significant bits of the prefix to a randomly generated bit string.
Is this enforced, and if so why? What stops me from having a prefix of /32
or /16
etc?
ip network ipv6 protocol-theory networking
New contributor
2
Remember the the "U" in ULA stands for "unique."
– Ron Maupin♦
Mar 24 at 16:03
add a comment |
According to RFC 4193, unique local addresses will always have a prefix of FD00::/8
.. but according to Wikipedia:
The block fd00::/8 is defined for /48 prefixes, formed by setting the forty least-significant bits of the prefix to a randomly generated bit string.
Is this enforced, and if so why? What stops me from having a prefix of /32
or /16
etc?
ip network ipv6 protocol-theory networking
New contributor
According to RFC 4193, unique local addresses will always have a prefix of FD00::/8
.. but according to Wikipedia:
The block fd00::/8 is defined for /48 prefixes, formed by setting the forty least-significant bits of the prefix to a randomly generated bit string.
Is this enforced, and if so why? What stops me from having a prefix of /32
or /16
etc?
ip network ipv6 protocol-theory networking
ip network ipv6 protocol-theory networking
New contributor
New contributor
edited Mar 24 at 17:52
Ron Maupin♦
67.9k1369126
67.9k1369126
New contributor
asked Mar 24 at 7:03
Sam PSam P
1283
1283
New contributor
New contributor
2
Remember the the "U" in ULA stands for "unique."
– Ron Maupin♦
Mar 24 at 16:03
add a comment |
2
Remember the the "U" in ULA stands for "unique."
– Ron Maupin♦
Mar 24 at 16:03
2
2
Remember the the "U" in ULA stands for "unique."
– Ron Maupin♦
Mar 24 at 16:03
Remember the the "U" in ULA stands for "unique."
– Ron Maupin♦
Mar 24 at 16:03
add a comment |
2 Answers
2
active
oldest
votes
The requirement exists to prevent collisions. This is a bit more important than most people recognize.
Even if you have systems which currently don't communicate with other systems over the internet you still need your addresses to be globally unique. You may now or in the future need to add a host which can communicate both with your internal network and with the internet. And for communication with that host to work, the IP addresses with which it communicate will need to be unique.
If two internal networks exist with the same local range there is the possibility a host will eventually need to communicate with both and at that point you would have to renumber one of the networks. This kind of communication is likely to be needed if you are using a VPN connection and both client and server are on networks which make use of RFC 4193 address space.
Another way you could end up needing to communicate with other internal networks in the future is in case your company merges with another company which also uses internal networks.
40 random bits is enough to guarantee that a host which needs to communicate with multiple internal networks can expect to reach approximately one million different networks before seeing the first collision.
The 40 random bits requirement is not enforced in any way, but if you don't follow it you are setting yourself up for problems in the future when a collision happens.
1
I'd be careful with the words "guarantee" and "expect"; there is a chance you will find a collision after one attempt. Not a large chance, sure, but..!
– Lightness Races in Orbit
Mar 24 at 20:24
4
@LightnessRacesinOrbit The word expect is being used according to the mathematical definition of expected value.
– kasperd
Mar 24 at 20:28
1
Then you should add an explanation or disclaimer to that effect, IMO, since this is not MathOverflow :)
– Lightness Races in Orbit
Mar 24 at 20:31
1
@LightnessRacesinOrbit I actually do expect network engineers to know some probability theory. This would be taught in an introductory course. Besides the risk of seeing a collision much sooner is much smaller than so many of the other things people take for granted.
– kasperd
Mar 24 at 20:46
1
Even so, you can't "guarantee" an "expectation", and I think your math is wrong anyway. With 40 bits of entropy the birthday paradox means that you need of the order of 1M (2^20) networks for there to be a 50% chance of any collision existing for any arbitrary pair of networks amongst all possible pairs. The chance of a collision existing for your network is 2^40 (assuming that your own ULA prefix was truly randomly selected).
– Alnitak
Mar 24 at 21:16
|
show 8 more comments
When companies merge or set up an extranet to communicate, it has proven difficult with IPv4 Private addressing because the companies often use the same or overlapping address space, and that requires the ugly hack of NAT to get around, and that can cause problems and break many protocols.
This was identified as a problem when IPv6 ULA was being developed, and the goal was to allow companies to have non-Internet address space, but to have a very high probability that the space used was unique. This is to try to prevent the problem of merging or communication between companies using non-Internet addressing. IPv6 doesn't have NAT, and the goal of IPv6 is to restore the IP end-to-end connectivity that was lost when NAT became necessary due to the limited number of IPv4 addresses.
The first half of the IPv6 ULA space (fc00::/8
) is reserved for assignment by a (yet to be named) global authority, while the second half of the IPv6 ULA space (fd00::/8
) was set up so that companies could assign their own addressing with a high probability of uniqueness.
According to RFC 4193, unique local addresses will always have a
prefix ofFD00::/8
That is simply incorrect. That RFC defines the ULA space as fc00::/7
, but there are two parts to the space that are defined by the eighth bit ("L" bit).
From the RFC:
3.1. Format
The Local IPv6 addresses are created using a pseudo-randomly allocated
global ID. They have the following format:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
This divides the ULA space into two /8
spaces: fc00::/8
for globally assigned addressing, and fd00::/8
for locally assigned addressing. Notice the format in the RFC requires "a pseudo-randomly allocated global ID." This is further explained:
3.2. Global ID
The allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT
be assigned sequentially or with well-known numbers. This is to ensure
that there is not any relationship between allocations and to help
clarify that these prefixes are not intended to be routed globally.
Specifically, these prefixes are not designed to aggregate.
This document defines a specific local method to allocate Global IDs,
indicated by setting the L bit to 1. Another method, indicated by
clearing the L bit, may be defined later. Apart from the allocation
method, all Local IPv6 addresses behave and are treated identically.
The local assignments are self-generated and do not need any central
coordination or assignment, but have an extremely high probability of
being unique.
As you can see, the premise of your question that the RFC says that ULA addresses will always have a prefix of fd00::/8
is incorrect.
Is this enforced, and if so why? What stops me from having a prefix of
/32 or /16 etc?
There is no actual enforcement, the way there would be if you were trying to use the addressing on the public Internet. Your company could simply use any addressing in that space, in whatever blocks it wants. What your business does for addressing on its own network is completely up to it, but it could prove foolish and expensive in the long run to not follow the standards.
For example, I know of some companies that used "dark" IPv4 address space within their networks, but then the dark address space started to be used on the public Internet, and the companies were unable to connect with customers or vendors using addressing in that address space, and it took some ugly solutions to get around that in the short term, until all the internal networks using that address space were readdressed. It took a few years and a lot of money to fix the problems.
RFC 4193, Unique Local IPv6 Unicast Addresses is the definition of IPv6 ULA, and you should refer to it for the details:
1. Introduction
This document defines an IPv6 unicast address format that is globally
unique and is intended for local communications [IPV6]. These
addresses are called Unique Local IPv6 Unicast Addresses and are
abbreviated in this document as Local IPv6 addresses. They are not
expected to be routable on the global Internet. They are routable
inside of a more limited area such as a site. They may also be routed
between a limited set of sites.
Local IPv6 unicast addresses have the following characteristics:
Globally unique prefix (with high probability of uniqueness).
Well-known prefix to allow for easy filtering at site
boundaries.
Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of
interfaces that use these prefixes.
Internet Service Provider independent and can be used for
communications inside of a site without having any permanent or
intermittent Internet connectivity.
If accidentally leaked outside of a site via routing or DNS,
there is no conflict with any other addresses.
In practice, applications may treat these addresses like global
scoped addresses.
This document defines the format of Local IPv6 addresses, how to
allocate them, and usage considerations including routing, site border
routers, DNS, application support, VPN usage, and guidelines for how
to use for local communication inside a site.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "496"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sam P is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57921%2fwhy-do-ipv6-unique-local-addresses-have-to-have-a-48-prefix%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The requirement exists to prevent collisions. This is a bit more important than most people recognize.
Even if you have systems which currently don't communicate with other systems over the internet you still need your addresses to be globally unique. You may now or in the future need to add a host which can communicate both with your internal network and with the internet. And for communication with that host to work, the IP addresses with which it communicate will need to be unique.
If two internal networks exist with the same local range there is the possibility a host will eventually need to communicate with both and at that point you would have to renumber one of the networks. This kind of communication is likely to be needed if you are using a VPN connection and both client and server are on networks which make use of RFC 4193 address space.
Another way you could end up needing to communicate with other internal networks in the future is in case your company merges with another company which also uses internal networks.
40 random bits is enough to guarantee that a host which needs to communicate with multiple internal networks can expect to reach approximately one million different networks before seeing the first collision.
The 40 random bits requirement is not enforced in any way, but if you don't follow it you are setting yourself up for problems in the future when a collision happens.
1
I'd be careful with the words "guarantee" and "expect"; there is a chance you will find a collision after one attempt. Not a large chance, sure, but..!
– Lightness Races in Orbit
Mar 24 at 20:24
4
@LightnessRacesinOrbit The word expect is being used according to the mathematical definition of expected value.
– kasperd
Mar 24 at 20:28
1
Then you should add an explanation or disclaimer to that effect, IMO, since this is not MathOverflow :)
– Lightness Races in Orbit
Mar 24 at 20:31
1
@LightnessRacesinOrbit I actually do expect network engineers to know some probability theory. This would be taught in an introductory course. Besides the risk of seeing a collision much sooner is much smaller than so many of the other things people take for granted.
– kasperd
Mar 24 at 20:46
1
Even so, you can't "guarantee" an "expectation", and I think your math is wrong anyway. With 40 bits of entropy the birthday paradox means that you need of the order of 1M (2^20) networks for there to be a 50% chance of any collision existing for any arbitrary pair of networks amongst all possible pairs. The chance of a collision existing for your network is 2^40 (assuming that your own ULA prefix was truly randomly selected).
– Alnitak
Mar 24 at 21:16
|
show 8 more comments
The requirement exists to prevent collisions. This is a bit more important than most people recognize.
Even if you have systems which currently don't communicate with other systems over the internet you still need your addresses to be globally unique. You may now or in the future need to add a host which can communicate both with your internal network and with the internet. And for communication with that host to work, the IP addresses with which it communicate will need to be unique.
If two internal networks exist with the same local range there is the possibility a host will eventually need to communicate with both and at that point you would have to renumber one of the networks. This kind of communication is likely to be needed if you are using a VPN connection and both client and server are on networks which make use of RFC 4193 address space.
Another way you could end up needing to communicate with other internal networks in the future is in case your company merges with another company which also uses internal networks.
40 random bits is enough to guarantee that a host which needs to communicate with multiple internal networks can expect to reach approximately one million different networks before seeing the first collision.
The 40 random bits requirement is not enforced in any way, but if you don't follow it you are setting yourself up for problems in the future when a collision happens.
1
I'd be careful with the words "guarantee" and "expect"; there is a chance you will find a collision after one attempt. Not a large chance, sure, but..!
– Lightness Races in Orbit
Mar 24 at 20:24
4
@LightnessRacesinOrbit The word expect is being used according to the mathematical definition of expected value.
– kasperd
Mar 24 at 20:28
1
Then you should add an explanation or disclaimer to that effect, IMO, since this is not MathOverflow :)
– Lightness Races in Orbit
Mar 24 at 20:31
1
@LightnessRacesinOrbit I actually do expect network engineers to know some probability theory. This would be taught in an introductory course. Besides the risk of seeing a collision much sooner is much smaller than so many of the other things people take for granted.
– kasperd
Mar 24 at 20:46
1
Even so, you can't "guarantee" an "expectation", and I think your math is wrong anyway. With 40 bits of entropy the birthday paradox means that you need of the order of 1M (2^20) networks for there to be a 50% chance of any collision existing for any arbitrary pair of networks amongst all possible pairs. The chance of a collision existing for your network is 2^40 (assuming that your own ULA prefix was truly randomly selected).
– Alnitak
Mar 24 at 21:16
|
show 8 more comments
The requirement exists to prevent collisions. This is a bit more important than most people recognize.
Even if you have systems which currently don't communicate with other systems over the internet you still need your addresses to be globally unique. You may now or in the future need to add a host which can communicate both with your internal network and with the internet. And for communication with that host to work, the IP addresses with which it communicate will need to be unique.
If two internal networks exist with the same local range there is the possibility a host will eventually need to communicate with both and at that point you would have to renumber one of the networks. This kind of communication is likely to be needed if you are using a VPN connection and both client and server are on networks which make use of RFC 4193 address space.
Another way you could end up needing to communicate with other internal networks in the future is in case your company merges with another company which also uses internal networks.
40 random bits is enough to guarantee that a host which needs to communicate with multiple internal networks can expect to reach approximately one million different networks before seeing the first collision.
The 40 random bits requirement is not enforced in any way, but if you don't follow it you are setting yourself up for problems in the future when a collision happens.
The requirement exists to prevent collisions. This is a bit more important than most people recognize.
Even if you have systems which currently don't communicate with other systems over the internet you still need your addresses to be globally unique. You may now or in the future need to add a host which can communicate both with your internal network and with the internet. And for communication with that host to work, the IP addresses with which it communicate will need to be unique.
If two internal networks exist with the same local range there is the possibility a host will eventually need to communicate with both and at that point you would have to renumber one of the networks. This kind of communication is likely to be needed if you are using a VPN connection and both client and server are on networks which make use of RFC 4193 address space.
Another way you could end up needing to communicate with other internal networks in the future is in case your company merges with another company which also uses internal networks.
40 random bits is enough to guarantee that a host which needs to communicate with multiple internal networks can expect to reach approximately one million different networks before seeing the first collision.
The 40 random bits requirement is not enforced in any way, but if you don't follow it you are setting yourself up for problems in the future when a collision happens.
answered Mar 24 at 13:29
kasperdkasperd
7141613
7141613
1
I'd be careful with the words "guarantee" and "expect"; there is a chance you will find a collision after one attempt. Not a large chance, sure, but..!
– Lightness Races in Orbit
Mar 24 at 20:24
4
@LightnessRacesinOrbit The word expect is being used according to the mathematical definition of expected value.
– kasperd
Mar 24 at 20:28
1
Then you should add an explanation or disclaimer to that effect, IMO, since this is not MathOverflow :)
– Lightness Races in Orbit
Mar 24 at 20:31
1
@LightnessRacesinOrbit I actually do expect network engineers to know some probability theory. This would be taught in an introductory course. Besides the risk of seeing a collision much sooner is much smaller than so many of the other things people take for granted.
– kasperd
Mar 24 at 20:46
1
Even so, you can't "guarantee" an "expectation", and I think your math is wrong anyway. With 40 bits of entropy the birthday paradox means that you need of the order of 1M (2^20) networks for there to be a 50% chance of any collision existing for any arbitrary pair of networks amongst all possible pairs. The chance of a collision existing for your network is 2^40 (assuming that your own ULA prefix was truly randomly selected).
– Alnitak
Mar 24 at 21:16
|
show 8 more comments
1
I'd be careful with the words "guarantee" and "expect"; there is a chance you will find a collision after one attempt. Not a large chance, sure, but..!
– Lightness Races in Orbit
Mar 24 at 20:24
4
@LightnessRacesinOrbit The word expect is being used according to the mathematical definition of expected value.
– kasperd
Mar 24 at 20:28
1
Then you should add an explanation or disclaimer to that effect, IMO, since this is not MathOverflow :)
– Lightness Races in Orbit
Mar 24 at 20:31
1
@LightnessRacesinOrbit I actually do expect network engineers to know some probability theory. This would be taught in an introductory course. Besides the risk of seeing a collision much sooner is much smaller than so many of the other things people take for granted.
– kasperd
Mar 24 at 20:46
1
Even so, you can't "guarantee" an "expectation", and I think your math is wrong anyway. With 40 bits of entropy the birthday paradox means that you need of the order of 1M (2^20) networks for there to be a 50% chance of any collision existing for any arbitrary pair of networks amongst all possible pairs. The chance of a collision existing for your network is 2^40 (assuming that your own ULA prefix was truly randomly selected).
– Alnitak
Mar 24 at 21:16
1
1
I'd be careful with the words "guarantee" and "expect"; there is a chance you will find a collision after one attempt. Not a large chance, sure, but..!
– Lightness Races in Orbit
Mar 24 at 20:24
I'd be careful with the words "guarantee" and "expect"; there is a chance you will find a collision after one attempt. Not a large chance, sure, but..!
– Lightness Races in Orbit
Mar 24 at 20:24
4
4
@LightnessRacesinOrbit The word expect is being used according to the mathematical definition of expected value.
– kasperd
Mar 24 at 20:28
@LightnessRacesinOrbit The word expect is being used according to the mathematical definition of expected value.
– kasperd
Mar 24 at 20:28
1
1
Then you should add an explanation or disclaimer to that effect, IMO, since this is not MathOverflow :)
– Lightness Races in Orbit
Mar 24 at 20:31
Then you should add an explanation or disclaimer to that effect, IMO, since this is not MathOverflow :)
– Lightness Races in Orbit
Mar 24 at 20:31
1
1
@LightnessRacesinOrbit I actually do expect network engineers to know some probability theory. This would be taught in an introductory course. Besides the risk of seeing a collision much sooner is much smaller than so many of the other things people take for granted.
– kasperd
Mar 24 at 20:46
@LightnessRacesinOrbit I actually do expect network engineers to know some probability theory. This would be taught in an introductory course. Besides the risk of seeing a collision much sooner is much smaller than so many of the other things people take for granted.
– kasperd
Mar 24 at 20:46
1
1
Even so, you can't "guarantee" an "expectation", and I think your math is wrong anyway. With 40 bits of entropy the birthday paradox means that you need of the order of 1M (2^20) networks for there to be a 50% chance of any collision existing for any arbitrary pair of networks amongst all possible pairs. The chance of a collision existing for your network is 2^40 (assuming that your own ULA prefix was truly randomly selected).
– Alnitak
Mar 24 at 21:16
Even so, you can't "guarantee" an "expectation", and I think your math is wrong anyway. With 40 bits of entropy the birthday paradox means that you need of the order of 1M (2^20) networks for there to be a 50% chance of any collision existing for any arbitrary pair of networks amongst all possible pairs. The chance of a collision existing for your network is 2^40 (assuming that your own ULA prefix was truly randomly selected).
– Alnitak
Mar 24 at 21:16
|
show 8 more comments
When companies merge or set up an extranet to communicate, it has proven difficult with IPv4 Private addressing because the companies often use the same or overlapping address space, and that requires the ugly hack of NAT to get around, and that can cause problems and break many protocols.
This was identified as a problem when IPv6 ULA was being developed, and the goal was to allow companies to have non-Internet address space, but to have a very high probability that the space used was unique. This is to try to prevent the problem of merging or communication between companies using non-Internet addressing. IPv6 doesn't have NAT, and the goal of IPv6 is to restore the IP end-to-end connectivity that was lost when NAT became necessary due to the limited number of IPv4 addresses.
The first half of the IPv6 ULA space (fc00::/8
) is reserved for assignment by a (yet to be named) global authority, while the second half of the IPv6 ULA space (fd00::/8
) was set up so that companies could assign their own addressing with a high probability of uniqueness.
According to RFC 4193, unique local addresses will always have a
prefix ofFD00::/8
That is simply incorrect. That RFC defines the ULA space as fc00::/7
, but there are two parts to the space that are defined by the eighth bit ("L" bit).
From the RFC:
3.1. Format
The Local IPv6 addresses are created using a pseudo-randomly allocated
global ID. They have the following format:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
This divides the ULA space into two /8
spaces: fc00::/8
for globally assigned addressing, and fd00::/8
for locally assigned addressing. Notice the format in the RFC requires "a pseudo-randomly allocated global ID." This is further explained:
3.2. Global ID
The allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT
be assigned sequentially or with well-known numbers. This is to ensure
that there is not any relationship between allocations and to help
clarify that these prefixes are not intended to be routed globally.
Specifically, these prefixes are not designed to aggregate.
This document defines a specific local method to allocate Global IDs,
indicated by setting the L bit to 1. Another method, indicated by
clearing the L bit, may be defined later. Apart from the allocation
method, all Local IPv6 addresses behave and are treated identically.
The local assignments are self-generated and do not need any central
coordination or assignment, but have an extremely high probability of
being unique.
As you can see, the premise of your question that the RFC says that ULA addresses will always have a prefix of fd00::/8
is incorrect.
Is this enforced, and if so why? What stops me from having a prefix of
/32 or /16 etc?
There is no actual enforcement, the way there would be if you were trying to use the addressing on the public Internet. Your company could simply use any addressing in that space, in whatever blocks it wants. What your business does for addressing on its own network is completely up to it, but it could prove foolish and expensive in the long run to not follow the standards.
For example, I know of some companies that used "dark" IPv4 address space within their networks, but then the dark address space started to be used on the public Internet, and the companies were unable to connect with customers or vendors using addressing in that address space, and it took some ugly solutions to get around that in the short term, until all the internal networks using that address space were readdressed. It took a few years and a lot of money to fix the problems.
RFC 4193, Unique Local IPv6 Unicast Addresses is the definition of IPv6 ULA, and you should refer to it for the details:
1. Introduction
This document defines an IPv6 unicast address format that is globally
unique and is intended for local communications [IPV6]. These
addresses are called Unique Local IPv6 Unicast Addresses and are
abbreviated in this document as Local IPv6 addresses. They are not
expected to be routable on the global Internet. They are routable
inside of a more limited area such as a site. They may also be routed
between a limited set of sites.
Local IPv6 unicast addresses have the following characteristics:
Globally unique prefix (with high probability of uniqueness).
Well-known prefix to allow for easy filtering at site
boundaries.
Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of
interfaces that use these prefixes.
Internet Service Provider independent and can be used for
communications inside of a site without having any permanent or
intermittent Internet connectivity.
If accidentally leaked outside of a site via routing or DNS,
there is no conflict with any other addresses.
In practice, applications may treat these addresses like global
scoped addresses.
This document defines the format of Local IPv6 addresses, how to
allocate them, and usage considerations including routing, site border
routers, DNS, application support, VPN usage, and guidelines for how
to use for local communication inside a site.
add a comment |
When companies merge or set up an extranet to communicate, it has proven difficult with IPv4 Private addressing because the companies often use the same or overlapping address space, and that requires the ugly hack of NAT to get around, and that can cause problems and break many protocols.
This was identified as a problem when IPv6 ULA was being developed, and the goal was to allow companies to have non-Internet address space, but to have a very high probability that the space used was unique. This is to try to prevent the problem of merging or communication between companies using non-Internet addressing. IPv6 doesn't have NAT, and the goal of IPv6 is to restore the IP end-to-end connectivity that was lost when NAT became necessary due to the limited number of IPv4 addresses.
The first half of the IPv6 ULA space (fc00::/8
) is reserved for assignment by a (yet to be named) global authority, while the second half of the IPv6 ULA space (fd00::/8
) was set up so that companies could assign their own addressing with a high probability of uniqueness.
According to RFC 4193, unique local addresses will always have a
prefix ofFD00::/8
That is simply incorrect. That RFC defines the ULA space as fc00::/7
, but there are two parts to the space that are defined by the eighth bit ("L" bit).
From the RFC:
3.1. Format
The Local IPv6 addresses are created using a pseudo-randomly allocated
global ID. They have the following format:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
This divides the ULA space into two /8
spaces: fc00::/8
for globally assigned addressing, and fd00::/8
for locally assigned addressing. Notice the format in the RFC requires "a pseudo-randomly allocated global ID." This is further explained:
3.2. Global ID
The allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT
be assigned sequentially or with well-known numbers. This is to ensure
that there is not any relationship between allocations and to help
clarify that these prefixes are not intended to be routed globally.
Specifically, these prefixes are not designed to aggregate.
This document defines a specific local method to allocate Global IDs,
indicated by setting the L bit to 1. Another method, indicated by
clearing the L bit, may be defined later. Apart from the allocation
method, all Local IPv6 addresses behave and are treated identically.
The local assignments are self-generated and do not need any central
coordination or assignment, but have an extremely high probability of
being unique.
As you can see, the premise of your question that the RFC says that ULA addresses will always have a prefix of fd00::/8
is incorrect.
Is this enforced, and if so why? What stops me from having a prefix of
/32 or /16 etc?
There is no actual enforcement, the way there would be if you were trying to use the addressing on the public Internet. Your company could simply use any addressing in that space, in whatever blocks it wants. What your business does for addressing on its own network is completely up to it, but it could prove foolish and expensive in the long run to not follow the standards.
For example, I know of some companies that used "dark" IPv4 address space within their networks, but then the dark address space started to be used on the public Internet, and the companies were unable to connect with customers or vendors using addressing in that address space, and it took some ugly solutions to get around that in the short term, until all the internal networks using that address space were readdressed. It took a few years and a lot of money to fix the problems.
RFC 4193, Unique Local IPv6 Unicast Addresses is the definition of IPv6 ULA, and you should refer to it for the details:
1. Introduction
This document defines an IPv6 unicast address format that is globally
unique and is intended for local communications [IPV6]. These
addresses are called Unique Local IPv6 Unicast Addresses and are
abbreviated in this document as Local IPv6 addresses. They are not
expected to be routable on the global Internet. They are routable
inside of a more limited area such as a site. They may also be routed
between a limited set of sites.
Local IPv6 unicast addresses have the following characteristics:
Globally unique prefix (with high probability of uniqueness).
Well-known prefix to allow for easy filtering at site
boundaries.
Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of
interfaces that use these prefixes.
Internet Service Provider independent and can be used for
communications inside of a site without having any permanent or
intermittent Internet connectivity.
If accidentally leaked outside of a site via routing or DNS,
there is no conflict with any other addresses.
In practice, applications may treat these addresses like global
scoped addresses.
This document defines the format of Local IPv6 addresses, how to
allocate them, and usage considerations including routing, site border
routers, DNS, application support, VPN usage, and guidelines for how
to use for local communication inside a site.
add a comment |
When companies merge or set up an extranet to communicate, it has proven difficult with IPv4 Private addressing because the companies often use the same or overlapping address space, and that requires the ugly hack of NAT to get around, and that can cause problems and break many protocols.
This was identified as a problem when IPv6 ULA was being developed, and the goal was to allow companies to have non-Internet address space, but to have a very high probability that the space used was unique. This is to try to prevent the problem of merging or communication between companies using non-Internet addressing. IPv6 doesn't have NAT, and the goal of IPv6 is to restore the IP end-to-end connectivity that was lost when NAT became necessary due to the limited number of IPv4 addresses.
The first half of the IPv6 ULA space (fc00::/8
) is reserved for assignment by a (yet to be named) global authority, while the second half of the IPv6 ULA space (fd00::/8
) was set up so that companies could assign their own addressing with a high probability of uniqueness.
According to RFC 4193, unique local addresses will always have a
prefix ofFD00::/8
That is simply incorrect. That RFC defines the ULA space as fc00::/7
, but there are two parts to the space that are defined by the eighth bit ("L" bit).
From the RFC:
3.1. Format
The Local IPv6 addresses are created using a pseudo-randomly allocated
global ID. They have the following format:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
This divides the ULA space into two /8
spaces: fc00::/8
for globally assigned addressing, and fd00::/8
for locally assigned addressing. Notice the format in the RFC requires "a pseudo-randomly allocated global ID." This is further explained:
3.2. Global ID
The allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT
be assigned sequentially or with well-known numbers. This is to ensure
that there is not any relationship between allocations and to help
clarify that these prefixes are not intended to be routed globally.
Specifically, these prefixes are not designed to aggregate.
This document defines a specific local method to allocate Global IDs,
indicated by setting the L bit to 1. Another method, indicated by
clearing the L bit, may be defined later. Apart from the allocation
method, all Local IPv6 addresses behave and are treated identically.
The local assignments are self-generated and do not need any central
coordination or assignment, but have an extremely high probability of
being unique.
As you can see, the premise of your question that the RFC says that ULA addresses will always have a prefix of fd00::/8
is incorrect.
Is this enforced, and if so why? What stops me from having a prefix of
/32 or /16 etc?
There is no actual enforcement, the way there would be if you were trying to use the addressing on the public Internet. Your company could simply use any addressing in that space, in whatever blocks it wants. What your business does for addressing on its own network is completely up to it, but it could prove foolish and expensive in the long run to not follow the standards.
For example, I know of some companies that used "dark" IPv4 address space within their networks, but then the dark address space started to be used on the public Internet, and the companies were unable to connect with customers or vendors using addressing in that address space, and it took some ugly solutions to get around that in the short term, until all the internal networks using that address space were readdressed. It took a few years and a lot of money to fix the problems.
RFC 4193, Unique Local IPv6 Unicast Addresses is the definition of IPv6 ULA, and you should refer to it for the details:
1. Introduction
This document defines an IPv6 unicast address format that is globally
unique and is intended for local communications [IPV6]. These
addresses are called Unique Local IPv6 Unicast Addresses and are
abbreviated in this document as Local IPv6 addresses. They are not
expected to be routable on the global Internet. They are routable
inside of a more limited area such as a site. They may also be routed
between a limited set of sites.
Local IPv6 unicast addresses have the following characteristics:
Globally unique prefix (with high probability of uniqueness).
Well-known prefix to allow for easy filtering at site
boundaries.
Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of
interfaces that use these prefixes.
Internet Service Provider independent and can be used for
communications inside of a site without having any permanent or
intermittent Internet connectivity.
If accidentally leaked outside of a site via routing or DNS,
there is no conflict with any other addresses.
In practice, applications may treat these addresses like global
scoped addresses.
This document defines the format of Local IPv6 addresses, how to
allocate them, and usage considerations including routing, site border
routers, DNS, application support, VPN usage, and guidelines for how
to use for local communication inside a site.
When companies merge or set up an extranet to communicate, it has proven difficult with IPv4 Private addressing because the companies often use the same or overlapping address space, and that requires the ugly hack of NAT to get around, and that can cause problems and break many protocols.
This was identified as a problem when IPv6 ULA was being developed, and the goal was to allow companies to have non-Internet address space, but to have a very high probability that the space used was unique. This is to try to prevent the problem of merging or communication between companies using non-Internet addressing. IPv6 doesn't have NAT, and the goal of IPv6 is to restore the IP end-to-end connectivity that was lost when NAT became necessary due to the limited number of IPv4 addresses.
The first half of the IPv6 ULA space (fc00::/8
) is reserved for assignment by a (yet to be named) global authority, while the second half of the IPv6 ULA space (fd00::/8
) was set up so that companies could assign their own addressing with a high probability of uniqueness.
According to RFC 4193, unique local addresses will always have a
prefix ofFD00::/8
That is simply incorrect. That RFC defines the ULA space as fc00::/7
, but there are two parts to the space that are defined by the eighth bit ("L" bit).
From the RFC:
3.1. Format
The Local IPv6 addresses are created using a pseudo-randomly allocated
global ID. They have the following format:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
This divides the ULA space into two /8
spaces: fc00::/8
for globally assigned addressing, and fd00::/8
for locally assigned addressing. Notice the format in the RFC requires "a pseudo-randomly allocated global ID." This is further explained:
3.2. Global ID
The allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT
be assigned sequentially or with well-known numbers. This is to ensure
that there is not any relationship between allocations and to help
clarify that these prefixes are not intended to be routed globally.
Specifically, these prefixes are not designed to aggregate.
This document defines a specific local method to allocate Global IDs,
indicated by setting the L bit to 1. Another method, indicated by
clearing the L bit, may be defined later. Apart from the allocation
method, all Local IPv6 addresses behave and are treated identically.
The local assignments are self-generated and do not need any central
coordination or assignment, but have an extremely high probability of
being unique.
As you can see, the premise of your question that the RFC says that ULA addresses will always have a prefix of fd00::/8
is incorrect.
Is this enforced, and if so why? What stops me from having a prefix of
/32 or /16 etc?
There is no actual enforcement, the way there would be if you were trying to use the addressing on the public Internet. Your company could simply use any addressing in that space, in whatever blocks it wants. What your business does for addressing on its own network is completely up to it, but it could prove foolish and expensive in the long run to not follow the standards.
For example, I know of some companies that used "dark" IPv4 address space within their networks, but then the dark address space started to be used on the public Internet, and the companies were unable to connect with customers or vendors using addressing in that address space, and it took some ugly solutions to get around that in the short term, until all the internal networks using that address space were readdressed. It took a few years and a lot of money to fix the problems.
RFC 4193, Unique Local IPv6 Unicast Addresses is the definition of IPv6 ULA, and you should refer to it for the details:
1. Introduction
This document defines an IPv6 unicast address format that is globally
unique and is intended for local communications [IPV6]. These
addresses are called Unique Local IPv6 Unicast Addresses and are
abbreviated in this document as Local IPv6 addresses. They are not
expected to be routable on the global Internet. They are routable
inside of a more limited area such as a site. They may also be routed
between a limited set of sites.
Local IPv6 unicast addresses have the following characteristics:
Globally unique prefix (with high probability of uniqueness).
Well-known prefix to allow for easy filtering at site
boundaries.
Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of
interfaces that use these prefixes.
Internet Service Provider independent and can be used for
communications inside of a site without having any permanent or
intermittent Internet connectivity.
If accidentally leaked outside of a site via routing or DNS,
there is no conflict with any other addresses.
In practice, applications may treat these addresses like global
scoped addresses.
This document defines the format of Local IPv6 addresses, how to
allocate them, and usage considerations including routing, site border
routers, DNS, application support, VPN usage, and guidelines for how
to use for local communication inside a site.
edited Mar 25 at 3:09
answered Mar 24 at 15:34
Ron Maupin♦Ron Maupin
67.9k1369126
67.9k1369126
add a comment |
add a comment |
Sam P is a new contributor. Be nice, and check out our Code of Conduct.
Sam P is a new contributor. Be nice, and check out our Code of Conduct.
Sam P is a new contributor. Be nice, and check out our Code of Conduct.
Sam P is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57921%2fwhy-do-ipv6-unique-local-addresses-have-to-have-a-48-prefix%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Remember the the "U" in ULA stands for "unique."
– Ron Maupin♦
Mar 24 at 16:03