IPv6 fc00::/7 — Unique local addresses
<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 -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
On Wed, 20 Oct 2010, Jeroen van Aart wrote:
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.
Use the cool tool at http://www.sixxs.net/tools/grh/ula/ to generate a ULA, then use it for local-scope stuff. Slick. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951
On Wed, 20 Oct 2010 14:48:47 -0700 Jeroen van Aart <jeroen@mompl.net> wrote:
<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 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.
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. Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick. Deepak
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 -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote:
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
On 21/10/2010 02:41, Owen DeLong wrote:
On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote:
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.
Someone insisted to me yesterday the RFC1918-like address space was the only way to provide a 'friendly' place for people to start their journey in playing with IPv6. I think that the idea of real routable IPs on a lab network daunts many people. I've been down the road with ULA a few years back and I have to agree with Owen - rather just do it on GUA. I was adding IPv6 to a fairly large experimental network and started using ULA. The local NREN then invited me to peer with them but I couldn't announce my ULA to them. They are running a 'public Internet' network and have a backbone that will just filter them. I think that the biggest thing that trips people up is that they think that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting your own GUA from an RIR isn't tough - rather just do it. -- Graham Beneke
In message <4CBFC1D0.60808@apolix.co.za>, Graham Beneke writes:
On 21/10/2010 02:41, Owen DeLong wrote:
On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote:
Someone advised me to use GUA instead of ULA. But since for my purposes th is 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 t o something that connects to the internet or whatever, GUA provides the following advantages: + Guaranteed uniqueness (not just statistically probable uniquene ss) + You can route it if you later desire to
Since ULA offers no real advantages, I don't really see the point.
Someone insisted to me yesterday the RFC1918-like address space was the only way to provide a 'friendly' place for people to start their journey in playing with IPv6. I think that the idea of real routable IPs on a lab network daunts many people.
I've been down the road with ULA a few years back and I have to agree with Owen - rather just do it on GUA.
Your throwing the baby out with the bath water here. ULA, by itself, is a painful especially when you have global IPv4 reachability as you end up with lots of timeouts. This is similar to have a bad 6to4 upsteam link. Just don't go there. ULA + PA works and provides stable internal addresses when your upstream link in down the same way as RFC 1918 provides stable internal addressing for IPv4 when your upstream link is down. You talk to the world using PA addresses, directly for IPv6 and indirectly via PNAT for IPv4. These can change over time. Similarly, ULA + 6to4 works well provided the 6to4 works when you are connected. When your IPv4 connection is renumbered you have a new external addresses but the internal addresses stay the same.
I was adding IPv6 to a fairly large experimental network and started using ULA. The local NREN then invited me to peer with them but I couldn't announce my ULA to them. They are running a 'public Internet' network and have a backbone that will just filter them.
I think that the biggest thing that trips people up is that they think that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting your own GUA from an RIR isn't tough - rather just do it.
If your big enough to get your own GUA and have the dollars to get it routed then do that. If you are forced to use PA (think home networks) then having a ULA prefix as well is a good thing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Oct 20, 2010, at 10:28 PM, Mark Andrews wrote:
In message <4CBFC1D0.60808@apolix.co.za>, Graham Beneke writes:
On 21/10/2010 02:41, Owen DeLong wrote:
On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote:
Someone advised me to use GUA instead of ULA. But since for my purposes th is 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 t o something that connects to the internet or whatever, GUA provides the following advantages: + Guaranteed uniqueness (not just statistically probable uniquene ss) + You can route it if you later desire to
Since ULA offers no real advantages, I don't really see the point.
Someone insisted to me yesterday the RFC1918-like address space was the only way to provide a 'friendly' place for people to start their journey in playing with IPv6. I think that the idea of real routable IPs on a lab network daunts many people.
I've been down the road with ULA a few years back and I have to agree with Owen - rather just do it on GUA.
Your throwing the baby out with the bath water here.
ULA, by itself, is a painful especially when you have global IPv4 reachability as you end up with lots of timeouts. This is similar to have a bad 6to4 upsteam link. Just don't go there.
ULA + PA works and provides stable internal addresses when your upstream link in down the same way as RFC 1918 provides stable internal addressing for IPv4 when your upstream link is down.
I keep hearing this and it never makes sense to me. If your provider will assign you a static /48, then, you have stable addresses when your provider link is down in GUA. Who needs ULA?
You talk to the world using PA addresses, directly for IPv6 and indirectly via PNAT for IPv4. These can change over time.
Or, if you don't want your IPv6 addresses to change over time, you can get a prefix from your friendly RIR.
Similarly, ULA + 6to4 works well provided the 6to4 works when you are connected. When your IPv4 connection is renumbered you have a new external addresses but the internal addresses stay the same.
That's a big "provided that"... One over which you have little or no control unless you are running a 6to4 gateway of your own and can guarantee that nobody pretends to be one that is topologically closer to any of your users.
I was adding IPv6 to a fairly large experimental network and started using ULA. The local NREN then invited me to peer with them but I couldn't announce my ULA to them. They are running a 'public Internet' network and have a backbone that will just filter them.
I think that the biggest thing that trips people up is that they think that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting your own GUA from an RIR isn't tough - rather just do it.
If your big enough to get your own GUA and have the dollars to get it routed then do that. If you are forced to use PA (think home networks) then having a ULA prefix as well is a good thing.
home network: 2620:0:930::/48 Try again. Owen
On Thu, Oct 21, 2010 at 04:46, Owen DeLong <owen@delong.com> wrote:
On Oct 20, 2010, at 10:28 PM, Mark Andrews wrote:
If your big enough to get your own GUA and have the dollars to get it routed then do that. If you are forced to use PA (think home networks) then having a ULA prefix as well is a good thing.
home network: 2620:0:930::/48
Try again.
How do you justify that to ARIN? My reading of the NRPM 6.5.8 ("qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect") and 4.3 (v4 /24 minimum for multihoming, 50% utilization) is that you need at least 128 devices to get a multihoming allocation. That's quite a home network you have. In a related vein, I'm looking at IPv6-numbering a non-connected private network of a few hundred hosts, and while a GUA assignment would be ideal, it looks like I need at least 2048 (50% of a v4 /20) devices to qualify for a non-multihomed v6 assignment. Am I missing something? -Ben
In message <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com>, Owen DeLong write s: > > On Oct 20, 2010, at 10:28 PM, Mark Andrews wrote: > > >=20 > > In message <4CBFC1D0.60808@apolix.co.za>, Graham Beneke writes: > >> On 21/10/2010 02:41, Owen DeLong wrote: > >>> On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote: > >>>> Someone advised me to use GUA instead of ULA. But since for my = > purposes th > >> is is used for an IPv6 LAN would ULA not be the better choice? > >>>>=20 > >>> 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 t > >> o something that connects to the internet or whatever, GUA provides > >>> the following advantages: > >>> + Guaranteed uniqueness (not just statistically probable = > uniquene > >> ss) > >>> + You can route it if you later desire to > >>>=20 > >>> Since ULA offers no real advantages, I don't really see the point. > >>=20 > >> Someone insisted to me yesterday the RFC1918-like address space was = > the=20 > >> only way to provide a 'friendly' place for people to start their = > journey=20 > >> in playing with IPv6. I think that the idea of real routable IPs on a=20= > > >> lab network daunts many people. > >>=20 > >> I've been down the road with ULA a few years back and I have to agree=20= > > >> with Owen - rather just do it on GUA. > >=20 > > Your throwing the baby out with the bath water here. > >=20 > > ULA, by itself, is a painful especially when you have global IPv4 > > reachability as you end up with lots of timeouts. This is similar > > to have a bad 6to4 upsteam link. Just don't go there. > >=20 > > ULA + PA works and provides stable internal addresses when your > > upstream link in down the same way as RFC 1918 provides stable > > internal addressing for IPv4 when your upstream link is down. > >=20 > I keep hearing this and it never makes sense to me. > > If your provider will assign you a static /48, then, you have stable > addresses when your provider link is down in GUA. Who needs ULA? You used the word "if". Reverse the sense of the "if" and see if it still doesn't makes sense to use ULA addresses. I get a mostly stable IPv4 address from my cable provider (DHCP). That address changes without notice about once a year. I can configure a 6to4 prefix based on that address (effectively a PA prefix). I use ULA addresses internally and 6to4 (PA) externally. Same for 6rd. Same for PD. DHCP derived 6to4, DHCP derived 6rd, DHCP derived Terado and PD all give you leased prefixes. They are not guarenteed to be STABLE. For internal communication you really do want stable prefixes. ULA gives you those stable prefixes. > > You talk to the world using PA addresses, directly for IPv6 and > > indirectly via PNAT for IPv4. These can change over time. > >=20 > Or, if you don't want your IPv6 addresses to change over time, you can > get a prefix from your friendly RIR. You really think I'm going to go to my RIR and get a addresses block for my home network then my cable provider will route it for me? > > Similarly, ULA + 6to4 works well provided the 6to4 works when you > > are connected. When your IPv4 connection is renumbered you have a > > new external addresses but the internal addresses stay the same. > >=20 > That's a big "provided that"... Not really. It works for lots of people. > One over which you have little or no control unless you are running > a 6to4 gateway of your own and can guarantee that nobody pretends > to be one that is topologically closer to any of your users. > > >> I was adding IPv6 to a fairly large experimental network and started=20= > > >> using ULA. The local NREN then invited me to peer with them but I=20 > >> couldn't announce my ULA to them. They are running a 'public = > Internet'=20 > >> network and have a backbone that will just filter them. > >>=20 > >> I think that the biggest thing that trips people up is that they = > think=20 > >> that they'll just fix-it-with-NAT to get onto the GUA Internet. = > Getting=20 > >> your own GUA from an RIR isn't tough - rather just do it. > >=20 > > If your big enough to get your own GUA and have the dollars to get > > it routed then do that. If you are forced to use PA (think home > > networks) then having a ULA prefix as well is a good thing. > >=20 > home network: 2620:0:930::/48 > > Try again. And you expect the routing system to cope when 2 billion homes do the same thing? > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
I keep hearing this and it never makes sense to me.
If your provider will assign you a static /48, then, you have stable addresses when your provider link is down in GUA. Who needs ULA?
You used the word "if". Reverse the sense of the "if" and see if it still doesn't makes sense to use ULA addresses. I get a mostly stable IPv4 address from my cable provider (DHCP). That address changes without notice about once a year. I can configure a 6to4 prefix based on that address (effectively a PA prefix). I use ULA addresses internally and 6to4 (PA) externally. Same for 6rd. Same for PD.
I use the dynamic address from my cable provider to terminate a set of GRE tunnels to my colo routers. I use the static address from my DSL provider to terminate other GRE tunnels to my colo routers. The DSL tunnels are all carrying both IPv4 and IPv6. When the cable address changes, the BGP sessions over those GRE tunnels drop and my network connection slows down. When I repair the tunnels with the new end-point address, everything goes back to fast.
DHCP derived 6to4, DHCP derived 6rd, DHCP derived Terado and PD all give you leased prefixes. They are not guarenteed to be STABLE. For internal communication you really do want stable prefixes. ULA gives you those stable prefixes.
Yep... Makes much more sense to have at least one provider with static and do native IPv6 than to use 6to4, 6rd, Teredo, or PD.
You talk to the world using PA addresses, directly for IPv6 and indirectly via PNAT for IPv4. These can change over time. =20 Or, if you don't want your IPv6 addresses to change over time, you can get a prefix from your friendly RIR.
You really think I'm going to go to my RIR and get a addresses block for my home network then my cable provider will route it for me?
No... I think you might go to your RIR and get an address block for your home network then find a way to use your cable provider for L2 transport and route it. That solution works quite well for me.
Similarly, ULA + 6to4 works well provided the 6to4 works when you are connected. When your IPv4 connection is renumbered you have a new external addresses but the internal addresses stay the same. =20 That's a big "provided that"...
Not really. It works for lots of people.
Then how come I hear a lot more 6to4 horror stories than 6to4 success stories? It's not like I don't talk to lots of people using these protocols on a daily basis.
And you expect the routing system to cope when 2 billion homes do the same thing?
As a matter of fact, I think the routing system damn well better start planning to cope with just that scenario. I think it is inevitable in one form or another. Owen
In message <B8AA2A26-3B41-4427-90F6-26EB9E6BE227@delong.com>, Owen DeLong write s:
I keep hearing this and it never makes sense to me.
If your provider will assign you a static /48, then, you have stable addresses when your provider link is down in GUA. Who needs ULA?
You used the word "if". Reverse the sense of the "if" and see if it still doesn't makes sense to use ULA addresses. I get a mostly stable IPv4 address from my cable provider (DHCP). That address changes without notice about once a year. I can configure a 6to4 prefix based on that address (effectively a PA prefix). I use ULA addresses internally and 6to4 (PA) externally. Same for 6rd. Same for PD.
I use the dynamic address from my cable provider to terminate a set of GRE tunnels to my colo routers. < I use the static address from my DSL provider to terminate other GRE tunnels to my colo routers.
The DSL tunnels are all carrying both IPv4 and IPv6.
When the cable address changes, the BGP sessions over those GRE tunnels drop and my network connection slows down. When I repair the tunnels with the new end-point address, everything goes back to fast.
You've gone way past what the average home user can or should be expected to handle here. Your well into advanced user territory. I've done the same sort of thing but I don't see myself as a average home user. The average home user should be able to plug in a home router into the network connection from the ISP. Plug that into a 10/100/1000 switch or turn on WiFi and plug in there hosts / enable WiFi on the hosts and have the network work regardless of whether the upstream is working or not. If they have bought the multi-upstream router then plug all isps in (Cable/DSL/WiMax/....) and have the whole thing work regardless of how many upstream links are working.
DHCP derived 6to4, DHCP derived 6rd, DHCP derived Terado and PD all give you leased prefixes. They are not guarenteed to be STABLE. For internal communication you really do want stable prefixes. ULA gives you those stable prefixes.
Yep... Makes much more sense to have at least one provider with static and do native IPv6 than to use 6to4, 6rd, Teredo, or PD.
Well when you can get agreements from all the residential ISPs to provide static IPv6 address come back to me. In the meantime I'm going to plan how to handle non static assignments,
You talk to the world using PA addresses, directly for IPv6 and indirectly via PNAT for IPv4. These can change over time. =3D20 Or, if you don't want your IPv6 addresses to change over time, you = can get a prefix from your friendly RIR.
You really think I'm going to go to my RIR and get a addresses block for my home network then my cable provider will route it for me?
No... I think you might go to your RIR and get an address block for your home network then find a way to use your cable provider for L2 transport and route it. That solution works quite well for me.
You still had to have someone route it somewhere be it the cable provider or someone else you reach over the cable provider.
Similarly, ULA + 6to4 works well provided the 6to4 works when you are connected. When your IPv4 connection is renumbered you have a new external addresses but the internal addresses stay the same.
That's a big "provided that"...
Not really. It works for lots of people.
Then how come I hear a lot more 6to4 horror stories than 6to4 success stories? It's not like I don't talk to lots of people using these protocols on a daily basis.
Because people complain when things break. They are silent when things work.
And you expect the routing system to cope when 2 billion homes do the same thing?
As a matter of fact, I think the routing system damn well better start planning to cope with just that scenario. I think it is inevitable in one form or another.
Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, 2010-10-21 at 01:46 -0700, Owen DeLong wrote:
If your big enough to get your own GUA and have the dollars to get it routed then do that. If you are forced to use PA (think home networks) then having a ULA prefix as well is a good thing.
home network: 2620:0:930::/48
In Oz it costs real money to get IPv6 address space from the RIR (APNIC). Around AUD$6K in the first year, around AUD$1100 each year thereafter. Your /48, according to the ARIN website, cost you US$625 this year, will cost US$937.50 next year, and $1250 every year thereafter. Fairly trivial amounts for most commercial entities, but prohibitive for all but the most enthusiastic home user. 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 1
Karl, Where does the 6K come from? AUD$4,175 is the amount - It consists of the "Associate Member Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500) Then AUD1180 for a /48 each year. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Arista -
-----Original Message----- From: Karl Auer [mailto:kauer@biplane.com.au] Sent: Friday, 22 October 2010 10:00 AM To: nanog@nanog.org Subject: Re: IPv6 fc00::/7 - Unique local addresses
On Thu, 2010-10-21 at 01:46 -0700, Owen DeLong wrote:
If your big enough to get your own GUA and have the dollars to get it routed then do that. If you are forced to use PA (think home networks) then having a ULA prefix as well is a good thing.
home network: 2620:0:930::/48
In Oz it costs real money to get IPv6 address space from the RIR (APNIC). Around AUD$6K in the first year, around AUD$1100 each year thereafter.
Your /48, according to the ARIN website, cost you US$625 this year, will cost US$937.50 next year, and $1250 every year thereafter.
Fairly trivial amounts for most commercial entities, but prohibitive for all but the most enthusiastic home user.
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 1
On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote:
Where does the 6K come from?
AUD$4,175 is the amount - It consists of the "Associate Member Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500)
Then AUD1180 for a /48 each year.
Er - apologies. Yes, the initial fee covers the first year's annual fee, so it's $4175 in the first year ans $1100 in subsequent years. The point still stands though - that's WAY too much for home users. While for Owen such costs might be doable, for the vast majority of home users in the AP region the only viable alternatives for internal addressing will be PA or ULA. Even with the lower costs that ARIN users pay, the prices are still IMHO too high for home users to be using PI in any significant numbers. 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
Small correction - there is no annual fee in the first year ;-) But I agree.. it is too much, and APNIC have been reviewing the Initial allocation fee for a while now, but haven't made any move on it. I'd like to see a new class of membership - 'Individual' which had a small allocation (well, in comparison) and had a cheaper membership level and was not required to be multi-homed, but was portable - and a small, if any initial allocation fee. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Arista -
-----Original Message----- From: Karl Auer [mailto:kauer@biplane.com.au] Sent: Friday, 22 October 2010 10:48 AM To: nanog@nanog.org Subject: RE: IPv6 fc00::/7 - Unique local addresses
On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote:
Where does the 6K come from?
AUD$4,175 is the amount - It consists of the "Associate Member Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500)
Then AUD1180 for a /48 each year.
Er - apologies. Yes, the initial fee covers the first year's annual fee, so it's $4175 in the first year ans $1100 in subsequent years.
The point still stands though - that's WAY too much for home users.
While for Owen such costs might be doable, for the vast majority of home users in the AP region the only viable alternatives for internal addressing will be PA or ULA.
Even with the lower costs that ARIN users pay, the prices are still IMHO too high for home users to be using PI in any significant numbers.
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 Oct 21, 2010, at 4:48 PM, Karl Auer wrote:
On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote:
Where does the 6K come from?
AUD$4,175 is the amount - It consists of the "Associate Member Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500)
Then AUD1180 for a /48 each year.
Er - apologies. Yes, the initial fee covers the first year's annual fee, so it's $4175 in the first year ans $1100 in subsequent years.
The point still stands though - that's WAY too much for home users.
While for Owen such costs might be doable, for the vast majority of home users in the AP region the only viable alternatives for internal addressing will be PA or ULA.
This is NANOG. To the best of my knowledge, no part of the NA in NANOG is in the APNIC service area. ARIN pricing is significantly better at US$100/year for ALL end-user resources, so, only the $1250 up-front fee would apply and apparently the partial fee-waiver for that is still in effect if your previous posting was correct.
Even with the lower costs that ARIN users pay, the prices are still IMHO too high for home users to be using PI in any significant numbers.
Really? $100/year is too much? Really? I guess that depends on whether you think addresses are worth more than coffee. ;-) Owen
In message <3D230C80-E7CC-4B73-9E47-780DF5FA33AC@delong.com>, Owen DeLong write s:
On Oct 21, 2010, at 4:48 PM, Karl Auer wrote:
On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote:
Where does the 6K come from?
AUD$4,175 is the amount - It consists of the "Associate Member Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500)
Then AUD1180 for a /48 each year.
Er - apologies. Yes, the initial fee covers the first year's annual fee, so it's $4175 in the first year ans $1100 in subsequent years.
The point still stands though - that's WAY too much for home users.
While for Owen such costs might be doable, for the vast majority of home users in the AP region the only viable alternatives for internal addressing will be PA or ULA.
This is NANOG. To the best of my knowledge, no part of the NA in NANOG is in the APNIC service area.
ARIN pricing is significantly better at US$100/year for ALL end-user resources, so, only the $1250 up-front fee would apply and apparently the partial fee-waiver for that is still in effect if your previous posting was correct.
Which is still too expensive for the home user.
Even with the lower costs that ARIN users pay, the prices are still IMHO too high for home users to be using PI in any significant numbers.
Really? $100/year is too much? Really? I guess that depends on whether you think addresses are worth more than coffee. ;-)
$100/year for a address block that nobody will route and requires someone to setup the address selection rules compared to a ULA at $0 that the OS vendors will make work well by default.
Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In Oz it costs real money to get IPv6 address space from the RIR (APNIC). Around AUD$6K in the first year, around AUD$1100 each year thereafter.
Your /48, according to the ARIN website, cost you US$625 this year, will cost US$937.50 next year, and $1250 every year thereafter.
Correction: For endusers it is $1250 initially, and $100 per year thereafter. Much closer to affordable. That same $100 also covers an ASN if you have one. ISPs are charged the large yearly fee.
Fairly trivial amounts for most commercial entities, but prohibitive for all but the most enthusiastic home user.
Justification aside, it is quote affordable for a typical power user. -Randy
On Oct 21, 2010, at 3:59 PM, Karl Auer wrote:
On Thu, 2010-10-21 at 01:46 -0700, Owen DeLong wrote:
If your big enough to get your own GUA and have the dollars to get it routed then do that. If you are forced to use PA (think home networks) then having a ULA prefix as well is a good thing.
home network: 2620:0:930::/48
In Oz it costs real money to get IPv6 address space from the RIR (APNIC). Around AUD$6K in the first year, around AUD$1100 each year thereafter.
Your /48, according to the ARIN website, cost you US$625 this year, will cost US$937.50 next year, and $1250 every year thereafter.
Uh, no... You're misreading it. It cost me $625 (or possibly less) one-time when I first got it. After that, the annual $100/year has been part of the same $100/year I've been paying for my IPv4 resources.
Fairly trivial amounts for most commercial entities, but prohibitive for all but the most enthusiastic home user.
Agreed, but, at $100/year that I was already paying for IPv4, it seemed pretty trivial. I bet you spend more than that at Starbucks each year. Owen
On Thu, 2010-10-21 at 18:48 -0700, Owen DeLong wrote:
Uh, no... You're misreading it.
Yes - I read the ISP bit, not the end user bit.
It cost me $625 (or possibly less) one-time when I first got it.
That was with the waivers in force. It will soon cost a one-time US $1250. We could argue till the cows come home about what proportion of the population would consider that "prohibitive" but I'm guessing that even in the USA that's a heck of an entry fee, and that the vast majority of non-corporate end users will not be willing to pay it. Which is the actual point, rather than quibbling about the precise price.
I bet you spend more than [US$100] at Starbucks each year.
You lose! The nearest Starbucks to me[1] is approximately 700km distant :-) Please transfer AUS$4175 immediately, bank details under separate cover :-) Regards, K. [1] According to the online Starbucks store locator... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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:
On Thu, 2010-10-21 at 18:48 -0700, Owen DeLong wrote:
Uh, no... You're misreading it.
Yes - I read the ISP bit, not the end user bit.
It cost me $625 (or possibly less) one-time when I first got it.
That was with the waivers in force. It will soon cost a one-time US $1250. We could argue till the cows come home about what proportion of the population would consider that "prohibitive" but I'm guessing that even in the USA that's a heck of an entry fee, and that the vast majority of non-corporate end users will not be willing to pay it. Which is the actual point, rather than quibbling about the precise price.
That seems to be quite an argument against trying to get IPv6 GUA, or am I missing something? In my experience companies are often too cheap to even buy things like a software license, if the free product suffices. Often ignoring the hidden costs of dealing with a restricted free copy. So I'd say, that in my case, providing an internal IPv6 network for testing purposes, does not warrant getting GUAs. Even if it technically speaking is a "good thing", it's not likely to happen. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
On Nov 1, 2010, at 4:12 PM, Randy Bush wrote:
It cost me $625 (or possibly less) one-time when I first got it.
one time? truely one time? no other fees or strings?
randy
Yes, one time. Truly one time. No other fees. The $100/year I was already paying for my other resources covers it, so, no increase in annual fees. If you're starting from scratch, then there is a $100/year fee. As to strings, well, it's subject to policy like any other RIR issued addresses. I don't see that as a problem or really as a string, but, some might. Owen
David Conrad <drc@virtualized.org> writes:
Owen,
On Nov 1, 2010, at 4:59 PM, Owen DeLong wrote:
Yes, one time.
Truly one time.
No other fees.
Let's say you returned all your IPv4 address space.
What would happen if you then stopped paying?
He'd lose his ASN. What do I win? -r
On Nov 2, 2010, at 6:40 AM, Robert E. Seastrom wrote:
David Conrad <drc@virtualized.org> writes:
Owen,
On Nov 1, 2010, at 4:59 PM, Owen DeLong wrote:
Yes, one time.
Truly one time.
No other fees.
Let's say you returned all your IPv4 address space.
What would happen if you then stopped paying?
He'd lose his ASN. What do I win?
And not his IPv6 space? ARIN has moved to a "Once and For All" (aka "Cemetery Plot") pricing model for IPv6? Regards, -drc
On Mon, 2010-11-01 at 15:26 -0700, Jeroen van Aart wrote:
Karl Auer wrote:
That was with the waivers in force. It will soon cost a one-time US $1250. We could argue till the cows come home about what proportion of the population would consider that "prohibitive" but I'm guessing that even in the USA that's a heck of an entry fee, and that the vast majority of non-corporate end users will not be willing to pay it. Which is the actual point, rather than quibbling about the precise price.
That seems to be quite an argument against trying to get IPv6 GUA, or am I missing something?
No you're not missing anything. And this is a good, simple policy tool to keep the numbers of PI routes down. At least from the US. But similar fees seem to be in force at other RIRs like APNIC and RIPE. 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 Nov 1, 2010, at 4:19 PM, Karl Auer wrote:
On Mon, 2010-11-01 at 15:26 -0700, Jeroen van Aart wrote:
Karl Auer wrote:
That was with the waivers in force. It will soon cost a one-time US $1250. We could argue till the cows come home about what proportion of the population would consider that "prohibitive" but I'm guessing that even in the USA that's a heck of an entry fee, and that the vast majority of non-corporate end users will not be willing to pay it. Which is the actual point, rather than quibbling about the precise price.
That seems to be quite an argument against trying to get IPv6 GUA, or am I missing something?
Interesting... I guess controlling your own internet fate hasn't been a priority for the companies where you've worked. Not one of my clients or the companies I have worked for has even given a second thought to approving the cost of address space once I presented the tradeoffs of PA vs. PI. Depending on your meaning of non-corporate (e.g. non-business or just not large business since this is unclear from your meaning and corporations come in all sizes including a single person), this may or may not be true.
No you're not missing anything. And this is a good, simple policy tool to keep the numbers of PI routes down. At least from the US. But similar fees seem to be in force at other RIRs like APNIC and RIPE.
The fees are not there to keep routes down. The fees are there to help the RIR recover the cost of maintaining the RIR and processing the application. Frankly, if we simplified the approval process we could probably lower the cost of reviewing these applications and thus lower the fees. Owen
On Mon, 2010-11-01 at 20:03 -0700, Owen DeLong wrote:
Interesting... I guess controlling your own internet fate hasn't been a priority for the companies where you've worked. Not one of my clients or the companies I have worked for has even given a second thought to approving the cost of address space once I presented the tradeoffs of PA vs. PI.
You know how you complained when someone moved the discourse to residential when you mentioned enterprise and to enterprise when you mentioned residential? At least I think it was you. Well, you're doing it now :-) It's not a one size fits all situation. There is no problem with some people (typically "enterprise" types) being concerned about PI vs PA and going one way, and someone else (typically "residential" types) not being concerned about it and going another way. It's not really about size, it's about the needs of the particular organisation (with residential users just being very small organisations).
The fees are not there to keep routes down. The fees are there to help the RIR recover the cost of maintaining the RIR and processing the application.
Whatever; a useful side effect of the fees is that they provide a barrier to the uptake of PI by smaller organisations. Only those who can justify the cost of PI (in whatever terms that make sense to them) will go that way, and that will probably not be the many millions of residential users, who will be quite happy to use PA. 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 Nov 1, 2010, at 5:23 PM, Karl Auer wrote:
It's not a one size fits all situation.
Right. There are folks who are more than happy (in fact demand) to pay the RIRs for PI space and pay their ISPs to get that space routed. There are (probably) folks who are perfectly happy with PA and accept that they'll need to renumber all their devices and change all their configs where there are IPv6 literals. But my impression is that there are more people who want to minimize the costs associated with PI _and_ with renumbering, hence PA+ULA+NAT66. As far as I can tell, the cost/benefit calculations here isn't significantly different from what it was with IPv4 ("96 bits, no magic").
Whatever; a useful side effect of the fees is that they provide a barrier to the uptake of PI by smaller organisations.
Are those fees that much more of a deterrent than what ISPs will charge to route the PI space?
Only those who can justify the cost of PI (in whatever terms that make sense to them) will go that way, and that will probably not be the many millions of residential users, who will be quite happy to use PA.
My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers... Regards, -drc
My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers...
That claim seems to be unsupported by current experience. Please elaborate. Nathan
On Nov 1, 2010, at 6:42 PM, Nathan Eisenberg wrote:
My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers... That claim seems to be unsupported by current experience. Please elaborate.
Currently, most residential customers have PA+NATv4, where the CPE provides the public IPv4 address to the NATv4 box (which might be the same box as the CPE) via DHCP (or PPPoE). As such, all internal devices are shielded from all renumbering events. In a NATless PA world, all devices will need to be renumbered on a change of provider. While in theory, address lifetimes and multiple addresses should reduce the impact renumbering might have, I will admit some skepticism that renumbering IPv6 providers will be sufficiently transparent as customers are used to with IPv4 PA+NATv4. Perhaps I am wrong. Regards, -drc
On Tue, Nov 2, 2010 at 00:58, David Conrad <drc@virtualized.org> wrote:
On Nov 1, 2010, at 6:42 PM, Nathan Eisenberg wrote:
My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers... That claim seems to be unsupported by current experience. Please elaborate.
Currently, most residential customers have PA+NATv4, where the CPE provides the public IPv4 address to the NATv4 box (which might be the same box as the CPE) via DHCP (or PPPoE). As such, all internal devices are shielded from all renumbering events. In a NATless PA world, all devices will need to be renumbered on a change of provider. While in theory, address lifetimes and multiple addresses should reduce the impact renumbering might have, I will admit some skepticism that renumbering IPv6 providers will be sufficiently transparent as customers are used to with IPv4 PA+NATv4. Perhaps I am wrong.
No "average residential user" should ever see or configure an IPv6 address; all the vendors are using zeroconf etc. to avoid it at all costs. If it was all autoconfigured in the first place, there's no reason autoconfiguration shouldn't be able to renumber it. -Ben
On Tue, 2 Nov 2010 01:24:45 -0400 Ben Jencks <ben@bjencks.net> wrote:
On Tue, Nov 2, 2010 at 00:58, David Conrad <drc@virtualized.org> wrote:
On Nov 1, 2010, at 6:42 PM, Nathan Eisenberg wrote:
My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers... That claim seems to be unsupported by current experience. Please elaborate.
Currently, most residential customers have PA+NATv4, where the CPE provides the public IPv4 address to the NATv4 box (which might be the same box as the CPE) via DHCP (or PPPoE). As such, all internal devices are shielded from all renumbering events. In a NATless PA world, all devices will need to be renumbered on a change of provider. While in theory, address lifetimes and multiple addresses should reduce the impact renumbering might have, I will admit some skepticism that renumbering IPv6 providers will be sufficiently transparent as customers are used to with IPv4 PA+NATv4. Perhaps I am wrong.
No "average residential user" should ever see or configure an IPv6 address; all the vendors are using zeroconf etc. to avoid it at all costs. If it was all autoconfigured in the first place, there's no reason autoconfiguration shouldn't be able to renumber it.
+1
-Ben
On 11/1/10 9:42 PM, Nathan Eisenberg wrote:
My guess is that the millions of residential users will be less and less enthused with (pure) PA each time they change service providers...
Hi, almost everytime I open my laptop it gets a different ip address, sometimes I'm home and it gets that same ip it had the last time I was there. once in a very great while my home gateway changes it's ip address, since it does dynamic dns updates I have no trouble finding it, and in fact the network storage perhipheral that I have thinks nothing of using upnp to punch a hole in the gateway all on it's own... These are mostly low touch and either zero or very little configuration required. The consumer isn't got to tollerate systems which don't work automatically or very nearly so, which means among other things having an ip address change or even have your home gateway(s) help the downstream devices renumber themselves.
That claim seems to be unsupported by current experience. Please elaborate.
It's not only not supported by current experience it seems really unlikely to be supported by future experience, e.g. many device you have are mobile, and a connected to more than one network at a time they still may be gatewaying for downstream devices. if somewhere along the line you solved this for the mobility case it is going to work for networks which are more stable.
Nathan
On 10/20/2010 9:30 PM, Graham Beneke wrote:
Someone insisted to me yesterday the RFC1918-like address space was the only way to provide a 'friendly' place for people to start their journey in playing with IPv6. I think that the idea of real routable IPs on a lab network daunts many people.
I once worked at a place that really *really* didn't want "real routable IPs" on their giant disk-protocols-over-IP network and wanted to start playing with IPv6 in those labs. What they wanted address space they knew no other company they ever merged with might be using, but which also would never, ever be on the public IPv6 Internet. At the time, there was no solution but to misuse ULA space. They're probably still doing just that.
I've been down the road with ULA a few years back and I have to agree with Owen - rather just do it on GUA.
I was adding IPv6 to a fairly large experimental network and started using ULA. The local NREN then invited me to peer with them but I couldn't announce my ULA to them. They are running a 'public Internet' network and have a backbone that will just filter them.
I think that the biggest thing that trips people up is that they think that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting your own GUA from an RIR isn't tough - rather just do it.
It isn't tough, but it isn't free either. I have an experimental network that I'd love to run IPv6 with my own GUAs on (for the aforementioned sorts of reasons, like what happens when you want to interconnect with others), but it wouldn't be connected (for quite some time) to the public IPv6 Internet and there are *zero* funds available for the fees for PI space. It just isn't like 1992 (or even 1994) was for IPv4. Matthew Kaufman
On Oct 20, 2010, at 9:30 PM, Graham Beneke wrote:
On 21/10/2010 02:41, Owen DeLong wrote:
On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote:
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.
Someone insisted to me yesterday the RFC1918-like address space was the only way to provide a 'friendly' place for people to start their journey in playing with IPv6. I think that the idea of real routable IPs on a lab network daunts many people.
They should get less daunted. You can always put a firewall with a deny all policy or an air-gap in front of it if you don't want to talk to the internet.
I've been down the road with ULA a few years back and I have to agree with Owen - rather just do it on GUA.
Thanks.
I was adding IPv6 to a fairly large experimental network and started using ULA. The local NREN then invited me to peer with them but I couldn't announce my ULA to them. They are running a 'public Internet' network and have a backbone that will just filter them.
Uh huh. Now, imagine if, instead of a small experimental deployment, you had a fortune 500 enterprise and instead of an NREN it was an ISP for whom you were a major customer... Any bets on which side of that equation gets the policy change?
I think that the biggest thing that trips people up is that they think that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting your own GUA from an RIR isn't tough - rather just do it.
I completely agree. Owen
On Wed, 20 Oct 2010 19:39:19 -0400 Deepak Jain <deepak@ai.net> wrote:
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.
On Oct 20, 2010, at 5:29 PM, Mark Smith wrote:
On Wed, 20 Oct 2010 19:39:19 -0400 Deepak Jain <deepak@ai.net> wrote:
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. 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
Hi Owen, On Wed, 20 Oct 2010 17:51:11 -0700 Owen DeLong <owen@delong.com> wrote:
On Oct 20, 2010, at 5:29 PM, Mark Smith wrote:
On Wed, 20 Oct 2010 19:39:19 -0400 Deepak Jain <deepak@ai.net> wrote:
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.
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.
_IF_ they implement as intended and as documented. As you've noted there's a lot of confusion and a lot of people not reading the documents, latching onto ULA and deciding ti's good. It's not a big leap for some company to do a huge ULA deployment saying "this will never connect to the intarweb thingy" and 5-10 years later not want to redeploy all their addressing, so, they start throwing money at getting providers to do what they shouldn't instead of readdressing their networks.
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.
One would hope, but, I bet laziness and misunderstanding trumps reason and adherence to RFCs over the long term. Since ULA won't get hard-coded into routers as unroutable (it can't), when people do bad stuff with it, it will work and since it works, they won't go read the documentation explaining that what works is a bad idea.
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.
No... The way it will work is that use of ULA as pseudo-GUA will spread slowly like cancer through the network. When provider A and provider B both have customers throwing lots of money at them to route their ULA, provider A and provider B will swallow hard and agree to exchange those routes in both directions. I wish I had your confidence in people doing the right thing, but, there are enough examples of RFC-1918 space in the GRT that I simply can't share your belief that it won't happen with ULA which doesn't have the reliability problems that RFC-1918 had. Owen
In message <E22A56B3-68F1-4A75-A091-E416800C485B@delong.com>, Owen DeLong write s:
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.
_IF_ they implement as intended and as documented. As you've noted there's a lot of confusion and a lot of people not reading the documents, latching onto ULA and deciding ti's good.
It's not a big leap for some company to do a huge ULA deployment saying "this will never connect to the intarweb thingy" and 5-10 years later not want to redeploy all their addressing, so, they start throwing money at getting providers to do what they shouldn't instead of readdressing their networks.
IPv4 think. You don't re-address you add a new address to every node. IPv6 is designed for multiple 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.
One would hope, but, I bet laziness and misunderstanding trumps reason and adherence to RFCs over the long term. Since ULA won't get hard-coded into routers as unroutable (it can't),
Actually it can be. You just need a easy switch to turn it off. The router can even work itself out many times. Configure multiple interfaces from the same ULA /48 and you pass traffic for the /48 between those interfaces. You also pass routes for that /48 via those interfaces.
when people do bad stuff with it, it will work and since it works, they won't go read the documentation explaining that what works is a bad idea.
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.
No... The way it will work is that use of ULA as pseudo-GUA will spread slowly like cancer through the network.
When provider A and provider B both have customers throwing lots of money at them to route their ULA, provider A and provider B will swallow hard and agree to exchange those routes in both directions.
I wish I had your confidence in people doing the right thing, but, there are enough examples of RFC-1918 space in the GRT that I simply can't share your belief that it won't happen with ULA which doesn't have the reliability problems that RFC-1918 had.
Owen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Sent: Thursday, October 21, 2010 3:16 PM To: Owen DeLong Cc: NANOG list Subject: Re: Re: IPv6 fc00::/7 - Unique local addresses
IPv4 think.
You don't re-address you add a new address to every node. IPv6 is designed for multiple addresses.
How does your application on the host decide which address to use when sourcing an outbound connection if you have two different subnets that are globally routable?
On 10/21/2010 5:56 PM, George Bonser wrote:
How does your application on the host decide which address to use when sourcing an outbound connection if you have two different subnets that are globally routable?
Many systems generally will go with the closest source address bitwise to the destination address. Not perfect, but works. This assumes that the source addresses are equal on other metrics. Jack
In message <5A6D953473350C4B9995546AFE9939EE0B14C41E@RWC-EX1.corp.seven.com>, " George Bonser" writes:
Sent: Thursday, October 21, 2010 3:16 PM To: Owen DeLong Cc: NANOG list Subject: Re: Re: IPv6 fc00::/7 - Unique local addresses =20 IPv4 think. =20 You don't re-address you add a new address to every node. IPv6 is designed for multiple addresses. =20
How does your application on the host decide which address to use when sourcing an outbound connection if you have two different subnets that are globally routable?
But ULAs aren't globally routable. ULA addresses are easy to identify and guess what IPv6 stacks know how to select different source address depending apon the destination address. They also know how to order the addresses returned to the application such that reachable ULA's are returned first and non-reachable ULAs are returned last. You can do the same thing with a RIR assigned prefix for internal communication but it requires more explict configuration. With ULA's the IPv6 stack can auto configure itself as you have a well known identifier. Any node that supports RFC3484 (February 2003) can do this for you though you may need to override the defaults. If your OS doesn't yet support it complain. The ability to set this site wide is also coming. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Oct 21, 2010, at 3:15 PM, Mark Andrews wrote:
In message <E22A56B3-68F1-4A75-A091-E416800C485B@delong.com>, Owen DeLong write s:
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.
_IF_ they implement as intended and as documented. As you've noted there's a lot of confusion and a lot of people not reading the documents, latching onto ULA and deciding ti's good.
It's not a big leap for some company to do a huge ULA deployment saying "this will never connect to the intarweb thingy" and 5-10 years later not want to redeploy all their addressing, so, they start throwing money at getting providers to do what they shouldn't instead of readdressing their networks.
IPv4 think.
You don't re-address you add a new address to every node. IPv6 is designed for multiple addresses.
That's a form of re-addressing. It's not removing the old addresses, but, it is a major undertaking just the same in a large deployment.
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.
One would hope, but, I bet laziness and misunderstanding trumps reason and adherence to RFCs over the long term. Since ULA won't get hard-coded into routers as unroutable (it can't),
Actually it can be. You just need a easy switch to turn it off. The router can even work itself out many times. Configure multiple interfaces from the same ULA /48 and you pass traffic for the /48 between those interfaces. You also pass routes for that /48 via those interfaces.
If you have an easy switch to turn it off, it will get used, thus meaning that it isn't hard coded, it's just default.
Owen
In message <4BC01459-B53A-4B2C-B75B-47D89550DFC5@delong.com>, Owen DeLong write s:
On Oct 21, 2010, at 3:15 PM, Mark Andrews wrote:
=20 Which is part one of the three things that have to happen to make = ULA really bad for the internet. =20 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. =20 =20 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. =20 _IF_ they implement as intended and as documented. As you've noted there's a lot of confusion and a lot of people not reading the documents, latching onto ULA and deciding ti's good. =20 It's not a big leap for some company to do a huge ULA deployment saying "this will never connect to the intarweb thingy" and 5-10 = years later not want to redeploy all their addressing, so, they start =
=20 In message <E22A56B3-68F1-4A75-A091-E416800C485B@delong.com>, Owen = DeLong write s: throwing
money at getting providers to do what they shouldn't instead of readdressing their networks. =20 IPv4 think. =20 You don't re-address you add a new address to every node. IPv6 is designed for multiple addresses. =20 That's a form of re-addressing. It's not removing the old addresses, = but, it is a major undertaking just the same in a large deployment.
I don't see any major difference in the amount of work required to go from disconnected ULA to ULA + PA/PI or ULA + NAT compared to disconnected PI to connected PI. Whether the machines have one or two address is inconsequential in the grand scheme of things.
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. =20 One would hope, but, I bet laziness and misunderstanding trumps reason and adherence to RFCs over the long term. Since ULA won't get hard-coded into routers as unroutable (it can't), =20 Actually it can be. You just need a easy switch to turn it off. The router can even work itself out many times. Configure multiple = interfaces from the same ULA /48 and you pass traffic for the /48 between those interfaces. You also pass routes for that /48 via those interfaces. =20 If you have an easy switch to turn it off, it will get used, thus = meaning that it isn't hard coded, it's just default.
On by default will create a effective deterrent.
=20 Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Oct 21, 2010, at 8:25 PM, Mark Andrews wrote:
In message <4BC01459-B53A-4B2C-B75B-47D89550DFC5@delong.com>, Owen DeLong write s:
On Oct 21, 2010, at 3:15 PM, Mark Andrews wrote:
> =20 Which is part one of the three things that have to happen to make = ULA really bad for the internet. =20 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. =20 =20 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. =20 _IF_ they implement as intended and as documented. As you've noted there's a lot of confusion and a lot of people not reading the documents, latching onto ULA and deciding ti's good. =20 It's not a big leap for some company to do a huge ULA deployment saying "this will never connect to the intarweb thingy" and 5-10 = years later not want to redeploy all their addressing, so, they start =
=20 In message <E22A56B3-68F1-4A75-A091-E416800C485B@delong.com>, Owen = DeLong write s: throwing
money at getting providers to do what they shouldn't instead of readdressing their networks. =20 IPv4 think. =20 You don't re-address you add a new address to every node. IPv6 is designed for multiple addresses. =20 That's a form of re-addressing. It's not removing the old addresses, = but, it is a major undertaking just the same in a large deployment.
I don't see any major difference in the amount of work required to go from disconnected ULA to ULA + PA/PI or ULA + NAT compared to disconnected PI to connected PI. Whether the machines have one or two address is inconsequential in the grand scheme of things.
If it's all SLAAC, you're right. Most people have some servers and some other machines that get static addresses. In those cases, those machines have to be touched to facilitate the transition if you start with ULA. If you start with GUA, then, it's just a matter of changing the firewall policies and the router filters, and, possibly some routes.
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. =20 One would hope, but, I bet laziness and misunderstanding trumps reason and adherence to RFCs over the long term. Since ULA won't get hard-coded into routers as unroutable (it can't), =20 Actually it can be. You just need a easy switch to turn it off. The router can even work itself out many times. Configure multiple = interfaces from the same ULA /48 and you pass traffic for the /48 between those interfaces. You also pass routes for that /48 via those interfaces. =20 If you have an easy switch to turn it off, it will get used, thus = meaning that it isn't hard coded, it's just default.
On by default will create a effective deterrent.
We can agree to disagree about that. However, there's enough code out there already that isn't on by default that I think that ship has sailed. Owen
In message <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com>, Owen DeLong write s:
On Oct 20, 2010, at 5:29 PM, Mark Smith wrote:
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 =
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 =
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
On Wed, 20 Oct 2010 19:39:19 -0400 Deepak Jain <deepak@ai.net> wrote: =20 prefix 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 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.
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 =3D GUA without policy =3D 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10/20/2010 5:51 PM, Owen DeLong wrote:
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
On 21/10/2010 03:49, Matthew Kaufman wrote:
On 10/20/2010 5:51 PM, Owen DeLong wrote:
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?
I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN.
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?
I've seen this too. Once again small providers who pretty quickly get caught out by collisions. The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess. -- Graham Beneke
On Thu, Oct 21, 2010, Graham Beneke wrote:
I've seen this too. Once again small providers who pretty quickly get caught out by collisions.
The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess.
You assume that people simply select ULA prefixes randomly and don't start doing linear allocations from the beginning of the ULA range. Adrian
On 10/20/10 9:44 PM, Adrian Chadd wrote:
On Thu, Oct 21, 2010, Graham Beneke wrote:
I've seen this too. Once again small providers who pretty quickly get caught out by collisions.
The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess.
having merged datacenters with multiple overlapping v4 prefixes I'll just observe that this is inevitable in v4, you can take steps that make it less likely to impact you in v6.
You assume that people simply select ULA prefixes randomly and don't start doing linear allocations from the beginning of the ULA range.
actually I assume they're going to just assign the whole botton half to themselves like they do with 10/8 since using fc01::/8 is clearly more work. If you do assign randomly the probability of someone deliberately assigning the same /48 for use in their network seems pretty low, you're a heck of a lot better off than with rfc 1918.
Adrian
On Thu, 21 Oct 2010 12:44:40 +0800 Adrian Chadd <adrian@creative.net.au> wrote:
On Thu, Oct 21, 2010, Graham Beneke wrote:
I've seen this too. Once again small providers who pretty quickly get caught out by collisions.
The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess.
You assume that people simply select ULA prefixes randomly and don't start doing linear allocations from the beginning of the ULA range.
Any time there is a parameter that can be configured, there is a possibility that people will misconfigure it. The only way to completely prevent that being a possibility is to eliminate the parameter. We can prevent people from getting addressing wrong by not putting addresses in the IP header - but I, and I suspect most people, would prefer their computers not to be a dumb terminal connected to a mainframe. Or we can make the network robust against misconfiguration, and put in place things like BCP38. This is all starting to sound a bit like Chicken Little. Regards, Mark.
On Thu, 21 Oct 2010 06:38:33 +0200 Graham Beneke <graham@apolix.co.za> wrote:
On 21/10/2010 03:49, Matthew Kaufman wrote:
On 10/20/2010 5:51 PM, Owen DeLong wrote:
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?
I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN.
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?
I've seen this too. Once again small providers who pretty quickly get caught out by collisions.
The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess.
I don't think there is a difference. The very small providers are the ones who make the stupid mistakes, it's the larger ones that do the right thing because it is in their operational interests. Operational competence, and the resulting increased reliability, is one of the attributes customers of ISPs value highly. If any of the Tier-1s don't route ULA address space, then it is useless compared to global addresses that *are* routed by *all* the Tier-1s. As the Tier-1s also hire competent networking people, they'll also understand the scaling issues of the ULA address space, and why it shouldn't be globally routed. Competent networking people also exist at the lower tiers as well. If operators just blindly accept and implement what sales people tell them to, then those operators aren't operators. They're mindless drones - and the rest of the people operating the Internet will protect the Internet from them. Darwin eventually gets rid of those operators and the ISP that employ them. Since ULAs could be used as DoS attack sources, they'll also likely be filtered out by most people as per BCP38. Regards, Mark.
On Oct 20, 2010, at 10:07 PM, Mark Smith wrote:
On Thu, 21 Oct 2010 06:38:33 +0200 Graham Beneke <graham@apolix.co.za> wrote:
On 21/10/2010 03:49, Matthew Kaufman wrote:
On 10/20/2010 5:51 PM, Owen DeLong wrote:
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?
I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN.
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?
I've seen this too. Once again small providers who pretty quickly get caught out by collisions.
The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess.
I don't think there is a difference. The very small providers are the ones who make the stupid mistakes, it's the larger ones that do the right thing because it is in their operational interests. Operational competence, and the resulting increased reliability, is one of the attributes customers of ISPs value highly.
If any of the Tier-1s don't route ULA address space, then it is useless compared to global addresses that *are* routed by *all* the Tier-1s. As the Tier-1s also hire competent networking people, they'll also understand the scaling issues of the ULA address space, and why it shouldn't be globally routed. Competent networking people also exist at the lower tiers as well.
Ah, but, since statistically probable Uniqueness is present, I'm betting eventually some combination of Tier-1s will get bought off to route ULA and then the flood gates open. Tier-1s are famous for having their sales and accounting departments override good engineering practices on a somewhat regular basis. With RFC-1918 this couldn't happen because collisions meant it simply wouldn't work. ULA has no such impediment.
If operators just blindly accept and implement what sales people tell them to, then those operators aren't operators. They're mindless drones - and the rest of the people operating the Internet will protect the Internet from them. Darwin eventually gets rid of those operators and the ISP that employ them.
There's a difference between blind acceptance and adherence to a direct overriding order from the guy that signs your paycheck. I'm sure they will attempt to fight the good fight, but, in the end, $$ tend to trump good engineering unless what the $$ want simply can't be made to work.
Since ULAs could be used as DoS attack sources, they'll also likely be filtered out by most people as per BCP38.
Maybe... Given what I've seen with RFC-1918 and other BCP38 violations, I lack your faith. Owen
On Oct 20, 2010, at 9:38 PM, Graham Beneke wrote:
On 21/10/2010 03:49, Matthew Kaufman wrote:
On 10/20/2010 5:51 PM, Owen DeLong wrote:
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?
I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN.
Correct... The only reason it isn't is because of the high chance of collision. Due to virtually guaranteed overlapping address conflicts, it doesn't work with RFC-1918. ULA solves that "problem" by providing probably unique addresses.
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?
I've seen this too. Once again small providers who pretty quickly get caught out by collisions.
The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess.
Exactly. Owen
On Thu, 21 Oct 2010, Graham Beneke wrote:
On 21/10/2010 03:49, Matthew Kaufman wrote:
On 10/20/2010 5:51 PM, Owen DeLong wrote:
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?
I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN.
I know for a fact that an extremely large tier 1 routed RFC1918 address space for an extremely large cable company at one time (and no, I don't mean 2547 or anything like that). I have no idea if this is still occurring, but when this very large cable company needed to use more private addresses they actually would ask the tier 1 for an assignment in order to avoid collision. I don't see the problem with ULA though, sure, someone will route it, but not everyone, just those getting paid to. It's actually the perfect solution to routing table bloat as there is a financial relationship between the parties that announce space and the networks that carry it. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss
On Oct 21, 2010, at 9:34 AM, Brandon Ross wrote:
On Thu, 21 Oct 2010, Graham Beneke wrote:
On 21/10/2010 03:49, Matthew Kaufman wrote:
On 10/20/2010 5:51 PM, Owen DeLong wrote:
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?
I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN.
I know for a fact that an extremely large tier 1 routed RFC1918 address space for an extremely large cable company at one time (and no, I don't mean 2547 or anything like that). I have no idea if this is still occurring, but when this very large cable company needed to use more private addresses they actually would ask the tier 1 for an assignment in order to avoid collision.
I don't see the problem with ULA though, sure, someone will route it, but not everyone, just those getting paid to. It's actually the perfect solution to routing table bloat as there is a financial relationship between the parties that announce space and the networks that carry it.
Only until there are two parties getting paid by two other parties to route it and they agree to exchange those routes without compensation in order to benefit their mutual customers who want to reach each other. From there, the problem mushrooms rapidly. Owen
On Wed, Oct 20, 2010 at 9:49 PM, Matthew Kaufman <matthew@matthew.at> wrote:
On 10/20/2010 5:51 PM, Owen DeLong wrote:
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?
Some designs for the "carrier NATs" that are supposed to tide us over from from v4 depletion through v6 deployment would seem to be an open door for this scenario.
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?
No. There's too much complexity associated with multiple ISPs negotiating private routing policies while VPNs work very well without needing special services from the ISP. Owen has this notion that there's a natural evolutionary path that will bring about some circumstance where two particular ISPs find it advantageous to swap ULA routes. That same driving force would presumably lead those ISPs to interact with a third and so on until the use of ULA addresses on the public Internet was a defacto standard. If there's a credible scenario where two ISPs and the folks paying them would find such a course of action preferable to the myriad other options for solving the given problem, I haven't heard it yet. If such a scenario exists, it's not obvious. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
[subject changes, such a useful way to indicate something different ;) ] On 2010-10-21 02:29, Mark Smith wrote:
On Wed, 20 Oct 2010 19:39:19 -0400 Deepak Jain <deepak@ai.net> wrote: [..]
Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it.
As stated at the bottom of the page: "This page uses the Unique Local Address (RFC4193) Generator by SUZUKI Shinsuke and Holger Zuleger. It uses oui.txt from the IEEE OUI Database file."
Anyway, the SIXXS tool seems pretty slick.
Thanks, but it effectively is just a call to the generator script as mentioned above + a insert into SQL... thus nothing fancy there ;) Thus thanks should go mostly to the above authors for their script that generates the numbers properly (linked from the page of course)
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.
As the page mentions under Notes: "If everybody uses this registry though, the chance for collisions should be near nil." Indeed when somebody opts to not use this "registry", quite a big chance that they do, or use some other "registry", then the system fails. Still this just increases the probability of collisions, nothing else. (no math to prove that though, like in the RFC :)
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.
And then it becomes a fight to who is right, nothing that can be done about that.
There also doesn't seem to be any limiting of the number of prefixes.
Should there be? How would we limit anything?
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 -
Is there a problem that one entity has 7 /48's out of (2**(128-8-48)) possible ones... no I am not going to write out that number or write it out in a percentage ;) [..]
or 458 752 subnets, and http://deticon.net isn't reachable via IPv6
Maybe because ULA is *LOCAL* address space. For that matter, as a great example: you won't find 9.0.0.0/8 easily on the internet either, I can tell you though that it is quite heavily used and completely filled up, so far even that there are a lot more prefixes that that organization uses for other purposes. [..]
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.
You want us to charge for virtual numbers which don't really exist? :) For all entries we have an email address, at the time of registration that email address was tested at least as having a proper configuration. We could always, if we wanted but I don't see why, start spamming people and ask them if their registration data is still correct. If you really think that the list is polluted by some entries then don't hesitate to mail info@sixxs.net and next to all the other things we do we might be able to look into it. There really are enough /48's in that /8 for everybody. At this moment there are 1024 of them in there, I don't even think there is a percentage number for that yet. I don't even think you are able to generate a single ULA that will clash with one of the entries in the list unless you generate a really large amount of them, cause well, that is the whole point of the ULA generation algorithm in the first place. As long though as there are this few entries, I really cannot see the point for this. If you want guaranteed globally unique address space there is a simple way for you to already get this today and actually for the last 10 years: You go to your favorite RIR and you get a prefix. Please remember that a prefix you get from the RIRs does not have a requirement of being announced on the Internet, you can also use it to interconnect between your own local networks. This is also the reason why fc00::/8 will never be used, as it will be exactly the same as what the RIRs are doing today already with 2000::/3. Greets, Jeroen
Is there a problem that one entity has 7 /48's out of (2**(128-8-48)) possible ones... no I am not going to write out that number or write it out in a percentage ;)
Your math is incorrect... It's 2^40, not 2^(128-8-48) 8 fd00::/8 -- preassigned. 40 Randomly generated 16 Locally assigned 64 Host identifieers ---- 128 Of that, only the 40 randomly generated provide ULA prefix uniqueness. Still... 2^40 is ~1 Trillion prefixes. If 7 Billion people all grab 7 prefixes, that's still only 49 Billion prefixes. However, since there's no reclamation at death, and, we're not just talking about people, but, people+orgs+whatever, I can see the potential for the sixxs registry to get harvested and ULA exhausted in less than 50 years with concerted effort. However, running out of ULA is, IMHO, the least of our problems with such a registry and its practices.
[..]
or 458 752 subnets, and http://deticon.net isn't reachable via IPv6
Maybe because ULA is *LOCAL* address space. For that matter, as a great example: you won't find 9.0.0.0/8 easily on the internet either, I can tell you though that it is quite heavily used and completely filled up, so far even that there are a lot more prefixes that that organization uses for other purposes.
He didn't say he couldn't find the prefix on the net. He said he couldn't find the domain name. I believe ibm.com is quite easy to find on the internet.
[..]
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.
You want us to charge for virtual numbers which don't really exist? :)
It is the only (so far) mechanism anyone has identified for being able to reliably confirm continued utilization of resources. If you have some other mechanism, go for it. If not, then you've just created a whole new class of swamp space and I will point you to the legacy address issues surrounding these same problems with IPv4 as an example of why this is a bad idea.
For all entries we have an email address, at the time of registration that email address was tested at least as having a proper configuration. We could always, if we wanted but I don't see why, start spamming people and ask them if their registration data is still correct.
If the domain shown in the record isn't resolvable, it's a pretty good indication that the email address probably won't work, no? Deprecating someones registration just because they don't respond to email is, well, not something people have wanted the RIRs to do, so, likely SIXXS will have similar problems.
If you really think that the list is polluted by some entries then don't hesitate to mail info@sixxs.net and next to all the other things we do we might be able to look into it.
ROFLMAO...
There really are enough /48's in that /8 for everybody. At this moment there are 1024 of them in there, I don't even think there is a percentage number for that yet. I don't even think you are able to
1024 is roughly 1/1,000,000,000th of the space. 40 bits is roughly a trillion.
generate a single ULA that will clash with one of the entries in the list unless you generate a really large amount of them, cause well, that is the whole point of the ULA generation algorithm in the first place.
Yep. And the primary reason that ULA is a much worse idea than RFC-1918.
As long though as there are this few entries, I really cannot see the point for this.
And so they created a new copy of the IPv4 swamp in IPv6 land, because they could, and, because they could not learn the lessons of history and were thus doomed to repeat them.
Please remember that a prefix you get from the RIRs does not have a requirement of being announced on the Internet, you can also use it to interconnect between your own local networks. This is also the reason why fc00::/8 will never be used, as it will be exactly the same as what the RIRs are doing today already with 2000::/3.
Exactly, so, why even have this ULA confusion in fd00::/8 to begin with? Owen
In message <20101021093109.06a50ea2@opy.nosense.org>, Mark Smith writes:
On Wed, 20 Oct 2010 14:48:47 -0700 Jeroen van Aart <jeroen@mompl.net> wrote:
<IPv6 newbie> =20 According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses= =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
Use something like fd00::1234, or incorporate=20 something like the interface's MAC address into the address? It'd make=20 the address quite unreadable though. =20
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.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Oct 20, 2010 at 4:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
<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. 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. -- -Jh
In message <AANLkTikxiibdH-3pggKAGxpU9KY0OyX-GczsQ8AjFomS@mail.gmail.com>, Jame s Hess writes:
On Wed, Oct 20, 2010 at 4:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
<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.
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. -- -Jh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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
On Wed, 20 Oct 2010 19:07:57 -0500 James Hess <mysidia@gmail.com> wrote:
On Wed, Oct 20, 2010 at 4:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
<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.
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. -- -Jh
On 10/20/2010 6:20 PM, Mark Smith wrote:
To make it clear, as it seems to be quite misunderstood, you'd have both ULA and global addressing in your network.
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
On Wed, 20 Oct 2010 18:46:34 -0700 Matthew Kaufman <matthew@matthew.at> wrote:
On 10/20/2010 6:20 PM, Mark Smith wrote:
To make it clear, as it seems to be quite misunderstood, you'd have both ULA and global addressing in your network.
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.
So you speak for everybody? I can do that too. Nobody wants to run NAT anymore either.
On Wed, Oct 20, 2010 at 8:46 PM, Matthew Kaufman <matthew@matthew.at> wrote:
On 10/20/2010 6:20 PM, Mark Smith wrote: 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.
A perfectly valid way to multihome, right? Setup each host with two IP addresses, one in each PA range. Use multiple DNS records, to indicate all the host's pairs of IPs. If an ISP link goes down, all the clients' should automatically try resend the unack'ed packets to the DNS name's other IPs in 10 or 11 seconds, and recover, without having to reconnect, right? right?? [ No :( ] Automatic failover to other multihomed IPs seems to always have been left missing from the TCP protocols, for some reason or another. Probably good reasons, but that multihoming strategy isn't a very good one, for now, due to the disruption of active connections, and bad client programs that won't look for other DNS records, even when trying to establish a new connection. Perhaps one day, there will be a truly reliable transport protocol, and an API that allows a bind() against multiple IPs and a connect() to all a target host's IPs instead of just one, so both hosts can learn of each other's IP addresses that are offered to be used for that connection, then "multiple PA IP addresses" would be a technically viable multi-homing strategy. -- -Jh
On Wed, 20 Oct 2010 21:15:35 -0500 James Hess <mysidia@gmail.com> wrote:
On Wed, Oct 20, 2010 at 8:46 PM, Matthew Kaufman <matthew@matthew.at> wrote:
On 10/20/2010 6:20 PM, Mark Smith wrote: 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.
A perfectly valid way to multihome, right? Setup each host with two IP addresses, one in each PA range. Use multiple DNS records, to indicate all the host's pairs of IPs. If an ISP link goes down, all the clients' should automatically try resend the unack'ed packets to the DNS name's other IPs in 10 or 11 seconds, and recover, without having to reconnect, right? right?? [ No :( ]
Automatic failover to other multihomed IPs seems to always have been left missing from the TCP protocols, for some reason or another.
Probably good reasons, but that multihoming strategy isn't a very good one, for now, due to the disruption of active connections, and bad client programs that won't look for other DNS records, even when trying to establish a new connection.
Perhaps one day, there will be a truly reliable transport protocol, and an API that allows a bind() against multiple IPs and a connect()
* Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs) * "TCP Extensions for Multipath Operation with Multiple Addresses" https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ and "Architectural Guidelines for Multipath TCP Development" https://datatracker.ietf.org/doc/draft-ietf-mptcp-architecture/
to all a target host's IPs instead of just one, so both hosts can learn of each other's IP addresses that are offered to be used for that connection, then "multiple PA IP addresses" would be a technically viable multi-homing strategy.
-- -Jh
On 10/20/2010 7:27 PM, Mark Smith wrote:
* Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs)
"because of NATs" s/b "because certain parties refused to acknowledge that encapsulation of SCTP in UDP would have operational advantages sufficient to outweigh the disadvantages". SCTP only gets you 90% of the way there, but it is a lot closer than today's TCP is. Matthew Kaufman
On Wed, 20 Oct 2010 19:50:06 -0700 Matthew Kaufman <matthew@matthew.at> wrote:
On 10/20/2010 7:27 PM, Mark Smith wrote:
* Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs)
"because of NATs" s/b "because certain parties refused to acknowledge that encapsulation of SCTP in UDP would have operational advantages sufficient to outweigh the disadvantages".
SCTP only gets you 90% of the way there, but it is a lot closer than today's TCP is.
Which is why there is also work going on at the network layer, both on the end-hosts via HIP or Shim6, and in the network, such as LISP. Ultimately, this is a hard problem to solve. There is no easy solution, otherwise it'd already exist, and have existed at least 10 years ago - as that is at least how long people have been working on trying to solve it. As there is no easy and perfect solution, then we need to accept that we're going to have to make trade offs to be able to get closer to solving it. In other words, a better solution, even if it isn't perfect, is better. The question is what trade offs are acceptable to make? We know and have experienced the many drawbacks of NAT, including such things as restricting deployment of new and better transport protocols like SCTP, DCCP, and maybe multipath TCP if the NAT boxes inspect and drop unknown TCP options, and forcing the nature of Internet applications to be client-server, even when a peer-to-peer application communications architecture would be far more reliable, scalable and secure. As NAT ultimately was about conserving address space, and IPv6 solves that problem, it is worth exploring other options that weren't possible with IPv4 and/or IPv4 NAT. Regards, Mark.
* Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs)
I would dearly love to see SCTP take off. There are so many great potential applications for that protocol that it can boggle. Any type of connection between two things that might have several different kinds of data going back and forth at the same time could greatly benefit.
On Wed, 20 Oct 2010 20:12:11 -0700 "George Bonser" <gbonser@seven.com> wrote:
* Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs)
I would dearly love to see SCTP take off. There are so many great potential applications for that protocol that it can boggle. Any type of connection between two things that might have several different kinds of data going back and forth at the same time could greatly benefit.
I agree. One application I'd though of was end-to-end Instant Messaging, where, when you wish to transfer a file to the other participant, a new SCTP stream is created for the file transfer within the existing SCTP connection. Not all that novel, but something that would be much easier to do with SCTP than TCP. Regards, Mark.
-----Original Message----- From: Mark Smith [mailto:nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Wednesday, October 20, 2010 9:41 PM To: George Bonser Cc: nanog@nanog.org Subject: Re: IPv6 fc00::/7 — Unique local addresses
I agree. One application I'd though of was end-to-end Instant Messaging, where, when you wish to transfer a file to the other participant, a new SCTP stream is created for the file transfer within the existing SCTP connection. Not all that novel, but something that would be much easier to do with SCTP than TCP.
The absolute win is the elimination of "head of line" blocking. So if you have a large transfer going, that little short IM or even email notification or whatever gets sent immediately by being multiplexed into the data stream instead of being dumped in at the end of a buffer full of other stuff. By having streams for different sorts of content, it has the potential to conserve considerable resources. Rather than having a separate connection for each type of content, you have only one. Now if they would figure out a good way to load balance SCTP, we would be all set. But the real win is where you have a mix of bulk data streams and interactive small data transfers. The bulk transfer doesn't interfere with the interactive experience. And there are so many other potential applications like maybe persistent VOIP "trunks" between branch offices over a long-lived SCTP connection with each of those "trunks" being a stream within one connection. The applications are potentially killer but nobody has really tapped into that area yet. Heck, multicast hasn't really lived up to its potential, either.
On 10/20/2010 7:15 PM, James Hess wrote:
Perhaps one day, there will be a truly reliable transport protocol, and an API that allows a bind() against multiple IPs and a connect() to all a target host's IPs instead of just one, so both hosts can learn of each other's IP addresses that are offered to be used for that connection, then "multiple PA IP addresses" would be a technically viable multi-homing strategy.
That protocol already exists and is installed on almost every personal computer in the world... but there's alas there's still a lot of TCP out there. By the way, the problems you listed are some, but not all, of the reasons why it isn't really a viable multi-homing strategy... but yours also include some of the reasons why having ULA + globally-routed space both active would be a problem for many applications. Matthew Kaufman
In message <4CBF9B7A.1000500@matthew.at>, Matthew Kaufman writes:
On 10/20/2010 6:20 PM, Mark Smith wrote:
To make it clear, as it seems to be quite misunderstood, you'd have both ULA and global addressing in your network.
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.
Only because there isn't good support for it yet. ULA + PA actually works today. The IP stack can do the address selection without worrying about reachability. The chances of the ULA being unreachable and the PA being reachable between two nodes in the same ULA prefix are negligable. If I'm talking to a ULA address I'll use my ULA address. If I'm talking to a non-ULA address I'll use my PA addresses. PA + PA is a problem because you need to worry about source address selection and that is driven by reachability. You also need to worry about egress points due to source address filtering. etc.
Matthew Kaufman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10/20/2010 7:22 PM, Mark Andrews wrote:
In message<4CBF9B7A.1000500@matthew.at>, Matthew Kaufman writes:
On 10/20/2010 6:20 PM, Mark Smith wrote:
To make it clear, as it seems to be quite misunderstood, you'd have both ULA and global addressing in your network. 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. Only because there isn't good support for it yet. Too bad that support didn't come first, or all the issues with address allocation and routing table size being discussed elsewhere wouldn't be a problem for operators. ULA + PA actually works today. The IP stack can do the address selection without worrying about reachability. The chances of the ULA being unreachable and the PA being reachable between two nodes in the same ULA prefix are negligable. If I'm talking to a ULA address I'll use my ULA address. If I'm talking to a non-ULA address I'll use my PA addresses.
PA + PA is a problem because you need to worry about source address selection and that is driven by reachability. You also need to worry about egress points due to source address filtering. etc. ULA + PA can have the same problems, especially if your ULA is inter-organization ULA, which was one of the cases under discussion.
Matthew Kaufman
In message <4CBFA9BB.9030100@matthew.at>, Matthew Kaufman writes:
ULA + PA can have the same problems, especially if your ULA is inter-organization ULA, which was one of the cases under discussion.
Which still isn't a problem. Presumably you want your inter-organization traffic to use ULA addresses to talk to each other so you setup the address selection rules to do just that. That requires new rules being distributed to all nodes that need to talk to the other site. Presumable DHCPv6 could do this. If there isn't yet a DHCP option to request address selection rules we need to define one. Use a VPN between the organisations so you fate share. If you have a private interconnect then the VPN becomes the backup.
Matthew Kaufman
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, 21 Oct 2010 14:29:11 +1100 Mark Andrews <marka@isc.org> wrote:
In message <4CBFA9BB.9030100@matthew.at>, Matthew Kaufman writes:
ULA + PA can have the same problems, especially if your ULA is inter-organization ULA, which was one of the cases under discussion.
Which still isn't a problem. Presumably you want your inter-organization traffic to use ULA addresses to talk to each other so you setup the address selection rules to do just that. That requires new rules being distributed to all nodes that need to talk to the other site. Presumable DHCPv6 could do this. If there isn't yet a DHCP option to request address selection rules we need to define one.
One is being defined - https://datatracker.ietf.org/doc/draft-fujisaki-6man-addr-select-opt/
Use a VPN between the organisations so you fate share. If you have a private interconnect then the VPN becomes the backup.
Matthew Kaufman
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Oct 20, 2010, at 6:46 PM, Matthew Kaufman wrote:
On 10/20/2010 6:20 PM, Mark Smith wrote:
To make it clear, as it seems to be quite misunderstood, you'd have both ULA and global addressing in your network.
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.
Or PI addresses from an RIR.
Only nobody wants to do that either.
There are lots of good reasons not to want to do that. Owen
On 10/21/2010 12:57 AM, Owen DeLong wrote:
On Oct 20, 2010, at 6:46 PM, Matthew Kaufman wrote:
On 10/20/2010 6:20 PM, Mark Smith wrote:
To make it clear, as it seems to be quite misunderstood, you'd have both ULA and global addressing in your network. 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.
Or PI addresses from an RIR. One set of PI addresses and BGP multihoming shouldn't be necessary (but is). The remaining parts of the protocol stack should (but don't) work just fine if you have two sets of PA addresses. They also should (but don't) work just fine if you have one GUA and one ULA, for many of the same reasons. (There are subtle differences that make this case slightly better in some ways, slightly worse in others)
Only nobody wants to do that either.
There are lots of good reasons not to want to do that. Agreed. That was my point here, and above.
Matthew Kaufman
Mark Smith expunged (nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org):
ULAs should never and are prohibited from appearing in the global route table
The problem with this statement is that everyone thinks their own table isn't the "Global Routing Table." -Steve
Hi Jeroen, On Thu, Oct 21, 2010 at 8:48 AM, Jeroen van Aart <jeroen@mompl.net> wrote:
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.
RFC4193 specifies a suggested algorithm to do it: http://tools.ietf.org/html/rfc4193#section-3.2.2 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.. -- SY, Jen Linkova aka Furry
On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
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.
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
For for all intents and purposes if you're looking for RFC1918 style space in IPv6 you should consider the block FD00::/8 not FC00::/7 as the FC00::/8 space is reserved in ULA for assignment by a central authority (who knows why, but with that much address space nobody really cares). People may throw a fit at this, but as far as I'm concerned FD00::/8 will never leave the edge of our network (we null route ULA space before it can leak out, just like you would with RFC1918 space). So you can pretty much use it has you see fit. If you want to keep your ULA space short there is nothing stopping you from using something like FD00::1 as a valid address. You could embed your ASN into it or some other identifier if you want to avoid conflicts with other non-routed address space which should never enter or leave your network from the outside, but I'm just not seeing the practical application for this. On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
<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
-- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Oct 21, 2010, at 4:33 AM, Ray Soucy wrote:
For for all intents and purposes if you're looking for RFC1918 style space in IPv6 you should consider the block FD00::/8 not FC00::/7 as the FC00::/8 space is reserved in ULA for assignment by a central authority (who knows why, but with that much address space nobody really cares).
People may throw a fit at this, but as far as I'm concerned FD00::/8 will never leave the edge of our network (we null route ULA space before it can leak out, just like you would with RFC1918 space). So you can pretty much use it has you see fit. If you want to keep your ULA space short there is nothing stopping you from using something like FD00::1 as a valid address.
I have no problem with that. My concern is that people will use FD00::/8 space in OTHER ways, and, since it has potential uniqueness if you follow the RFC, it has greater potential for undesired success than RFC-1918.
You could embed your ASN into it or some other identifier if you want to avoid conflicts with other non-routed address space which should never enter or leave your network from the outside, but I'm just not seeing the practical application for this.
That only avoids conflicts if everyone within the networks to which you may communicate uses the same system of uniqueness. Think beyond today to the future possibility of M&A of other companies also using ULA, etc. Owen
On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
<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
-- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
I guess my point is that as soon as you introduced the human element into ULA with no accountability, it became a lost cause. People can't be trusted to respect the RFC once they know it's non-routed address space, and I suspect most won't. Just like countless vendors still use 1.1.1.1 as a baked-in management address even though there was never a time when that was allowed. It was a nice idea, but as soon as you let people "choose" the "random" number, well... there you go. At least if you stay within the FD space we have a chance at using FC correctly. On Thu, Oct 21, 2010 at 7:47 AM, Owen DeLong <owen@delong.com> wrote:
On Oct 21, 2010, at 4:33 AM, Ray Soucy wrote:
For for all intents and purposes if you're looking for RFC1918 style space in IPv6 you should consider the block FD00::/8 not FC00::/7 as the FC00::/8 space is reserved in ULA for assignment by a central authority (who knows why, but with that much address space nobody really cares).
People may throw a fit at this, but as far as I'm concerned FD00::/8 will never leave the edge of our network (we null route ULA space before it can leak out, just like you would with RFC1918 space). So you can pretty much use it has you see fit. If you want to keep your ULA space short there is nothing stopping you from using something like FD00::1 as a valid address.
I have no problem with that. My concern is that people will use FD00::/8 space in OTHER ways, and, since it has potential uniqueness if you follow the RFC, it has greater potential for undesired success than RFC-1918.
You could embed your ASN into it or some other identifier if you want to avoid conflicts with other non-routed address space which should never enter or leave your network from the outside, but I'm just not seeing the practical application for this.
That only avoids conflicts if everyone within the networks to which you may communicate uses the same system of uniqueness. Think beyond today to the future possibility of M&A of other companies also using ULA, etc.
Owen
On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
<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
-- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On 2010-10-21 13:33, Ray Soucy wrote: [..]
People may throw a fit at this, but as far as I'm concerned FD00::/8 will never leave the edge of our network (we null route ULA space before it can leak out, just like you would with RFC1918 space). So you can pretty much use it has you see fit. If you want to keep your ULA space short there is nothing stopping you from using something like FD00::1 as a valid address.
And then your company gets bought and you need to merge networks, that is: renumber as they picked the same prefix. There is nothing wrong with RFC1918 per se, the big problem with it is that everybody else uses the same prefix, thus when you need to merge two networks you have collisions. I at one time also though that 'merging networks' and 'renumbering' is easy, till I heard stories from folks who where doing that for really large networks, who basically told that they where introducing 7+ layers of NAT to solve that issue, as renumbering is simply not doable if you have a global organization and if you are merging things like banks, for some magic reason they want to be able to talk to eachother. That is why there is ULA: low chance of collisions if one wants to stay in the RFC1918 mindset. And if you want a guarantee of no collisions: go to your favorite RIR and get a prefix from them. Greets, Jeroen
That's assuming ULA would be the primary addressing scheme used. If that became the norm, I agree, the extra uniqueness would be desirable, perhaps to the point that you should be asking an authority for FC00::/8 space to be assigned. But then why wouldn't you just ask for a GUA at that point. You could still randomly get "0", and if you don't think people will keep cycling through random numbers until they get something pretty you're underestimating human will to control everything ;-) I see ULA falling into the role of things like embedded device management and sandbox networks, more than production, but who knows what will become "the way" to engineer the IPv6 network of the next decade. We've only applied ULA to things like web-based network registration and device management for devices that should never be accessed from off the network (but even there, we've been more in the mindset of using GUA with ACLs or null routes, etc to restrict access). It's really more of a utility address IMHO. On Thu, Oct 21, 2010 at 7:47 AM, Jeroen Massar <jeroen@unfix.org> wrote:
On 2010-10-21 13:33, Ray Soucy wrote: [..]
People may throw a fit at this, but as far as I'm concerned FD00::/8 will never leave the edge of our network (we null route ULA space before it can leak out, just like you would with RFC1918 space). So you can pretty much use it has you see fit. If you want to keep your ULA space short there is nothing stopping you from using something like FD00::1 as a valid address.
And then your company gets bought and you need to merge networks, that is: renumber as they picked the same prefix.
There is nothing wrong with RFC1918 per se, the big problem with it is that everybody else uses the same prefix, thus when you need to merge two networks you have collisions.
I at one time also though that 'merging networks' and 'renumbering' is easy, till I heard stories from folks who where doing that for really large networks, who basically told that they where introducing 7+ layers of NAT to solve that issue, as renumbering is simply not doable if you have a global organization and if you are merging things like banks, for some magic reason they want to be able to talk to eachother.
That is why there is ULA: low chance of collisions if one wants to stay in the RFC1918 mindset.
And if you want a guarantee of no collisions: go to your favorite RIR and get a prefix from them.
Greets, Jeroen
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Thu, Oct 21, 2010 at 8:14 AM, Ray Soucy <rps@maine.edu> wrote:
That's assuming ULA would be the primary addressing scheme used. If that became the norm, I agree, the extra uniqueness would be desirable, perhaps to the point that you should be asking an authority for FC00::/8 space to be assigned. But then why wouldn't you just ask for a GUA at that point.
Because you might want space that doesn't route on the Internet so that if your routes accidentally leak external folks still can't reach you? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 10/21/10 6:02 AM, William Herrin wrote:
On Thu, Oct 21, 2010 at 8:14 AM, Ray Soucy <rps@maine.edu> wrote:
That's assuming ULA would be the primary addressing scheme used. If that became the norm, I agree, the extra uniqueness would be desirable, perhaps to the point that you should be asking an authority for FC00::/8 space to be assigned. But then why wouldn't you just ask for a GUA at that point.
Because you might want space that doesn't route on the Internet so that if your routes accidentally leak external folks still can't reach you?
Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far.
Regards, Bill Herrin
On 10/21/2010 5:27 PM, Joel Jaeggli wrote:
Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far.
This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone. I personally could understand the fear of wondering if your stateful firewall is properly working and doing it's job and how a simple mistake could have disastrous effects that NAT systems usually don't have. ULA w/ NAT very well may become the norm. Jack
Ray said: ".. But then why wouldn't you just ask for a GUA at that point." What's the cost for a /48 GUA from ARIN these days? Why pay for something that you're not going to "use"? I agree with you but as long as the RIRs charge for integers people will make up their own if they can find a way. If a small shop guy is looking at ether paying for GUA space or affording a more expensive switch that will do SNMP, he's going to get the switch. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
On Oct 21, 2010, at 3:52 PM, Joe Hamelin wrote:
Ray said: ".. But then why wouldn't you just ask for a GUA at that point."
What's the cost for a /48 GUA from ARIN these days? Why pay for something that you're not going to "use"?
$1250 initial and $100/year thereafter. If you have any other end-user resources, it's part of the same $100/year you're already paying, so, it might be effectively free after the initial payment. Assuming you use it for 10 years, that amortizes out to $125/year. I don't know if there are still discounts on end-user assignments or not. I know that when I got mine, there was a partial fee waiver program in effect and I paid quite a bit less than $1250.
I agree with you but as long as the RIRs charge for integers people will make up their own if they can find a way.
The RIRs don't charge for integers. The RIRs charge for making globally guaranteed unique registrations of integers and maintaining the associated records in several databases.
If a small shop guy is looking at ether paying for GUA space or affording a more expensive switch that will do SNMP, he's going to get the switch.
There are places to get legitimate GUA space other than RIRs. Some of them are free. Owen (KB6MER, btw)
On Oct 21, 2010, at 3:42 PM, Jack Bates wrote:
On 10/21/2010 5:27 PM, Joel Jaeggli wrote:
Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far.
This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone.
Given the number of times and the distance over which I have seen RFC-1918 routes propagate, this belief is false to begin with, so, removing this false sense of security is not necessarily a bad thing.
I personally could understand the fear of wondering if your stateful firewall is properly working and doing it's job and how a simple mistake could have disastrous effects that NAT systems usually don't have. ULA w/ NAT very well may become the norm.
I tend to doubt that it will... Hopefully there will be enough proper deployments that developers will not eschew improvements that depend on an end-to-end model and there will be real features unavailable to any network that deploys such relatively quickly. The tragedy won't be networks deploying NAT. I'm all for allowing you to buy a gun, ammunition, and aim at your foot or head as you wish. The tragedy will be if enough networks do this to hobble development of truly useful tools that depend on a NAT-free environment to work. Owen
On 10/21/2010 8:38 PM, Owen DeLong wrote:
Given the number of times and the distance over which I have seen RFC-1918 routes propagate, this belief is false to begin with, so, removing this false sense of security is not necessarily a bad thing.
I don't think it's really a propagation issue. As the ISP, I don't actually route RFC-1918 space to my corporate customers, many of which maintain static assignments (no routing protocol). While they can leak packets out, there will never be a return of packets to them. They view this as a feature.The tragedy won't be networks deploying NAT. I'm all for allowing you to buy
a gun, ammunition, and aim at your foot or head as you wish.
The tragedy will be if enough networks do this to hobble development of truly useful tools that depend on a NAT-free environment to work.
I think we should respect the different types of networks, and their administrative goals. I have customers who manage large educational networks. Their engineers have a strong belief in free speech and openness. They have very few filters, don't utilize NAT, and have a reactionary security policy. I also have corporate customers who run extreme nat, don't allow access to social network sites, proxy every communication in and out, and generally don't care that they break 90%+ of the applications that work over the Internet, especially when it's not business related. That being said, I've seen corporate networks change, altering their security policy and the way they do things in order to support applications which they desire. So I wouldn't be surprised if a tight NAT dwelling network suddenly shifted to routing global addressing to meet new applications needs. Jack
On 10/21/10 6:38 PM, Owen DeLong wrote:
On Oct 21, 2010, at 3:42 PM, Jack Bates wrote:
On 10/21/2010 5:27 PM, Joel Jaeggli wrote:
Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far.
This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone.
the rfc 1918 space is being routed inside almost all your adjacent networks, so if their ingress filtering is working as expected, great, but you're only a filter away from leaking.
Given the number of times and the distance over which I have seen RFC-1918 routes propagate, this belief is false to begin with, so, removing this false sense of security is not necessarily a bad thing.
this happened this morning in a pop we have in the far east... packets ended up in atlanta. what's more, the return path was natted.
I personally could understand the fear of wondering if your stateful firewall is properly working and doing it's job and how a simple mistake could have disastrous effects that NAT systems usually don't have. ULA w/ NAT very well may become the norm.
I tend to doubt that it will... Hopefully there will be enough proper deployments that developers will not eschew improvements that depend on an end-to-end model and there will be real features unavailable to any network that deploys such relatively quickly.
The tragedy won't be networks deploying NAT. I'm all for allowing you to buy a gun, ammunition, and aim at your foot or head as you wish.
The tragedy will be if enough networks do this to hobble development of truly useful tools that depend on a NAT-free environment to work.
Owen
On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli <joelja@bogus.com> wrote:
On 10/21/10 6:38 PM, Owen DeLong wrote:
On Oct 21, 2010, at 3:42 PM, Jack Bates wrote:
On 10/21/2010 5:27 PM, Joel Jaeggli wrote:
Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far.
This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone.
the rfc 1918 space is being routed inside almost all your adjacent networks, so if their ingress filtering is working as expected, great, but you're only a filter away from leaking.
A filter away from leaking to -one- of the millions of entities on the internet. Two filters away from leaking to two. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Oct 22, 2010, at 5:25 AM, William Herrin wrote:
On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli <joelja@bogus.com> wrote:
On 10/21/10 6:38 PM, Owen DeLong wrote:
On Oct 21, 2010, at 3:42 PM, Jack Bates wrote:
On 10/21/2010 5:27 PM, Joel Jaeggli wrote:
Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far.
This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone.
the rfc 1918 space is being routed inside almost all your adjacent networks, so if their ingress filtering is working as expected, great, but you're only a filter away from leaking.
A filter away from leaking to -one- of the millions of entities on the internet. Two filters away from leaking to two.
This underestimates the transitive property of leakage. Owen
It's amazing how much of a problem you think leaking of prefixes is... I don't know about you, but I'm pretty strict about what prefixes I allow to be advertised up to me from people we service. I'm not sure having a random private prefix will make much of a difference, since it sounds like fat-fingering a GUA and hijacking a real prefix is just as (or even more) likely. I think the original point was that if you do decide to use ULA, then stay in FD00::/8 and not FC00::/7, there is no way to force people to follow the RFC for something thats non-routed unless we involve vendors. If it sounds like a good idea to include the random 40-bit segment and you can tolerate having non-routed addresses be a little more difficult to remember, then go for it. If you don't follow the RFC and it bites you because of a merger in the future, then it's your own fault and you haven't affected anyone. In the vast majority of environments, even if this space did leak out into the global table and wasn't filtered at all, you would probably still maintain normal operation because your non-routed networks would be a shorter path than anything advertised back down to you. Do we really need 80 messages talking about the dangers of leaking? Perhaps you should see your doctor if its that big of a problem. I think there are some drugs to fix that problem these days... The obvious assumption is that anyone who is providing IPv6 transit is already protecting themselves appropriately, just as they already do in the IP world. On Fri, Oct 22, 2010 at 11:40 AM, Owen DeLong <owen@delong.com> wrote:
On Oct 22, 2010, at 5:25 AM, William Herrin wrote:
On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli <joelja@bogus.com> wrote:
On 10/21/10 6:38 PM, Owen DeLong wrote:
On Oct 21, 2010, at 3:42 PM, Jack Bates wrote:
On 10/21/2010 5:27 PM, Joel Jaeggli wrote:
Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far.
This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone.
the rfc 1918 space is being routed inside almost all your adjacent networks, so if their ingress filtering is working as expected, great, but you're only a filter away from leaking.
A filter away from leaking to -one- of the millions of entities on the internet. Two filters away from leaking to two.
This underestimates the transitive property of leakage.
Owen
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Fri, Oct 22, 2010 at 11:40 AM, Owen DeLong <owen@delong.com> wrote:
On Oct 22, 2010, at 5:25 AM, William Herrin wrote:
On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli <joelja@bogus.com> wrote:
On 10/21/10 6:38 PM, Owen DeLong wrote:
On Oct 21, 2010, at 3:42 PM, Jack Bates wrote:
On 10/21/2010 5:27 PM, Joel Jaeggli wrote:
Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far.
This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone.
the rfc 1918 space is being routed inside almost all your adjacent networks, so if their ingress filtering is working as expected, great, but you're only a filter away from leaking.
A filter away from leaking to -one- of the millions of entities on the internet. Two filters away from leaking to two.
This underestimates the transitive property of leakage.
Owen, Just for grins, let's put some rough math to that assertion. The average percentage of the Internet reached by a ULA or RFC1918 leak will be close to: (1-A)^C A = the probability of any given organization filtering private address announcements and/or private address packets at their borders B = the average width of the Internet in organizations (which should be slightly higher than the width in ASes) So filling in example numbers for the equation, if 50% filter announcements or packets and the Internet is an average of 10 organizations wide then the scope of an address leak is: (1-0.5)^10 = 0.5 ^ 10 = 0.1% of the Internet reached by the leak. In that scenario, the leak is in a very real sense one thousandth as serious as if the leak had been from GUA space which all of the organizations make an effort to carry. And that's assuming that fully half the organizations on the Internet just don't bother trying to filter RFC1918 or ULA use from their public networks. If 75% filter then a whopping 0.0001% of the Internet is reached by the leak. Now, if only 10% filter then your leak reaches a largish 6% of the Internet. That's a worry for someone hoping for some security benefits to not using GUA space but it's far too little to support this bizarre concern that ULA space would somehow supplant GUA space on the public Internet and explode the routers. Of course, I make no claim to know what the correct two constants are in that equation. Perhaps the Internet is thinner. Perhaps nobody filters egress packets despite years of proselytizing. Perhaps the ISP peering interconnectedness corrupts the combinatorics I used to derive the equation in a more substantial fashion than is obvious. Or perhaps your worry about route leakage from non-GUA space really is as overblown as the math suggests. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Oct 22, 2010, at 6:10 PM, William Herrin wrote:
On Fri, Oct 22, 2010 at 11:40 AM, Owen DeLong <owen@delong.com> wrote:
On Oct 22, 2010, at 5:25 AM, William Herrin wrote:
On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli <joelja@bogus.com> wrote:
On 10/21/10 6:38 PM, Owen DeLong wrote:
On Oct 21, 2010, at 3:42 PM, Jack Bates wrote:
On 10/21/2010 5:27 PM, Joel Jaeggli wrote: > > Announce your gua and then blackhole it and monitor your prefix. > you can tell if you're leaking. it's generally pretty hard to > tell if you're leaking rfc 1918 since your advertisement may well > work depending on the filters of your peers but not very far.
This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone.
the rfc 1918 space is being routed inside almost all your adjacent networks, so if their ingress filtering is working as expected, great, but you're only a filter away from leaking.
A filter away from leaking to -one- of the millions of entities on the internet. Two filters away from leaking to two.
This underestimates the transitive property of leakage.
Owen,
Just for grins, let's put some rough math to that assertion. The average percentage of the Internet reached by a ULA or RFC1918 leak will be close to:
(1-A)^C
A = the probability of any given organization filtering private address announcements and/or private address packets at their borders B = the average width of the Internet in organizations (which should be slightly higher than the width in ASes)
I'll note that you don't have a B in your equation and didn't define C, so, I'll presume that C= the average width...
So filling in example numbers for the equation, if 50% filter announcements or packets and the Internet is an average of 10 organizations wide then the scope of an address leak is:
(1-0.5)^10 = 0.5 ^ 10 = 0.1% of the Internet reached by the leak.
I think your estimation of 50% is highly optimistic. I also think you underestimate the diameter of the internet, being much closer to 25 than 10 from what I can see. Filling in more realistic (based on my observations) numbers of 5% and 25, my numbers come out as: (1-0.05)^25 = 0.95 ^ 25 = 0.27 = a little more than 1/4 of the internet.
In that scenario, the leak is in a very real sense one thousandth as serious as if the leak had been from GUA space which all of the organizations make an effort to carry. And that's assuming that fully half the organizations on the Internet just don't bother trying to filter RFC1918 or ULA use from their public networks.
With more realistic numbers, it's closer to 1/4 of the impact of a leak from GUA where you both leaked the route and failed your IP filter and didn't null-route the prefix at your border. (Gee, that seems like three mistakes you need to make for the GUA problem to take effect instead of just the "two" you claimed for ULA).
If 75% filter then a whopping 0.0001% of the Internet is reached by the leak.
ROFLMAO... Yeah, and if Ostriches had 15 times the wing surface area they could probably fly.
Now, if only 10% filter then your leak reaches a largish 6% of the Internet. That's a worry for someone hoping for some security benefits to not using GUA space but it's far too little to support this bizarre concern that ULA space would somehow supplant GUA space on the public Internet and explode the routers.
ULA won't supplant GUA, it will be much more insidious than that. Most people will still use GUA for GUA purposes. However, deliberate routing of ULA will start small and slowly spread over time like a slow-growing cancer. You won't even really detect it until it has metastasized to such an extent that nothing can be done about it. You can't talk about the impact of an accidental leak and compare that to the impact of a deliberate choice to do something. They are two entirely different effects.
Of course, I make no claim to know what the correct two constants are in that equation. Perhaps the Internet is thinner. Perhaps nobody filters egress packets despite years of proselytizing. Perhaps the ISP peering interconnectedness corrupts the combinatorics I used to derive the equation in a more substantial fashion than is obvious.
I think that the internet is actually much wider and that the actual filtration rate is much closer to 5%. I also think that the peering combinatorics do probably corrupt your equation, but, I'm not sure in which direction or to what extent. It would be pretty hard to estimate, so, I'm willing to go with it for now.
Or perhaps your worry about route leakage from non-GUA space really is as overblown as the math suggests.
I'm not worried about leakage. You're claiming that a low probability of leakage provides a security benefit, I'm claiming that your security benefit is actually a false sense of security. (i.e. The benefit claimed for ULA is somewhere between small and non-existent). In a separate topic, I believe that DELIBERATE routing of ULA will be a very likely outcome of current policies eventually resulting in ULA being ubiquitously routed just as GUA is intended to be. This unfortunate end result of the combination of human nature to do the expedient rather than the correct will eventually remove any perceive benefits to ULA and cause additional problems as ULA becomes a globally routable resource not subject to RIR policy. The two issues are related, but, very different problems. (Actually, the first issue isn't really a problem unless you are depending on ULA to provide some form of security benefit). In my opinion, the far more secure thing to do is to use GUA. Put the hosts you want to be reachable from the outside in specific ranges of your GUA. For example: 2620:0db8:532a::/48 Total assignment for end site 2620:0db8:532a::/56 Space reserved for externally reachable Configure the following on your border routers: Routes: 2620:0db8:532a::/56 dynamic or static routes to correct destinations. 2620:0db8:532a:100::/55 -> null 2620:0db8:532a:200::/54 -> null 2620:0db8:532a:400::/53 -> null 2620:0db8:532a:800::/52 -> null 2620:0db8:532a:1000::/51 -> null 2620:0db8:532a:2000::/50 -> null 2620:0db8:532a:4000::/49 -> null 2620:0db8:532a:8000::/48 -> null Route filters: From internal interfaces: Accept 2620:0db8:532a::/56 or longer Deny 2620:0db8:532a:: ge /48 le /55 Packet filters: Stateful (outbound to internet): Permit <source match 2620:0db8:532a::/56> any Default Deny any any Stateful (inbound from internet): Permit <specifically intended inbound flows to 2620:0db8:532a::/56> Permit <matching outbound state table entry> Deny any 2620:0db8:532a::/48 Default deny inbound Static (outbound to internal interfaces) permit any 2620:0db8:532a::/56 deny any any Static (inbound from internal interfaces) permit <source match 2620:0db8:532a::/56> any deny any any (Assuming a router capable of stateful and static filters where a packet must be permitted by both in order to be forwarded. This is the case for JunOS. I'm not sure about Cisco or others. If you can only do stateless on your router, then, you lose one layer of defense, but, not all). Presumably you have stateful firewall(s) inside your border with appropriate full stateful policies. Now, in order to reach one of the hosts in the GUA space being used for the internal-only communications, one needs to make the following unauthorized or errant changes: 1. Override the null route. (either a static route or an unauthorized change to the dynamic filter + a dynamic route generated by or through the firewall). 2. Override the stateful Packet filter. 3. Override the Static packet filter. 4. Permit the flow on the firewall. Or, the easier approach: 1. Configure the host with an externally reachable address in the public accessible host range. 2. Plug the host into one of the publicly reachable networks rather than an internal network. 3. Add inbound permits to the stateful packet filter. 4. Add inbound permits to the firewall. Eiher way, it takes at least four acts of fat-fingered or malicious activity on hosts that have a security border role in order to achieve a meaningful leak, not the single error you claimed. Owen
On 10/23/2010 2:07 AM, Owen DeLong wrote:
However, deliberate routing of ULA will start small and slowly spread over time like a slow-growing cancer. You won't even really detect it until it has metastasized to such an extent that nothing can be done about it.
Which is why all v6 templates really need to get this in as a discard/filter/etc, just as we do with RFC-1918. I'm not saying it is perfect, but based on how much bogon lists have hurt legitimate traffic, we know the templates are at least used. Jack
On Sat, Oct 23, 2010 at 3:07 AM, Owen DeLong <owen@delong.com> wrote:
On Oct 22, 2010, at 6:10 PM, William Herrin wrote: Just for grins, let's put some rough math to that assertion. The average percentage of the Internet reached by a ULA or RFC1918 leak will be close to:
(1-A)^B
A = the probability of any given organization filtering private address announcements and/or private address packets at their borders B = the average width of the Internet in organizations (which should be slightly higher than the width in ASes)
I think your estimation of 50% is highly optimistic. I also think you underestimate the diameter of the internet, being much closer to 25 than 10 from what I can see. Filling in more realistic (based on my observations) numbers of 5% and 25, my numbers come out as: (1-0.05)^25 = 0.95 ^ 25 = 0.27 = a little more than 1/4 of the internet.
Owen, I see. In trying to pick those numbers, my current (today) experience is this: I filter. Two of the three ISPs I interact with personally filter. My employer filters. Three of the five ISPs they deal with filter. Total: 7 of 10 filter. What experience of yours leads you to believe that something closer to 1 in 20 organizations choose to filter out RFC1918 and/or ULA at their borders? Do *you* filter border-crossing RFC1918 traffic? Does your employer, HE?
ULA won't supplant GUA, it will be much more insidious than that. Most people will still use GUA for GUA purposes. However, deliberate routing of ULA will start small and slowly spread over time like a slow-growing cancer. You won't even really detect it until it has metastasized to such an extent that nothing can be done about it. I believe that DELIBERATE routing of ULA will be a very likely outcome of current policies eventually resulting in ULA being ubiquitously routed just as GUA is intended to be. This unfortunate end result of the combination of human nature to do the expedient rather than the correct will eventually remove any perceive benefits to ULA and cause additional problems as ULA becomes a globally routable resource not subject to RIR policy.
You need to back that up with something. This sort of thing doesn't just magically happen. Spin at least one scenario leading there in which the step-by-step choices by each of the participants are at least arguably rational.
In my opinion, the far more secure thing to do is to use GUA. Put the hosts you want to be reachable from the outside in specific ranges of your GUA. For example: Route filters: From internal interfaces: Accept 2620:0db8:532a::/56 or longer Deny 2620:0db8:532a:: ge /48 le /55
Fat finger the second line (interpose the b and the d) and misconnect one ethernet cable so that your firewall interior protocol can touch your firewall exterior protocol. In comes a set of formerly interior routes ranging from /56 to /64, more specific routes that override your nulls. You're done. Your entire internal network is now firewall-free on the Internet. You've never typed in a line wrong in a router config or plugged a cable in to the wrong jack, right? And you've never tasked network setup work to a junior engineer whose networking sophistication is less than your own. BTW, in your opinionated security process you forgot to install RA guard. Without RA guard on every switch port that doesn't connect to an intentional router, some idiot user can plug a 4G modem into their laptop and every damn device sharing the network will assign itself an additional GUA address and route through him. Two IPv4 dhcp servers tended to conflict with each other so the result was an outage. IPv6's designers considered that a bug and made it go away so that there's a good chance you won't notice the breach. We have not yet begun to reach the depths of SLAAC's badness. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Oct 21, 2010 at 6:27 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 10/21/10 6:02 AM, William Herrin wrote:
On Thu, Oct 21, 2010 at 8:14 AM, Ray Soucy <rps@maine.edu> wrote:
That's assuming ULA would be the primary addressing scheme used. If that became the norm, I agree, the extra uniqueness would be desirable, perhaps to the point that you should be asking an authority for FC00::/8 space to be assigned. But then why wouldn't you just ask for a GUA at that point.
Because you might want space that doesn't route on the Internet so that if your routes accidentally leak external folks still can't reach you?
Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far.
Joel, I have a condensate overflow pan under my computer room air conditioner that collects water if it leaks. I also have an alarm that alerts me if there's a leak and careful maintenance to prevent it from leaking in the first place. But I still have the pan. Even though a leak could fill the pan and overflow, I insist on having a pan there to try to catch the water. How many guesses do you need to figure out why? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Oct 21, 2010, at 6:02 AM, William Herrin wrote:
On Thu, Oct 21, 2010 at 8:14 AM, Ray Soucy <rps@maine.edu> wrote:
That's assuming ULA would be the primary addressing scheme used. If that became the norm, I agree, the extra uniqueness would be desirable, perhaps to the point that you should be asking an authority for FC00::/8 space to be assigned. But then why wouldn't you just ask for a GUA at that point.
Because you might want space that doesn't route on the Internet so that if your routes accidentally leak external folks still can't reach you?
That is, at best, a false sense of security which is worse than no security. Owen
Sorry for the double post. From re-reading the thread it doesn't sound like you might want ULA at all. The mindset of using RFC1918 space, throwing everything behind a NAT box, and not having to re-configure systems when you change ISP doesn't exist in IPv6. There is no IPv6 NAT (yet). If you wanted to setup an "island" of IPv6 that would never talk to the Internet, then you could use ULA, but that would only be needed if you plan on routing between LANs. Remember that by default every IPv6 host has a link-local address allowing it to talk to any directly connected hosts without configuration. So if you're simply looking for some sort of ad-hoc network, it's likely already there. As much as I hate NAT and want to see it go away. I think the biggest transition mechanism for people to get online with IPv6 will be some sort of appliance that does NAT of global IPv6 addresses to private IPv4 addresses to keep all the people living in the NAT world from having to redesign their networks. It's ugly, but its the path of least resistance and that's likely what will happen when we see IPv6 become required to do business... at least as a stepping stone. The idea to use multiple PA IPv6 allocations and have multiple GUAs for each host wasn't a bad one. It would certainly make the Internet routing table a lot more stable to not have everyone touching BGP... But they failed to fix DNS in a way that would make it possible. We already have priority for MX records. If we had priority for all records, and resolvers would remember when one was unreachable for a short time, then yes, you could have www.yourdomain.com point to multiple PA GUAs and if one was down users would nicely fail-over to the other. Unfortunately, if you have a host record with multiple AAAAs and one of them is unreachable, it will just mean that for some users the request will time out (as its just doing a round-robin and not trying others when things don't respond). In theory, you could try to get around the limitation by having a TTL of 30 seconds or something on your records, and have a system that would update DNS records when a connection dropped, but that's assuming people aren't deciding to set minimum cache times of their own. I think the best model possible with existing technology that's available is to separate L2 and L3 and use provider redundancy at L2 (multiple ME transport providers to your single, redundant, L3 transit provider). If you need more redundancy that that, you're likely using BGP for IPv4 already, anyway. The real problem never goes away, though. People like the operational control and simplicity that they get with NAT. If the provider goes down, they still work internally, if they have multiple providers, the internal network doesn't care which is active, and if they need to host services, they usually go with a hosting company off-site. I really don't think it will be long before we see some magic IPv6 NAT boxes start to pop up, whether or not standards exist for them, and it will be and ugly nightmare. IPv6 is simple enough for larger networks (like universities and governments) but very little attention has been giving to the SMB community and their needs with IPv6. On Thu, Oct 21, 2010 at 7:33 AM, Ray Soucy <rps@maine.edu> wrote:
For for all intents and purposes if you're looking for RFC1918 style space in IPv6 you should consider the block FD00::/8 not FC00::/7 as the FC00::/8 space is reserved in ULA for assignment by a central authority (who knows why, but with that much address space nobody really cares).
People may throw a fit at this, but as far as I'm concerned FD00::/8 will never leave the edge of our network (we null route ULA space before it can leak out, just like you would with RFC1918 space). So you can pretty much use it has you see fit. If you want to keep your ULA space short there is nothing stopping you from using something like FD00::1 as a valid address.
You could embed your ASN into it or some other identifier if you want to avoid conflicts with other non-routed address space which should never enter or leave your network from the outside, but I'm just not seeing the practical application for this.
On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
<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
-- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Oct 21, 2010, at 4:59 AM, Ray Soucy wrote:
Sorry for the double post. From re-reading the thread it doesn't sound like you might want ULA at all.
The mindset of using RFC1918 space, throwing everything behind a NAT box, and not having to re-configure systems when you change ISP doesn't exist in IPv6. There is no IPv6 NAT (yet).
And hopefully there never will be...
If you wanted to setup an "island" of IPv6 that would never talk to the Internet, then you could use ULA, but that would only be needed if you plan on routing between LANs. Remember that by default every IPv6 host has a link-local address allowing it to talk to any directly connected hosts without configuration. So if you're simply looking for some sort of ad-hoc network, it's likely already there.
You may want non-LL space even if you aren't routing, since for LL, the destination address has to include the outbound interface name or it doesn't work.
As much as I hate NAT and want to see it go away. I think the biggest transition mechanism for people to get online with IPv6 will be some sort of appliance that does NAT of global IPv6 addresses to private IPv4 addresses to keep all the people living in the NAT world from having to redesign their networks. It's ugly, but its the path of least resistance and that's likely what will happen when we see IPv6 become required to do business... at least as a stepping stone.
NAT64 already exists, although generally not for that application. I'm not convinced it is the path of least resistance, technically. If you mean politically, then, yes, but, making engineering decisions based on the political path of least resistance tends to cause more damage than it resolves. You don't actually have to redesign your IPv4 NAT network to put IPv6 on it in parallel. You just need to recognize that the IPv6 stateful firewall now provides your IPv6 security without needing to mangle the packet header in the process. You should be able to put all the same exact policies in place, without the nasty address translation bits.
The idea to use multiple PA IPv6 allocations and have multiple GUAs for each host wasn't a bad one. It would certainly make the Internet
If it worked, it would be a great one, but...
routing table a lot more stable to not have everyone touching BGP... But they failed to fix DNS in a way that would make it possible. We
Not just DNS... It would have impacted TCP, to some extent, UDP, applications, etc.
already have priority for MX records. If we had priority for all records, and resolvers would remember when one was unreachable for a short time, then yes, you could have www.yourdomain.com point to
The resolver doesn't have any way to know the reachability status of a given address from the resolver client. The information simply isn't available to the resolver. I suppose you could design a mechanism for the client to send feedback to the resolver, but, that's pretty hokey.
multiple PA GUAs and if one was down users would nicely fail-over to the other. Unfortunately, if you have a host record with multiple AAAAs and one of them is unreachable, it will just mean that for some users the request will time out (as its just doing a round-robin and not trying others when things don't respond).
Actually, unless the client software is exceptionally poorly written, it won't time out, but, the delay before trying the next host is exceedingly long (30 seconds) if you don't get an unreachable message back about the first attempt(s).
In theory, you could try to get around the limitation by having a TTL of 30 seconds or something on your records, and have a system that would update DNS records when a connection dropped, but that's assuming people aren't deciding to set minimum cache times of their own.
We already know that M$ absolutely breaks this across the board.
I think the best model possible with existing technology that's available is to separate L2 and L3 and use provider redundancy at L2 (multiple ME transport providers to your single, redundant, L3 transit provider). If you need more redundancy that that, you're likely using BGP for IPv4 already, anyway.
You can get exactly the same reliability from IPv6 as you have in IPv4 using pretty much exactly the same tactics. If you're using IPv4 with multiple providers giving you different NAT pools, then, you're looking at outbound, not inbound resiliency and the DNS stuff you described is irrelevant. As long as your outbound gateway(s) have some way to detect provider down-ness (all the same tactics that work for IPv4 here work for IPv6 with pretty much the same flaws), you can do the same thing. The difference is that in IPv6, you have to tell the hosts which IPv6 source prefix to use. The easy way to do that is to alter the desired/valid lifetimes in your internal RAs accordingly. This isn't hard to script. If you're using IPv4 with BGP and advertising the same prefix(es) to multiple providers, the same thing works in IPv6 with nearly identical processes. If you've got meaningful in-bound resiliency in IPv4, then, you're using IPv4 with BGP and advertising the same prefix(es) to multiple providers anyway. If you're doing something else in IPv4, then, you're pretending to have resiliency and it will work just as poorly in IPv6, most likely.
The real problem never goes away, though. People like the operational control and simplicity that they get with NAT. If the provider goes
Huh? I don't see what NAT gives you for EITHER of those things.
down, they still work internally, if they have multiple providers, the
There's no reason that can't be true with IPv6. NOTHING says your IPv6 prefix use internally has to be affected by your provider going down.
internal network doesn't care which is active, and if they need to host services, they usually go with a hosting company off-site. I
This is achievable in IPv6, too. If you have multiple providers, that's sufficient justification to obtain an IPv6 prefix from most RIRs. Once you do that, your internal network doesn't care which provider is active.
really don't think it will be long before we see some magic IPv6 NAT boxes start to pop up, whether or not standards exist for them, and it will be and ugly nightmare.
I really really really hope you are wrong about that.
IPv6 is simple enough for larger networks (like universities and governments) but very little attention has been giving to the SMB community and their needs with IPv6.
I disagree... Please let me know where you think IPv6 falls short for SMB and I will be happy to show you feasible solutions. Owen 2620:0:930::/48 ARIN direct assignment, multihomed through (relatively) cheap connectivity at my house.
On Thu, Oct 21, 2010 at 7:33 AM, Ray Soucy <rps@maine.edu> wrote:
For for all intents and purposes if you're looking for RFC1918 style space in IPv6 you should consider the block FD00::/8 not FC00::/7 as the FC00::/8 space is reserved in ULA for assignment by a central authority (who knows why, but with that much address space nobody really cares).
People may throw a fit at this, but as far as I'm concerned FD00::/8 will never leave the edge of our network (we null route ULA space before it can leak out, just like you would with RFC1918 space). So you can pretty much use it has you see fit. If you want to keep your ULA space short there is nothing stopping you from using something like FD00::1 as a valid address.
You could embed your ASN into it or some other identifier if you want to avoid conflicts with other non-routed address space which should never enter or leave your network from the outside, but I'm just not seeing the practical application for this.
On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
<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
-- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
See... You're falling into the same elitist mindset that I was trapped in a year ago. Perception is a powerful thing. And Joe IT guy at Mom and Pop dot com (who's network experience involves setting up a Linksys at home) loves his magical NAT box firewall appliance. Over the last year I've been trying to fight the NAT war and have gotten pretty beat down. It doesn't matter if *we* know NAT is wrong, undesirable, and breaks the Internet... we all live in the large scale, multi-homed, BGP, mega Internet land. Start working with smaller shops, and you'll find the typical setup is a bunch of switches and a "VPN Firewall" picked up from Best Buy, or maybe a Sonicwall or something. These guys couldn't manage public IPv4 let alone public IPv6, because the term "private" gives them that warm and fuzzy false sense of security and lets them change their ISP without reconfiguring a single thing (they often wouldn't know where to start anyway). They *will* fight you, and tell you to your face that if you want to take NAT away from them it will be from their cold dead hands. Why? Because we've had 10 years of "consultants" selling NAT as the best thing for security since sliced bread. Maybe we could get them to do it the right way if they had some sort of IPv6 appliance that dumbed things down, but it simply doesn't exist yet. When it is created, it will be created by the people with the NAT mindset wishing to maintain the status quo. At least that's my prediction... We need to keep in mind that most on this list is likely at a completely different level than anything you'd find in the SMB community. They can't afford to hire "networking" people, they hire "IT" people who are tasked with anything related to technology and usually completely understaffed. Thus they want the quick, painless, easy solution. On Thu, Oct 21, 2010 at 8:26 AM, Owen DeLong <owen@delong.com> wrote:
On Oct 21, 2010, at 4:59 AM, Ray Soucy wrote:
Sorry for the double post. From re-reading the thread it doesn't sound like you might want ULA at all.
The mindset of using RFC1918 space, throwing everything behind a NAT box, and not having to re-configure systems when you change ISP doesn't exist in IPv6. There is no IPv6 NAT (yet).
And hopefully there never will be...
If you wanted to setup an "island" of IPv6 that would never talk to the Internet, then you could use ULA, but that would only be needed if you plan on routing between LANs. Remember that by default every IPv6 host has a link-local address allowing it to talk to any directly connected hosts without configuration. So if you're simply looking for some sort of ad-hoc network, it's likely already there.
You may want non-LL space even if you aren't routing, since for LL, the destination address has to include the outbound interface name or it doesn't work.
As much as I hate NAT and want to see it go away. I think the biggest transition mechanism for people to get online with IPv6 will be some sort of appliance that does NAT of global IPv6 addresses to private IPv4 addresses to keep all the people living in the NAT world from having to redesign their networks. It's ugly, but its the path of least resistance and that's likely what will happen when we see IPv6 become required to do business... at least as a stepping stone.
NAT64 already exists, although generally not for that application.
I'm not convinced it is the path of least resistance, technically. If you mean politically, then, yes, but, making engineering decisions based on the political path of least resistance tends to cause more damage than it resolves.
You don't actually have to redesign your IPv4 NAT network to put IPv6 on it in parallel. You just need to recognize that the IPv6 stateful firewall now provides your IPv6 security without needing to mangle the packet header in the process. You should be able to put all the same exact policies in place, without the nasty address translation bits.
The idea to use multiple PA IPv6 allocations and have multiple GUAs for each host wasn't a bad one. It would certainly make the Internet
If it worked, it would be a great one, but...
routing table a lot more stable to not have everyone touching BGP... But they failed to fix DNS in a way that would make it possible. We
Not just DNS... It would have impacted TCP, to some extent, UDP, applications, etc.
already have priority for MX records. If we had priority for all records, and resolvers would remember when one was unreachable for a short time, then yes, you could have www.yourdomain.com point to
The resolver doesn't have any way to know the reachability status of a given address from the resolver client. The information simply isn't available to the resolver. I suppose you could design a mechanism for the client to send feedback to the resolver, but, that's pretty hokey.
multiple PA GUAs and if one was down users would nicely fail-over to the other. Unfortunately, if you have a host record with multiple AAAAs and one of them is unreachable, it will just mean that for some users the request will time out (as its just doing a round-robin and not trying others when things don't respond).
Actually, unless the client software is exceptionally poorly written, it won't time out, but, the delay before trying the next host is exceedingly long (30 seconds) if you don't get an unreachable message back about the first attempt(s).
In theory, you could try to get around the limitation by having a TTL of 30 seconds or something on your records, and have a system that would update DNS records when a connection dropped, but that's assuming people aren't deciding to set minimum cache times of their own.
We already know that M$ absolutely breaks this across the board.
I think the best model possible with existing technology that's available is to separate L2 and L3 and use provider redundancy at L2 (multiple ME transport providers to your single, redundant, L3 transit provider). If you need more redundancy that that, you're likely using BGP for IPv4 already, anyway.
You can get exactly the same reliability from IPv6 as you have in IPv4 using pretty much exactly the same tactics.
If you're using IPv4 with multiple providers giving you different NAT pools, then, you're looking at outbound, not inbound resiliency and the DNS stuff you described is irrelevant. As long as your outbound gateway(s) have some way to detect provider down-ness (all the same tactics that work for IPv4 here work for IPv6 with pretty much the same flaws), you can do the same thing. The difference is that in IPv6, you have to tell the hosts which IPv6 source prefix to use. The easy way to do that is to alter the desired/valid lifetimes in your internal RAs accordingly. This isn't hard to script.
If you're using IPv4 with BGP and advertising the same prefix(es) to multiple providers, the same thing works in IPv6 with nearly identical processes.
If you've got meaningful in-bound resiliency in IPv4, then, you're using IPv4 with BGP and advertising the same prefix(es) to multiple providers anyway. If you're doing something else in IPv4, then, you're pretending to have resiliency and it will work just as poorly in IPv6, most likely.
The real problem never goes away, though. People like the operational control and simplicity that they get with NAT. If the provider goes
Huh?
I don't see what NAT gives you for EITHER of those things.
down, they still work internally, if they have multiple providers, the
There's no reason that can't be true with IPv6. NOTHING says your IPv6 prefix use internally has to be affected by your provider going down.
internal network doesn't care which is active, and if they need to host services, they usually go with a hosting company off-site. I
This is achievable in IPv6, too. If you have multiple providers, that's sufficient justification to obtain an IPv6 prefix from most RIRs. Once you do that, your internal network doesn't care which provider is active.
really don't think it will be long before we see some magic IPv6 NAT boxes start to pop up, whether or not standards exist for them, and it will be and ugly nightmare.
I really really really hope you are wrong about that.
IPv6 is simple enough for larger networks (like universities and governments) but very little attention has been giving to the SMB community and their needs with IPv6.
I disagree... Please let me know where you think IPv6 falls short for SMB and I will be happy to show you feasible solutions.
Owen 2620:0:930::/48 ARIN direct assignment, multihomed through (relatively) cheap connectivity at my house.
On Thu, Oct 21, 2010 at 7:33 AM, Ray Soucy <rps@maine.edu> wrote:
For for all intents and purposes if you're looking for RFC1918 style space in IPv6 you should consider the block FD00::/8 not FC00::/7 as the FC00::/8 space is reserved in ULA for assignment by a central authority (who knows why, but with that much address space nobody really cares).
People may throw a fit at this, but as far as I'm concerned FD00::/8 will never leave the edge of our network (we null route ULA space before it can leak out, just like you would with RFC1918 space). So you can pretty much use it has you see fit. If you want to keep your ULA space short there is nothing stopping you from using something like FD00::1 as a valid address.
You could embed your ASN into it or some other identifier if you want to avoid conflicts with other non-routed address space which should never enter or leave your network from the outside, but I'm just not seeing the practical application for this.
On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart <jeroen@mompl.net> wrote:
<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
-- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Hi All, I've inherited a small network with a couple of Internet connections through different providers, I'll call them Slow and Fast. We use RFC 1918 space internally and have a pair of external firewalls that handle NAT and such. Due to internal policy (read money), some users default to the Slow connection and some default to Fast. Using probes and policy routing, a failure of one of the ISPs is generally transparent, outside of the usual session resets for things like ssh or remote control sessions). Looking forward to the next 12 months, we may have clients that are living in IPv6 space. Our ISPs are happy to give us IPv6 allocations and our network gear vendors either have GA IPv6 code now or will soon. We have been somewhat spoiled by our firewall/NAT boxes, the stuff just works for our needs and the combination of NAT and policy routing keeps people on the circuits they are paying for. Am trying to decide how I would implement this kind of policy in the new world of globally trackable^H^H^H^H^H^H^H routable IPs for my desktops. Solutions seem to be: 1) Purchase some BGP capable routers, grab PI space. Here I can obv choose outbound path, but we are typical in that our inbound to outbound is 6 or 7 to 1. 2) Assign PA space from the ISPs to the appropriate devices. What do I do when I loose a provider? 3) Make loud noises to my firewall vendor to include equivalent NAT/ISP failover functionality (even 6to6 NAT would be fine). Anyway, another sample of 1, but I do work for a managed services provider and see many small orgs facing similary choices. I personally am happy to use globally routable addresses and will work through the privacy and perceived security implications of NAT/nonat, I just want the same ease of use and flexibility I have today in a SMB environment. Cheers, -Allen
[Oh wow, that subject field, so handy to indicate a topic change! ;) ] On 2010-10-21 18:29, Allen Smith wrote: [... well described situation about having two/multiple IPv4 upstreams, enabling dual-stack at both, but wanting to failover between them without doing NATv6 ...] Short answer: you announce both PA prefixes using Router Advertisement (RA) inside the network. You pull the RA when a uplink goes down/breaks. Sessions break indeed, but because there is the other prefix they fall over to that and build up new sessions from there. Most RA "daemons" will properly send a 0-lifetime announcement to pull the prefix thus all hosts are automatically informed that the prefix has become invalid. Of course you can also make the router's IP address unreachable as then Neighbor Discovery will take care of failing over too. To address your 'we have multiple groups of people some use slow some use fast', put them in separate (V)LANs and presto. You could effectively live with using one prefix per group and only failing over to the other prefix when the primary one goes down; that is only RA the prefix to those VLANs when you really need it. You should be getting a /48 from both ISPs and here comes the reason for always getting a /48 and nothing else: you have the same numbering plan for all of them. Now the problem with such a setup is the many locations where you actually are hardcoding the IP addresses/prefixes into: firewalls, DNS etc. That is the hard part to solve, especially when these services are managed by other parties. Greets, Jeroen
Jeroen Massar (jeroen) writes:
Now the problem with such a setup is the many locations where you actually are hardcoding the IP addresses/prefixes into: firewalls, DNS etc. That is the hard part to solve, especially when these services are managed by other parties.
And probably the reason why most won't deploy RA and multiple prefixes. Hardcode and NAT, baby!
On Oct 21, 2010, at 10:02 AM, Phil Regnauld wrote:
Jeroen Massar (jeroen) writes:
Now the problem with such a setup is the many locations where you actually are hardcoding the IP addresses/prefixes into: firewalls, DNS etc. That is the hard part to solve, especially when these services are managed by other parties.
And probably the reason why most won't deploy RA and multiple prefixes. Hardcode and NAT, baby!
If you want to hardcode, do it with PI and not NAT. Owen
In message <20101021170258.GE61771@macbook.catpipe.net>, Phil Regnauld writes:
Jeroen Massar (jeroen) writes:
Now the problem with such a setup is the many locations where you actually are hardcoding the IP addresses/prefixes into: firewalls, DNS etc. That is the hard part to solve, especially when these services are managed by other parties.
And probably the reason why most won't deploy RA and multiple prefixes. Hardcode and NAT, baby!
Well have the hosts update their own addresses in the DNS. That's one of the problems addressed. There are at least two commercial OSs which will do this for you. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Well have the hosts update their own addresses in the DNS. That's one of the problems addressed. There are at least two commercial OSs which will do this for you.
Mark
But they sometimes don't check to make sure there aren't stale DNS entries for their hostname before they add the new one! I have run into that problem often. A machine that has been "bounced" several times recently might have a dozen A records for its hostname in DNS. I won't mention any names but their initials are MICROSOFT. For many of our machines, there are load balancers, even in the office data center with hard coded IP addresses for the backend servers. Dynamic address assignment isn't really an option but works fine for things like user machines in the cubes. You aren't going to be looking those up by A record anyway. Static assignment by DHCP is possible for the devices that do that, you just have to remember to change it if you change a NIC (or if the interfaces are bound together on the box, such as with linux bonding, the "master" interface of the bond changes for some reason like a failure of the previous master). Static hard coding of the IP address is actually easier to manage in the colo than DHCP or autoconfiguration.
On 10/21/2010 9:32 PM, George Bonser wrote:
But they sometimes don't check to make sure there aren't stale DNS entries for their hostname before they add the new one! I have run into that problem often. A machine that has been "bounced" several times recently might have a dozen A records for its hostname in DNS. I won't mention any names but their initials are MICROSOFT. For many of our machines, there are load balancers, even in the office data center with hard coded IP addresses for the backend servers. Dynamic address assignment isn't really an option but works fine for things like user machines in the cubes. You aren't going to be looking those up by A record anyway. Static assignment by DHCP is possible for the devices that do that, you just have to remember to change it if you change a NIC (or if the interfaces are bound together on the box, such as with linux bonding, the "master" interface of the bond changes for some reason like a failure of the previous master). Static hard coding of the IP address is actually easier to manage in the colo than DHCP or autoconfiguration.
Many of these problems are application/implementation issues. Many devices need support for dynamic prefix specifications "hey, my destination for the load balancer is $prefix:blah", and some devices still need support for just setting their IP with RA (though all my servers do it fine). At this time, there are many situations where static assignment is probably the only option. Multiple assignments may not be out of the question. However, this is due to the shortage of what IPv6 *could* be. We are missing so many support protocols and applications that could truly make it far superior to IPv4. Then again, I think SCTP is superior to udp/tcp, and I don't think I have a single app using it. Jack
From: Jeroen Massar > Sent: Thursday, October 21, 2010 9:57 AM To: Allen Smith Cc: NANOG list Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 — Unique local addresses)
[Oh wow, that subject field, so handy to indicate a topic change! ;) ]
Short answer: you announce both PA prefixes using Router Advertisement (RA) inside the network. You pull the RA when a uplink goes down/breaks.
That assumes importing some sort of routing state into your RA config. Sort of a conditional RA. Can that be done today by anyone?
Sessions break indeed, but because there is the other prefix they fall over to that and build up new sessions from there.
This still doesn’t address breakage that happens AFTER your link to your upstream. What if your upstream has a peering issue or their peer has a peering issue? How do you detect that the distant end has a route back to that prefix but doesn't to the other? You can't.
On 2010-10-21 21:35, George Bonser wrote:
From: Jeroen Massar > Sent: Thursday, October 21, 2010 9:57 AM To: Allen Smith Cc: NANOG list Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 — Unique local addresses)
[Oh wow, that subject field, so handy to indicate a topic change! ;) ]
Short answer: you announce both PA prefixes using Router Advertisement (RA) inside the network. You pull the RA when a uplink goes down/breaks.
That assumes importing some sort of routing state into your RA config. Sort of a conditional RA. Can that be done today by anyone?
Sessions break indeed, but because there is the other prefix they fall over to that and build up new sessions from there.
This still doesn’t address breakage that happens AFTER your link to your upstream. What if your upstream has a peering issue or their peer has a peering issue? How do you detect that the distant end has a route back to that
Should be possible with any vendor that supports IPv6. If you take a vendor C box and the box dies (just pull the power plug to test this or configure it with something funky ;), Neighbor Discovery starts failing and every IPv6 stack that I know will deprecate the routes over that gateway, and stuff fails over. For 'production usage', let your monitor script login to your router, whatever brand/make/model that is, and unconfigure the RA or heck kill the radvd daemon. prefix but
doesn't to the other? You can't.
Solve it the way you solve it with PI: - Get an SLA with every destination you want to reach Indeed, that is a more or less unsolveable problem. You can of course monitor all the destinations you want to reach and based on that to use the prefix or not. Greets, Jeroen
On Oct 21, 2010, at 12:35 PM, George Bonser wrote:
From: Jeroen Massar > Sent: Thursday, October 21, 2010 9:57 AM To: Allen Smith Cc: NANOG list Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 — Unique local addresses)
[Oh wow, that subject field, so handy to indicate a topic change! ;) ]
Short answer: you announce both PA prefixes using Router Advertisement (RA) inside the network. You pull the RA when a uplink goes down/breaks.
That assumes importing some sort of routing state into your RA config. Sort of a conditional RA. Can that be done today by anyone?
It can be done with some clever JunOScript or a few other mechanisms. Of course, it can also be done on a linux-based router fairly easily using whatever scripting language you like.
Sessions break indeed, but because there is the other prefix they fall over to that and build up new sessions from there.
This still doesn’t address breakage that happens AFTER your link to your upstream. What if your upstream has a peering issue or their peer has a peering issue? How do you detect that the distant end has a route back to that prefix but doesn't to the other? You can't.
How do you do that for IPv4... There's nothing new here. The failure modes are identical and your NAT box in IPv4 doesn't protect you from this any better. In fact, even multihomed BGP doesn't protect you from this unless you're taking a full table (which is a lot more practical in IPv6 than IPv4). Owen
How do you do that for IPv4... There's nothing new here. The failure modes are identical and your NAT box in IPv4 doesn't protect you from this any better.
With IPv4 I don't generally use two sets of prefixes for the same traffic from the same site to the Internet unless there is some sort of appliance in the path that somehow decides the "best" one to use for NAT and even then I am not convinced of such a device's utility in a general purpose sense. There might be corner cases where such an option is useful, though. I was making the point that trying to use two prefixes for the same traffic from the same site as some sort of redundancy doesn't really offer it because it only offers relief if your link to the provider drops. There are all sorts of other problems that can happen out on "the net" to make one prefix reachable but the other one not reachable from a remote site. Multihoming the same prefix from two providers is generally more reliable because if the remote network can "see" either provider, you are good and traffic can "fail over" from provider A to provider B in the course of a transaction without disruption. To recap, this tangent of the original thread was about the typical practice at small offices without a lot of network savvy to number the network in 1918 space and use a NAT at the Internet edge. To change providers, you simply change the NAT pool and you are done. With v6, while changing prefixes is easy for some gear, other gear is not so easy. If you number your entire network in Provider A's space, you might have more trouble renumbering into Provider B's space because now you have to change your DHCP ranges, probably visit printers, fax machines, wireless gateways, etc. and renumber those, etc. And some production boxes that you might have in the office data center are probably best left at a static IP address, particularly if they are fronted by a load balancer where their IP is manually configured. The complaint was that there is no equivalent in v6 and that someone is probably going to build and sell one and we will be right back in the same situation with v6 with networks in ULA space being NATed at the edge. People aren't going to want very much of their network infrastructure support tied to a provider's IP space. The small operation of which there are millions in this country, cannot justify the expense of multihoming for the sole reason of having an IP address range that doesn't change. As soon as the same configuration currently used is available for v6, you will see mass adoption of it. The lack of this currently in the market is probably one of the major drags on the adoption of v6 in the small office environment. People just do not want to number their internal network into PA space and can't justify the requirements to get PI space.
In fact, even multihomed BGP doesn't protect you from this unless you're taking a full table (which is a lot more practical in IPv6 than IPv4).
Owen
In a message written on Thu, Oct 21, 2010 at 07:21:41PM -0700, George Bonser wrote:
With v6, while changing prefixes is easy for some gear, other gear is not so easy. If you number your entire network in Provider A's space, you might have more trouble renumbering into Provider B's space because now you have to change your DHCP ranges, probably visit printers, fax machines, wireless gateways, etc. and renumber those, etc. And some production boxes that you might have in the office data center are probably best left at a static IP address, particularly if they are fronted by a load balancer where their IP is manually configured.
The complaint was that there is no equivalent in v6 and that someone is probably going to build and sell one and we will be right back in the same situation with v6 with networks in ULA space being NATed at the edge. People aren't going to want very much of their network infrastructure support tied to a provider's IP space.
It would seem to me there is a market for a "new sort of NAT" with IPv6. That is the technology is not new, but it's a model we can't do in IPv4. If you could number your internal network out of some IPv6 space (possibly 1918 style, possibly not), probably a /48, and then get from your two (or more) upstreams /48's of PA space you could do 1:1 NAT. No PAT, just pure address translation, 1:1. You can "renumber" by configuring a new outside translation. The NAT box can do the load distribution functions discussed here, some users out one provider, others out the second provider. There is no port complication, so incoming connections are much simpler. It's a vast improvement over the port based mess we have now, and provides an interesting way to "multihome" at the edge. If we could get a simple protocol, in the model of UDLD to go NAT box to Provider router to establish that it was up, and a little bit of DNS software magic to make it easier to manage the external addresses appearing in DNS for exposed services this could solve the vast majority of small site multihoming needs. What makes it all possible is the same prefix length internally and from all providers. It's a reason why /48 could be important. Given all effort put into "better" multihoming in IPv6 I'm really surprised this simple solution which basically exists in code today (porting an IPv4 NAT to IPv6, if there is no PAT, is easy). -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
From: Leo Bicknell Sent: Thursday, October 21, 2010 7:53 PM To: NANOG list Subject: Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses)
What makes it all possible is the same prefix length internally and from all providers. It's a reason why /48 could be important.
Right. /48 is the secret sauce in that. What you could do is: Assume a new connection to a destination you have not spoken to yet. SYN arrives from the inside machine trying to connect out. NAT box sends a SYN from each of the NATed IPs for the upstream providers. The one that returns first "wins" and that is the prefix you use to NAT that connection, the other one gets RST. You remember which upstream is associated with that connection for some period of time and reuse it. After some period of time elapses you would "forget" and test again on a new connection attempt. That at least gives you assurance the remote site has a path back to that IP and you are going with the higher performing path. You might even have an option to "nail" certain inside IPs to a certain path or certain remote destinations to a certain path.
Given all effort put into "better" multihoming in IPv6 I'm really surprised this simple solution which basically exists in code today (porting an IPv4 NAT to IPv6, if there is no PAT, is easy).
It would seem that simply translating the source /48 would be simple enough but would probably break something. Might break some Microsoft secure connection protocols where the IP in the header doesn't match the reported IP inside the packet, though, but that could probably be fixed, too.
On Thu, Oct 21, 2010, Leo Bicknell wrote:
If you could number your internal network out of some IPv6 space (possibly 1918 style, possibly not), probably a /48, and then get from your two (or more) upstreams /48's of PA space you could do 1:1 NAT. No PAT, just pure address translation, 1:1.
You can "renumber" by configuring a new outside translation. The NAT box can do the load distribution functions discussed here, some users out one provider, others out the second provider. There is no port complication, so incoming connections are much simpler.
You assume the protocol(s) don't include IP addresses inside the payload. You also assume the protocol(s) don't do things like checksum application payloads, which include IP addresses. Both of which I've seen, today. Some of which I occasionally see inside, hm, "over-enthusiastic" HTTP procotol/application designers. NAT's going to be needed, but it's going to be more stateful inspection-y than most of the vocal nanog+ipv6 people desire. :) Adrian
On Thu, 21 Oct 2010 19:21:41 PDT, George Bonser said:
With v6, while changing prefixes is easy for some gear, other gear is not so easy. If you number your entire network in Provider A's space, you might have more trouble renumbering into Provider B's space because now you have to change your DHCP ranges, probably visit printers, fax machines, wireless gateways, etc. and renumber those, etc. And some production boxes that you might have in the office data center are probably best left at a static IP address, particularly if they are fronted by a load balancer where their IP is manually configured.
"If Woody had gone straight to a ULA prefix, this would never have happened..." If a site is numbering their internal IPv4 stuff to avoid having to renumber on a provider change, then why would they number their IPv6 stuff from provider space rather than ULA space? And remember - (a) IPv6 allows machine to easily support multiple addresses and (b) if you have a provider address and a ULA, changing providers only means renumbering a *partial* renumber of the hosts that require external visibility - your internal hosts can continue talking to each other on a ULA as if nothing happened. Sure beats the mayhem if your company buys an organization and the 1918 spaces the 2 groups use overlap... Yee-hah. ;)
On Oct 31, 2010, at 7:22 AM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 21 Oct 2010 19:21:41 PDT, George Bonser said:
With v6, while changing prefixes is easy for some gear, other gear is not so easy. If you number your entire network in Provider A's space, you might have more trouble renumbering into Provider B's space because now you have to change your DHCP ranges, probably visit printers, fax machines, wireless gateways, etc. and renumber those, etc. And some production boxes that you might have in the office data center are probably best left at a static IP address, particularly if they are fronted by a load balancer where their IP is manually configured.
"If Woody had gone straight to a ULA prefix, this would never have happened..."
Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either.
If a site is numbering their internal IPv4 stuff to avoid having to renumber on a provider change, then why would they number their IPv6 stuff from provider space rather than ULA space?
Which gains what vs. PI?
And remember - (a) IPv6 allows machine to easily support multiple addresses and (b) if you have a provider address and a ULA, changing providers only means renumbering a *partial* renumber of the hosts that require external visibility - your internal hosts can continue talking to each other on a ULA as if nothing happened.
If you have PI space, changing providers can be even easier and you can leave multiple providers running in parallel. Owen
On Sun, Oct 31, 2010 at 12:31 PM, Owen DeLong <owen@delong.com> wrote:
On Oct 31, 2010, at 7:22 AM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 21 Oct 2010 19:21:41 PDT, George Bonser said:
With v6, while changing prefixes is easy for some gear, other gear is not so easy. If you number your entire network in Provider A's space, you might have more trouble renumbering into Provider B's space because now you have to change your DHCP ranges, probably visit printers, fax machines, wireless gateways, etc. and renumber those, etc. And some production boxes that you might have in the office data center are probably best left at a static IP address, particularly if they are fronted by a load balancer where their IP is manually configured.
"If Woody had gone straight to a ULA prefix, this would never have happened..."
Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either.
ula really never should an option... except for a short lived lab, nothing permanent.
ula really never should an option... except for a short lived lab, nothing permanent.
I have a few candidate networks for it. Mostly networks used for clustering or database access where they are just a flat LAN with no "gateway". No layer 3 gets routed off that subnet and the only things talking on it are directly attached to it.
On Sun, Oct 31, 2010 at 2:01 PM, George Bonser <gbonser@seven.com> wrote:
ula really never should an option... except for a short lived lab, nothing permanent.
I have a few candidate networks for it. Mostly networks used for clustering or database access where they are just a flat LAN with no "gateway". No layer 3 gets routed off that subnet and the only things talking on it are directly attached to it.
why not just use link-local then? eventually you'll have to connect that network with another one, chances of overlap (if the systems support real revenue) are likely too high to want to pay the renumbering costs, so even link-local isn't a 100% win :( globally-unique is really the best option all around. -chris
why not just use link-local then? eventually you'll have to connect that network with another one, chances of overlap (if the systems support real revenue) are likely too high to want to pay the renumbering costs, so even link-local isn't a 100% win :( globally-unique is really the best option all around.
-chris
Routing mostly on the end host is why. If I have 10 clustering vlans (which will never get routed outside the cluster) and they all have the same link local address (if the vlan interfaces are configured on the same ethernet device, they will all have the same link local address), how do they know which vlan interface to send the packet out? All of them will have exactly the same link local address. And I have an aversion to putting link local IPs in DNS as everyone thinks the hostname is on the local link in case of some kind of dns screwup.
In message <AANLkTimsB6Uj-jpogLg08Q-RZDUB-+C9c5KMzcKTQKmQ@mail.gmail.com>, Chri stopher Morrow writes:
On Sun, Oct 31, 2010 at 2:01 PM, George Bonser <gbonser@seven.com> wrote:
ula really never should an option... except for a short lived lab, nothing permanent.
I have a few candidate networks for it. =A0Mostly networks used for clustering or database access where they are just a flat LAN with no "gateway". =A0No layer 3 gets routed off that subnet and the only things talking on it are directly attached to it.
why not just use link-local then?
If you had actually every tried to use link-local then you would know why you don't use link-local.
eventually you'll have to connect that network with another one, chances of overlap (if the systems support real revenue) are likely too high to want to pay the renumbering costs, so even link-local isn't a 100% win :( globally-unique is really the best option all around.
2^40 is 1099511627776. The chances of collision are so low that one really shouldn't worry about it. You are millions of times more likely of dieing from a asteroid 1-in-500,000[1]. If you merge thousands of ULA and don't consolidate then you start to have a reasonable chance of collision. Even if you do have colliding ULA prefixes you don't necessarially have colliding subnets when merging companies. Just allocate subnet randomly. It's not like 2^16 internal subnets is going to be a major routing problem. Mark [1] http://www.livescience.com/environment/050106_odds_of_dying.html -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Oct 31, 2010, at 7:43 PM, Mark Andrews wrote:
In message <AANLkTimsB6Uj-jpogLg08Q-RZDUB-+C9c5KMzcKTQKmQ@mail.gmail.com>, Chri stopher Morrow writes:
On Sun, Oct 31, 2010 at 2:01 PM, George Bonser <gbonser@seven.com> wrote:
ula really never should an option... except for a short lived lab, nothing permanent.
I have a few candidate networks for it. =A0Mostly networks used for clustering or database access where they are just a flat LAN with no "gateway". =A0No layer 3 gets routed off that subnet and the only things talking on it are directly attached to it.
why not just use link-local then?
If you had actually every tried to use link-local then you would know why you don't use link-local.
I use link local often for many things. Try again.
eventually you'll have to connect that network with another one, chances of overlap (if the systems support real revenue) are likely too high to want to pay the renumbering costs, so even link-local isn't a 100% win :( globally-unique is really the best option all around.
2^40 is 1099511627776. The chances of collision are so low that one really shouldn't worry about it. You are millions of times more likely of dieing from a asteroid 1-in-500,000[1].
There are almost 7,000,000,000 people on the planet. We have not had anywhere near 14,000 people killed by asteroids, I think their calculation is off.
If you merge thousands of ULA and don't consolidate then you start to have a reasonable chance of collision. Even if you do have colliding ULA prefixes you don't necessarially have colliding subnets when merging companies. Just allocate subnet randomly. It's not like 2^16 internal subnets is going to be a major routing problem.
This is, of course, assuming many things: 1. Everyone follows the same random ULA allocation algorithm. 2. The algorithm is not flawed and yields relatively smooth distribution without significant hot-spots. 3. People are not lazy 4. People read instructions Assumption 1 depends on assumptions 3 and 4. Assumption 2 is still relatively unknown as we don't have enough operational experience with it. Assumption 3 is pretty well provably false. Assumption 4 is virtually guaranteed to fail. Since Assumptions 3 and 4 are non-starters, assumption 1 is seriously flawed at best. Owen
On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote:
"If Woody had gone straight to a ULA prefix, this would never have happened..." Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent.
Seems to me the options are: 1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell. My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers. That would seem to leave (3). Am I missing an option? Regards, -drc
Seems to me the options are:
1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost,
no
routing table bloat
In my particular case, IPv6 offers no advantage when it comes to renumbering. It is just exactly as difficult to renumber with v6 as it is with v4. I do understand that in a lot of cases where end nodes are autoconfiguring based on RA it makes it easy but in many places that really isn't an option.
On Sun, Oct 31, 2010 at 3:10 PM, David Conrad <drc@virtualized.org> wrote:
On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote:
"If Woody had gone straight to a ULA prefix, this would never have happened..." Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent.
Seems to me the options are:
1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat
Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell.
My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers.
That would seem to leave (3).
Am I missing an option?
I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense. 2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?' -chris
On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Oct 31, 2010 at 3:10 PM, David Conrad <drc@virtualized.org> wrote:
On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote:
"If Woody had gone straight to a ULA prefix, this would never have happened..." Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent.
Seems to me the options are:
1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat
Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell.
My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers.
That would seem to leave (3).
Am I missing an option?
I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense.
Surely your not saying "we ought to make getting PI easy, easy enough that the other options just don't make sense" so that all residential users get PI so that if their ISP disappears their network doesn't break? Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks. In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6. For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for your internal networks reduces their reliability and availability. In this common case of PA, how are you going to justify that "no IPv6 without an IPv6 ISP" view to people who are very remote, such that even intermittent Internet access is very occasional; to people who run IPv6 sensor networks and don't ever want them connected to the Internet; or 3rd world countries where just local connectivity provides a very significant benefit, when global connectivity just isn't affordable? These and similar are cases where only ISP PA or PI aren't acceptable. Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional.
2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?'
There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon going to be a way to distribute it via DHCPv6 if the defaults don't suit - http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09 Regards, Mark.
Surely your not saying "we ought to make getting PI easy, easy enough that the other options just don't make sense" so that all residential users get PI so that if their ISP disappears their network doesn't break?
I've seen this last point come up a few times, and I really don't get it. If you're multihomed with multiple PA GUAs, yes, you'd want each RA to track its corresponding WAN availability so your devices are using a prefix that has connectivity. If you're a single-homed leaf network, why on earth wouldn't you want to generate RAs for your statically-assigned prefix all the time, regardless of the state of your WAN connection? Regards, Tim.
On Mon, 1 Nov 2010 10:24:31 +0000 (GMT) Tim Franklin <tim@pelican.org> wrote:
Surely your not saying "we ought to make getting PI easy, easy enough that the other options just don't make sense" so that all residential users get PI so that if their ISP disappears their network doesn't break?
I've seen this last point come up a few times, and I really don't get it.
If you're multihomed with multiple PA GUAs, yes, you'd want each RA to track its corresponding WAN availability so your devices are using a prefix that has connectivity.
If you're a single-homed leaf network, why on earth wouldn't you want to generate RAs for your statically-assigned prefix all the time, regardless of the state of your WAN connection?
This isn't to do with anything low level like RAs. This is about people proposing every IPv6 end-site gets PI i.e. a default free zone with multiple billions of routes instead of using ULAs for internal, stable addressing. It's as though they're not aware that the majority of end-sites on the Internet are residential ones, and that PI can scale to that number of end-sites. I can't see any other way to interpret "we ought to make getting PI easy, easy enough that the other options just don't make sense". Regards, Mark.
On Nov 1, 2010, at 9:07 AM, Mark Smith wrote:
On Mon, 1 Nov 2010 10:24:31 +0000 (GMT) Tim Franklin <tim@pelican.org> wrote:
Surely your not saying "we ought to make getting PI easy, easy enough that the other options just don't make sense" so that all residential users get PI so that if their ISP disappears their network doesn't break?
I've seen this last point come up a few times, and I really don't get it.
If you're multihomed with multiple PA GUAs, yes, you'd want each RA to track its corresponding WAN availability so your devices are using a prefix that has connectivity.
If you're a single-homed leaf network, why on earth wouldn't you want to generate RAs for your statically-assigned prefix all the time, regardless of the state of your WAN connection?
This isn't to do with anything low level like RAs. This is about people proposing every IPv6 end-site gets PI i.e. a default free zone with multiple billions of routes instead of using ULAs for internal, stable addressing. It's as though they're not aware that the majority of end-sites on the Internet are residential ones, and that PI can scale to that number of end-sites. I can't see any other way to interpret "we ought to make getting PI easy, easy enough that the other options just don't make sense".
Making it easy enough to get PI that anyone who wants it can get it will not result in most residential customers choosing to go with PI. Most residential customers will continue with PA. This discussion was originally about businesses needing failover between providers which is an environment where I will continue to advocate PI over other solutions. For a single-homed residence that doesn't care, PA will remain easier on multiple levels than PI even if the RIRs were not involved at all. As to the ability to scale PI, that is a deficiency in the current routing paradigm which must be fixed eventually anyway. It's unfortunate that we chose not to address this in IPv6, but, so it is and we are where we are. Hopefully we can find a way to address it without needing another major rev. of the protocol that is application affecting since that's the actual hard part of the IPv6 migration. Owen
Regards, Mark.
On Mon, Nov 1, 2010 at 5:28 AM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Oct 31, 2010 at 3:10 PM, David Conrad <drc@virtualized.org> wrote:
On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote:
"If Woody had gone straight to a ULA prefix, this would never have happened..." Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent.
Seems to me the options are:
1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat
Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell.
My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers.
That would seem to leave (3).
Am I missing an option?
I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense.
Surely your not saying "we ought to make getting PI easy, easy enough that the other options just don't make sense" so that all residential users get PI so that if their ISP disappears their network doesn't break?
all the world is not a corner case... I don't think sane folks are supportive of 'every end site gets pi', I think it's somewhat sane to believe that enterprise type folks can/should be able to get PI space to suit their needs. ULA for enterprises is really not a good solution. Cable/dsl end users can certainly apply for PI space they may even be able to justify an allocation (see owen...) I don't think they'll have much success actually getting a DSL/Cable provider to actually hold the route for them though... so I'm not sure that your pathological case matters here. -chris
On Nov 1, 2010, at 2:28 AM, Mark Smith wrote:
On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Oct 31, 2010 at 3:10 PM, David Conrad <drc@virtualized.org> wrote:
On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote:
"If Woody had gone straight to a ULA prefix, this would never have happened..." Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent.
Seems to me the options are:
1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat
Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell.
My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers.
That would seem to leave (3).
Am I missing an option?
I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense.
Surely your not saying "we ought to make getting PI easy, easy enough that the other options just don't make sense" so that all residential users get PI so that if their ISP disappears their network doesn't break?
He may or may not be. I don't think it's such a bad idea.
Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks.
The upstream valid lifetime doesn't have a lot to do with what happens on the internal network if you're smart.
In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6.
No...PI does not require an available IPv6 ISP connection at all. This is a misstatement that does not become any less false no matter how many times you repeat it.
For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for your internal networks reduces their reliability and availability.
This is also false if you use any form of sanity in applying the assigned PA prefix to your network.
In this common case of PA, how are you going to justify that "no IPv6 without an IPv6 ISP" view to people who are very remote, such that even intermittent Internet access is very occasional; to people who run IPv6 sensor networks and don't ever want them connected to the Internet; or 3rd world countries where just local connectivity provides a very significant benefit, when global connectivity just isn't affordable? These and similar are cases where only ISP PA or PI aren't acceptable.
Nobody is trying to. This is a fallacy of logic that you keep pushing, but, it's still false. If I wire a PA prefix into my router, it doesn't go away just because the ISP does. All that happens is that I can't reach the internet from it, which is kind of true regardless of the address space used at the point where your ISP goes away.
Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional.
Why shouldn't PI if it was easy to get? I still don't understand the perceived advantage of ULA vs. PI other than the perception that it is easier to get. If PI is just as easy to get, why is it a problem?
2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?'
There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon going to be a way to distribute it via DHCPv6 if the defaults don't suit -
http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09
Sure, now, how many applications have been coded to actually pay attention to what getaddrinfo is telling them about address selection order? Owen
On Mon, 1 Nov 2010 09:20:41 -0700 Owen DeLong <owen@delong.com> wrote:
On Nov 1, 2010, at 2:28 AM, Mark Smith wrote:
On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Oct 31, 2010 at 3:10 PM, David Conrad <drc@virtualized.org> wrote:
On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote:
> "If Woody had gone straight to a ULA prefix, this would never have happened..." Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. ula really never should an option... except for a short lived lab, nothing permanent.
Seems to me the options are:
1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat
Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell.
My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers.
That would seem to leave (3).
Am I missing an option?
I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense.
Surely your not saying "we ought to make getting PI easy, easy enough that the other options just don't make sense" so that all residential users get PI so that if their ISP disappears their network doesn't break?
He may or may not be. I don't think it's such a bad idea.
How about algorithmically generating these addresses, so that they're near unique, instead of having the overhead of a central registry, and a global routability expectation?
Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks.
The upstream valid lifetime doesn't have a lot to do with what happens on the internal network if you're smart.
Residential end-users aren't "smart" and aren't network engineers - they pay people like us so that they don't have to be.
In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6.
No...PI does not require an available IPv6 ISP connection at all. This is a misstatement that does not become any less false no matter how many times you repeat it.
What if you don't have an IPv6 ISP connection? Where do you get your PA from? Link local isn't good enough, because it can't span more than a single link. Homes in the future are likely to have multiple networks - visitor segments, multicast segments for video, children segments, 6LowPAN for home sensor networks etc. You've stated you use link locals for this sort of thing, yet you'd be specifying the interface to use as well. That isn't much different to using a subnet number, embedded in the address, to specify either directly attached or remotely reachable subnets. The nice thing about doing it that way is that IPv6 applications are addressing scope agnostic - they just use the address supplied, and ask the underlying OS, which uses the local route table, to direct where the packets go and therefore select the outgoing interface. Link locals + interfaces is more complicated, because now socket options have to be invoked, and only in the case of when a link local address is specified, which also means performing an address type check for the interface option. This code has to be present in ever application, instead of letting the underlying OS taking care of how application packets are directed towards their destinations, and the applications not having to care.
For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for your internal networks reduces their reliability and availability.
This is also false if you use any form of sanity in applying the assigned PA prefix to your network.
I suppose since they don't have the expertise, you could consider residential end-users insane. You can't make the insane sane just by telling them to be so. Preventing their "insanity" from breaking their Internet service, causing them to call your helpdesk, is the sane thing to do. That is achieved by making their Internet service work with the absolute least operational intervention on their part. It's hard enough to get them to enter their username/password via an embedded web server - to the point where some vendors supply setup CDs to automate the discovery of the device, avoiding the end user having to type an IP address URL into their browser.
In this common case of PA, how are you going to justify that "no IPv6 without an IPv6 ISP" view to people who are very remote, such that even intermittent Internet access is very occasional; to people who run IPv6 sensor networks and don't ever want them connected to the Internet; or 3rd world countries where just local connectivity provides a very significant benefit, when global connectivity just isn't affordable? These and similar are cases where only ISP PA or PI aren't acceptable.
Nobody is trying to. This is a fallacy of logic that you keep pushing, but, it's still false. If I wire a PA prefix into my router, it doesn't go away just because the ISP does. All that happens is that I can't reach the internet from it, which is kind of true regardless of the address space used at the point where your ISP goes away.
You haven't ever tried to get a majority of residential end-users to update their firmware have you? You'll have the same luck getting a majority of them to "wire a PA prefix into" their routers.
Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional.
Why shouldn't PI if it was easy to get? I still don't understand the perceived advantage of ULA vs. PI other than the perception that it is easier to get. If PI is just as easy to get, why is it a problem?
It seems to me your main criticism of ULAs is that people would expect it to be globally routed if they paid enough money. Now you're saying that if PI is really easy to get, people *won't* have a global routing expectation of PI routability? I certainly would if I was given PI. What would be worse is that this "non-routable" PI won't come out of a specific prefix so that it can easily filtered, unlike ULAs.
2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?'
There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon going to be a way to distribute it via DHCPv6 if the defaults don't suit -
http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09
Sure, now, how many applications have been coded to actually pay attention to what getaddrinfo is telling them about address selection order?
All the ones I use - they all seem to use the first getaddrinfo() response. They should be attempting to successively connect() to all responses in the order that getaddrinfo() returns as connect() failures occur. I don't know if they are (as destination reachability is usually good), however if they aren't, then the application developers haven't used getaddrinfo() correctly. That behaviour wouldn't be exclusive to IPv6 though - IPv4 applications should also be attempting to connect() to successive addresses when multiple are returned. IOW, applications coping with multiple responses to getaddrinfo() is not an exclusive issue to IPv6. I actually override the current default IPv6 address rules. Here's my /etc/gai.conf, which makes ULAs override GUAs as that currently isn't in the default address selection rules, and makes tunnelled IPv6 preferred over native IPv4, as I don't currently have native IPv6. The MRS entries are the non-defaults, the rest are from the gai.conf manual page. -- # Used for selecting source addresses # # label <prefix> <label> # label ::1/128 0 label ::/0 1 label 2002::/16 2 label 2000::/3 2 # MRS label ::/96 3 label ::ffff:0:0/96 4 label fc00::/7 5 # ULA - MRS # Used for sorting destination addresses # # precedence <prefix> <precedence> # precendence ::1/128 50 precendence ::/0 40 precendence fc00::/7 35 # ULA - MRS precendence 2000::/3 30 # MRS precendence 2002::/16 30 precendence ::/96 20 precendence ::ffff:0:0/96 10 --
Hi,
2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?'
There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon going to be a way to distribute it via DHCPv6 if the defaults don't suit -
http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09
I'm a co-author of this draft. The draft was redirected to 6man wg at IETF, and has a filename: draft-fujisaki-6man-addr-select-opt-00 Unfortunately, I cannot declare it's gonna be ready soon. This proposal has been hanging in the air for long time without any remarkable progress. IMO, this is mainly due to lack of interests on this kind of issues, and lack of operator's perspective on it. I'm glad if anyone could make comments to the 6man list. Best regards,
Sure, now, how many applications have been coded to actually pay attention to what getaddrinfo is telling them about address selection order?
All the ones I use - they all seem to use the first getaddrinfo() response. They should be attempting to successively connect() to all responses in the order that getaddrinfo() returns as connect() failures occur. I don't know if they are (as destination reachability is usually good), however if they aren't, then the application developers haven't used getaddrinfo() correctly. That behaviour wouldn't be exclusive to IPv6 though - IPv4 applications should also be attempting to connect() to successive addresses when multiple are returned. IOW, applications coping with multiple responses to getaddrinfo() is not an exclusive issue to IPv6.
I actually override the current default IPv6 address rules. Here's my /etc/gai.conf, which makes ULAs override GUAs as that currently isn't in the default address selection rules, and makes tunnelled IPv6 preferred over native IPv4, as I don't currently have native IPv6. The MRS entries are the non-defaults, the rest are from the gai.conf manual page.
-- # Used for selecting source addresses # # label <prefix> <label> # label ::1/128 0 label ::/0 1 label 2002::/16 2
label 2000::/3 2 # MRS
label ::/96 3 label ::ffff:0:0/96 4
label fc00::/7 5 # ULA - MRS
# Used for sorting destination addresses # # precedence <prefix> <precedence> # precendence ::1/128 50 precendence ::/0 40
precendence fc00::/7 35 # ULA - MRS
precendence 2000::/3 30 # MRS
precendence 2002::/16 30 precendence ::/96 20 precendence ::ffff:0:0/96 10 --
On Tue, 02 Nov 2010 03:46:55 +1030, Mark Smith said:
How about algorithmically generating these addresses, so that they're near unique, instead of having the overhead of a central registry, and a global routability expectation?
Go re-read RFC4193, section 3.2.3: 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. Works great if you're creating a conglomerate of even a few thousand private networks that would otherwise have been RFC1918 collision city. Global usage is another story. Last week's 'Weekly Routing Table' posting listed 332,569. Feel free to do the computation above for 300K networks and let us know how you'd feel about debugging the resulting routing table.
He may or may not be. I don't think it's such a bad idea.
How about algorithmically generating these addresses, so that they're near unique, instead of having the overhead of a central registry, and a global routability expectation?
Why not just keep a low-overhead central registry and start accepting that PI != global routability. Routability is a discussion between the resource holder and their ISP(s). ULA is the algorithmically generated problem and I think it's a generally bad idea. It's basically an expectation of uniqueness where it may or may not exist and the potential to fudge the level of routability into whatever strange definition long-term creativity may evolve. I think it's better to make GUA easy to get and remove the expectation that GUA == Routable. (Ideally, we'd restore that eventually with a scalable routing paradigm).
Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks.
The upstream valid lifetime doesn't have a lot to do with what happens on the internal network if you're smart.
Residential end-users aren't "smart" and aren't network engineers - they pay people like us so that they don't have to be.
That still doesn't have a lot to do with enterprise failover which is what we were talking about. As to residential, residential end users mostly don't care if their network goes down when their provider goes away. However, for those that do, it still shouldn't be hard for the provider to uncouple circuit viability from address presence.
In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6.
No...PI does not require an available IPv6 ISP connection at all. This is a misstatement that does not become any less false no matter how many times you repeat it.
What if you don't have an IPv6 ISP connection? Where do you get your PA from? Link local isn't good enough, because it can't span more than a single link. Homes in the future are likely to have multiple networks - visitor segments, multicast segments for video, children segments, 6LowPAN for home sensor networks etc.
It gets configured in your router. Why is that such a difficult concept? Your home gateway that talks to your internet connection can either get it via DHCP-PD or static configuration. Either way, it could (should?) be set up to hold the prefix until it gets told something different, possibly even past the advertised valid time. It can delegate subnets using DHCP-PD, but, the point is that the top level router at the site can easily be coded/configured to keep the prefix regardless of the state of the external link.
You've stated you use link locals for this sort of thing, yet you'd be specifying the interface to use as well. That isn't much different to using a subnet number, embedded in the address, to specify either directly attached or remotely reachable subnets. The nice thing about doing it that way is that IPv6 applications are addressing scope agnostic - they just use the address supplied, and ask the underlying OS, which uses the local route table, to direct where the packets go and therefore select the outgoing interface. Link locals + interfaces is more complicated, because now socket options have to be invoked, and only in the case of when a link local address is specified, which also means performing an address type check for the interface option. This code has to be present in ever application, instead of letting the underlying OS taking care of how application packets are directed towards their destinations, and the applications not having to care.
No, I've stated that you could. I have stated that I use link locals for a variety of things. Usually for this type of thing, I'd use a legitimate GUA prefix whether PI or PA.
For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for your internal networks reduces their reliability and availability.
This is also false if you use any form of sanity in applying the assigned PA prefix to your network.
I suppose since they don't have the expertise, you could consider residential end-users insane. You can't make the insane sane just by telling them to be so. Preventing their "insanity" from breaking their Internet service, causing them to call your helpdesk, is the sane thing to do. That is achieved by making their Internet service work with the absolute least operational intervention on their part. It's hard enough to get them to enter their username/password via an embedded web server - to the point where some vendors supply setup CDs to automate the discovery of the device, avoiding the end user having to type an IP address URL into their browser.
Sure, but, why can't you set it up so that you either ship them pre-configured hardware, have their hardware download it's configuration once each time the CONFIGURATION MASTER RESET button is pushed, or, having the hardware learn the configuration via DHCP-PD, but, keeping the configuration until a newer configuration is received? All of these provide zero-user-intervention ways to configure their equipment such that they will have a valid PA address locally that survives a link failure.
In this common case of PA, how are you going to justify that "no IPv6 without an IPv6 ISP" view to people who are very remote, such that even intermittent Internet access is very occasional; to people who run IPv6 sensor networks and don't ever want them connected to the Internet; or 3rd world countries where just local connectivity provides a very significant benefit, when global connectivity just isn't affordable? These and similar are cases where only ISP PA or PI aren't acceptable.
Nobody is trying to. This is a fallacy of logic that you keep pushing, but, it's still false. If I wire a PA prefix into my router, it doesn't go away just because the ISP does. All that happens is that I can't reach the internet from it, which is kind of true regardless of the address space used at the point where your ISP goes away.
You haven't ever tried to get a majority of residential end-users to update their firmware have you? You'll have the same luck getting a majority of them to "wire a PA prefix into" their routers.
Why do they have to wire it in? Why can't I wire it in for them? I know lots of companies that maintain control of the top-level CPE router for just this reason.
Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional.
Why shouldn't PI if it was easy to get? I still don't understand the perceived advantage of ULA vs. PI other than the perception that it is easier to get. If PI is just as easy to get, why is it a problem?
It seems to me your main criticism of ULAs is that people would expect it to be globally routed if they paid enough money. Now you're saying that if PI is really easy to get, people *won't* have a global routing expectation of PI routability? I certainly would if I was given PI. What would be worse is that this "non-routable" PI won't come out of a specific prefix so that it can easily filtered, unlike ULAs.
If you find a provider that will route your PI, no harm done. You're paying enough to get someone to listen to your routes and the internet is accepting them for the time being. At least your PI is subject to policy and the will of the community. ULA, on the other hand, has no community oversight, no policy body, and no restrictions whatsoever on who else uses "your ULA". Yet, through creativity and luck, ULA will eventually get routed across more and more of the internet until it starts to look like cheap easy policy free GUA. At that point, the harm is not about your expectations, the harm is about the failed expectations of the rest of the internet with respect to ULA.
2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?'
There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon going to be a way to distribute it via DHCPv6 if the defaults don't suit -
http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09
Sure, now, how many applications have been coded to actually pay attention to what getaddrinfo is telling them about address selection order?
All the ones I use - they all seem to use the first getaddrinfo() response. They should be attempting to successively connect() to all responses in the order that getaddrinfo() returns as connect() failures occur. I don't know if they are (as destination reachability is usually good), however if they aren't, then the application developers haven't used getaddrinfo() correctly. That behaviour wouldn't be exclusive to IPv6 though - IPv4 applications should also be attempting to connect() to successive addresses when multiple are returned. IOW, applications coping with multiple responses to getaddrinfo() is not an exclusive issue to IPv6.
There are well behaved and not so well behaved applications out there with respect to getaddrinfo. I agree with you about the ideal, but, counting on that is sort of like counting on the user to configure something correctly... Not likely to reduce your help desk calls.
I actually override the current default IPv6 address rules. Here's my /etc/gai.conf, which makes ULAs override GUAs as that currently isn't in the default address selection rules, and makes tunnelled IPv6 preferred over native IPv4, as I don't currently have native IPv6. The MRS entries are the non-defaults, the rest are from the gai.conf manual page.
You do this for your residential customers? It's fun to watch how this discussion gets steered back to enterprise for places where it works better for you as an enterprise, but, residential customers are suddenly the topic when I give an answer that solves the enterprise problem but may not work for residential. Owen
-- # Used for selecting source addresses # # label <prefix> <label> # label ::1/128 0 label ::/0 1 label 2002::/16 2
label 2000::/3 2 # MRS
label ::/96 3 label ::ffff:0:0/96 4
label fc00::/7 5 # ULA - MRS
# Used for sorting destination addresses # # precedence <prefix> <precedence> # precendence ::1/128 50 precendence ::/0 40
precendence fc00::/7 35 # ULA - MRS
precendence 2000::/3 30 # MRS
precendence 2002::/16 30 precendence ::/96 20 precendence ::ffff:0:0/96 10 --
On Mon, 1 Nov 2010 18:04:28 -0700 Owen DeLong <owen@delong.com> wrote:
He may or may not be. I don't think it's such a bad idea.
How about algorithmically generating these addresses, so that they're near unique, instead of having the overhead of a central registry, and a global routability expectation?
Why not just keep a low-overhead central registry and start accepting that PI != global routability. Routability is a discussion between the resource holder and their ISP(s).
ULA is the algorithmically generated problem and I think it's a generally bad idea. It's basically an expectation of uniqueness where it may or may not exist and the potential to fudge the level of routability into whatever strange definition long-term creativity may evolve.
I think it's better to make GUA easy to get and remove the expectation that GUA == Routable. (Ideally, we'd restore that eventually with a scalable routing paradigm).
Is it possible to get GUA from RIRs without making it globally visible? I think the only current exception is IXes. A couple of years back I'd have liked to have gotten a globally unique IPv4 allocation that wasn't being announced globally for use with customer facing DNS servers, reducing their DoS attack surface significantly. Wasn't able to.
Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks.
The upstream valid lifetime doesn't have a lot to do with what happens on the internal network if you're smart.
Residential end-users aren't "smart" and aren't network engineers - they pay people like us so that they don't have to be.
That still doesn't have a lot to do with enterprise failover which is what we were talking about.
As to residential, residential end users mostly don't care if their network goes down when their provider goes away. However, for those that do, it still shouldn't be hard for the provider to uncouple circuit viability from address presence.
In some markets, CPE are sold at the local electronics/white goods store.
In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6.
No...PI does not require an available IPv6 ISP connection at all. This is a misstatement that does not become any less false no matter how many times you repeat it.
What if you don't have an IPv6 ISP connection? Where do you get your PA from? Link local isn't good enough, because it can't span more than a single link. Homes in the future are likely to have multiple networks - visitor segments, multicast segments for video, children segments, 6LowPAN for home sensor networks etc.
It gets configured in your router.
By whom?
Why is that such a difficult concept?
For me it isn't, but a lot of things are simple to people with the right expertise. For residential customers who don't know what an IP address, I'm sure it is not only difficult but probably for most an impossible concept.
Your home gateway that talks to your internet connection can either get it via DHCP-PD or static configuration. Either way, it could (should?) be set up to hold the prefix until it gets told something different, possibly even past the advertised valid time.
That breaks the IPv6 spec. Preferred and valid lifetimes are there for a reason.
It can delegate subnets using DHCP-PD, but, the point is that the top level router at the site can easily be coded/configured to keep the prefix regardless of the state of the external link.
You've stated you use link locals for this sort of thing, yet you'd be specifying the interface to use as well. That isn't much different to using a subnet number, embedded in the address, to specify either directly attached or remotely reachable subnets. The nice thing about doing it that way is that IPv6 applications are addressing scope agnostic - they just use the address supplied, and ask the underlying OS, which uses the local route table, to direct where the packets go and therefore select the outgoing interface. Link locals + interfaces is more complicated, because now socket options have to be invoked, and only in the case of when a link local address is specified, which also means performing an address type check for the interface option. This code has to be present in ever application, instead of letting the underlying OS taking care of how application packets are directed towards their destinations, and the applications not having to care.
No, I've stated that you could. I have stated that I use link locals for a variety of things.
Usually for this type of thing, I'd use a legitimate GUA prefix whether PI or PA.
That doesn't mean there they only options that will work. I'm guaranteed to have a ULA prefix to solve this problem, because I can generate one myself, and know that it won't collide with a GUA prefix if I get one at a latter date. If I follow the ULA algorithm, it probably also won't collide with any other ULA domains I may interconnect with. I can't be assured of those attributes for a GUA prefix, and may not be able to wait to establish a commercial relationship with an ISP before I get a GUA for use with this purpose.
For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for your internal networks reduces their reliability and availability.
This is also false if you use any form of sanity in applying the assigned PA prefix to your network.
I suppose since they don't have the expertise, you could consider residential end-users insane. You can't make the insane sane just by telling them to be so. Preventing their "insanity" from breaking their Internet service, causing them to call your helpdesk, is the sane thing to do. That is achieved by making their Internet service work with the absolute least operational intervention on their part. It's hard enough to get them to enter their username/password via an embedded web server - to the point where some vendors supply setup CDs to automate the discovery of the device, avoiding the end user having to type an IP address URL into their browser.
Sure, but, why can't you set it up so that you either ship them pre-configured hardware, have their hardware download it's configuration once each time the CONFIGURATION MASTER RESET button is pushed, or, having the hardware learn the configuration via DHCP-PD, but, keeping the configuration until a newer configuration is received?
As I said earlier, CPE isn't always sold or operated by through the ISP the customer will get Internet services from.
All of these provide zero-user-intervention ways to configure their equipment such that they will have a valid PA address locally that survives a link failure.
In this common case of PA, how are you going to justify that "no IPv6 without an IPv6 ISP" view to people who are very remote, such that even intermittent Internet access is very occasional; to people who run IPv6 sensor networks and don't ever want them connected to the Internet; or 3rd world countries where just local connectivity provides a very significant benefit, when global connectivity just isn't affordable? These and similar are cases where only ISP PA or PI aren't acceptable.
Nobody is trying to. This is a fallacy of logic that you keep pushing, but, it's still false. If I wire a PA prefix into my router, it doesn't go away just because the ISP does. All that happens is that I can't reach the internet from it, which is kind of true regardless of the address space used at the point where your ISP goes away.
You haven't ever tried to get a majority of residential end-users to update their firmware have you? You'll have the same luck getting a majority of them to "wire a PA prefix into" their routers.
Why do they have to wire it in? Why can't I wire it in for them?
I know lots of companies that maintain control of the top-level CPE router for just this reason.
as before.
Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional.
Why shouldn't PI if it was easy to get? I still don't understand the perceived advantage of ULA vs. PI other than the perception that it is easier to get. If PI is just as easy to get, why is it a problem?
It seems to me your main criticism of ULAs is that people would expect it to be globally routed if they paid enough money. Now you're saying that if PI is really easy to get, people *won't* have a global routing expectation of PI routability? I certainly would if I was given PI. What would be worse is that this "non-routable" PI won't come out of a specific prefix so that it can easily filtered, unlike ULAs.
If you find a provider that will route your PI, no harm done. You're paying enough to get someone to listen to your routes and the internet is accepting them for the time being.
At least your PI is subject to policy and the will of the community.
ULA, on the other hand, has no community oversight, no policy body, and no restrictions whatsoever on who else uses "your ULA". Yet, through creativity and luck, ULA will eventually get routed across more and more of the internet until it starts to look like cheap easy policy free GUA. At that point, the harm is not about your expectations, the harm is about the failed expectations of the rest of the internet with respect to ULA.
I think you under estimate the value of free. With GUA addresses you get free global routability. With ULAs you don't. Why would a network choose to only use ULAs and then try to force upstreams to route it by writing out big cheques (checks), when instantly and persistently globally routable GUA either comes for free with the Internet service, or at a much lower cost than trying to make non-globally routable ULA address space routable - that isn't ever assured of being anywhere near as successful in providing global reachability as using GUAs is.
2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?'
There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon going to be a way to distribute it via DHCPv6 if the defaults don't suit -
http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09
Sure, now, how many applications have been coded to actually pay attention to what getaddrinfo is telling them about address selection order?
All the ones I use - they all seem to use the first getaddrinfo() response. They should be attempting to successively connect() to all responses in the order that getaddrinfo() returns as connect() failures occur. I don't know if they are (as destination reachability is usually good), however if they aren't, then the application developers haven't used getaddrinfo() correctly. That behaviour wouldn't be exclusive to IPv6 though - IPv4 applications should also be attempting to connect() to successive addresses when multiple are returned. IOW, applications coping with multiple responses to getaddrinfo() is not an exclusive issue to IPv6.
There are well behaved and not so well behaved applications out there with respect to getaddrinfo. I agree with you about the ideal, but, counting on that is sort of like counting on the user to configure something correctly... Not likely to reduce your help desk calls.
With IPv4, the history of applications on the Internet is that they've only tried one connection attempt, due to the nature of gethostbyname(). That has worked very reliably. IOW, that means destination hosts are usually available the majority of the time. So, as I said, ideally applications should try to connect to multiple addresses in turn if multiple addresses are returned. IPv4 history has shown that it isn't actually as important as it may appear to be. Therefore, attempting to connect to each returned address is more of an an optional robustness and resilience mechanism. The need for it in IPv6 might be increased due to the possibility of multiple paths to the destination host, but I don't think it is an all that significant increase. The likelyhood is the first returned address will work most of the time, as it has in IPv4. For highly available services, people choose to put in place mechanisms such as HSRP or VRRP to provide further availability for announced addresses.
I actually override the current default IPv6 address rules. Here's my /etc/gai.conf, which makes ULAs override GUAs as that currently isn't in the default address selection rules, and makes tunnelled IPv6 preferred over native IPv4, as I don't currently have native IPv6. The MRS entries are the non-defaults, the rest are from the gai.conf manual page.
You do this for your residential customers? It's fun to watch how this discussion gets steered back to enterprise for places where it works better for you as an enterprise, but, residential customers are suddenly the topic when I give an answer that solves the enterprise problem but may not work for residential.
The problem is you never seem to qualify your statements by saying "For enterprises, ". You make broad statements without qualification, which can only be interpreted to mean that you think they apply to all IPv6 situations. I know of situations, which I think are relevant to this mailing list, where they don't, which is why I point them out. Regards, Mark.
On Nov 2, 2010, at 3:08 AM, Mark Smith wrote:
On Mon, 1 Nov 2010 18:04:28 -0700 Owen DeLong <owen@delong.com> wrote:
He may or may not be. I don't think it's such a bad idea.
How about algorithmically generating these addresses, so that they're near unique, instead of having the overhead of a central registry, and a global routability expectation?
Why not just keep a low-overhead central registry and start accepting that PI != global routability. Routability is a discussion between the resource holder and their ISP(s).
ULA is the algorithmically generated problem and I think it's a generally bad idea. It's basically an expectation of uniqueness where it may or may not exist and the potential to fudge the level of routability into whatever strange definition long-term creativity may evolve.
I think it's better to make GUA easy to get and remove the expectation that GUA == Routable. (Ideally, we'd restore that eventually with a scalable routing paradigm).
Is it possible to get GUA from RIRs without making it globally visible? I think the only current exception is IXes. A couple of years back I'd have liked to have gotten a globally unique IPv4 allocation that wasn't being announced globally for use with customer facing DNS servers, reducing their DoS attack surface significantly. Wasn't able to.
Depends on what you mean by globally visible. If you mean routed, sure. There is no requirement whatsoever to route your address space and there are specific provisions for non-connected networks to get space. There always have been. If you mean visible in whois, then, IXes are not exempt and there are no actual exceptions for RIR-isssued addresses. If you weren't able to get the space you describe, most likely there was some other problem with your application, or, you did not apply under the correct policy for your situation. (assuming this was an ARIN application. I am not as familiar with the other RIRs policies in this regard).
Recently we've seen somebody (on either nanog or ipv6-ops) proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour outage is unusual for a always connected broadband service, it isn't for intermittently connected nodes and networks.
The upstream valid lifetime doesn't have a lot to do with what happens on the internal network if you're smart.
Residential end-users aren't "smart" and aren't network engineers - they pay people like us so that they don't have to be.
That still doesn't have a lot to do with enterprise failover which is what we were talking about.
As to residential, residential end users mostly don't care if their network goes down when their provider goes away. However, for those that do, it still shouldn't be hard for the provider to uncouple circuit viability from address presence.
In some markets, CPE are sold at the local electronics/white goods store.
So?
In effect people who suggest using PA GUAs or PI for all IPv6 addressing are saying you can't run IPv6 unless you have an available IPv6 ISP connection or you must be able to afford to be able to thrust upon the world occupation of a global route table slot. They're not realistic requirements for all potential users of IPv6.
No...PI does not require an available IPv6 ISP connection at all. This is a misstatement that does not become any less false no matter how many times you repeat it.
What if you don't have an IPv6 ISP connection? Where do you get your PA from? Link local isn't good enough, because it can't span more than a single link. Homes in the future are likely to have multiple networks - visitor segments, multicast segments for video, children segments, 6LowPAN for home sensor networks etc.
It gets configured in your router.
By whom?
Ideally automation. Potentially either the ISP or the end user.
Why is that such a difficult concept?
For me it isn't, but a lot of things are simple to people with the right expertise. For residential customers who don't know what an IP address, I'm sure it is not only difficult but probably for most an impossible concept.
This was intended as a suggestion for enterprise customers that cared about reliable failover between providers. If a residential customer is multi-homing and cares about faling over between two providers, I'm pretty sure they have some expertise. However, this could still be automated even in the case where no expertise is present.
Your home gateway that talks to your internet connection can either get it via DHCP-PD or static configuration. Either way, it could (should?) be set up to hold the prefix until it gets told something different, possibly even past the advertised valid time.
That breaks the IPv6 spec. Preferred and valid lifetimes are there for a reason.
Sure... However, if you have no upstream connectivity there is no harm in hanging on to the prefix until connectivity is restored and you receive an indication that you should do something different from what you are currently doing.
It can delegate subnets using DHCP-PD, but, the point is that the top level router at the site can easily be coded/configured to keep the prefix regardless of the state of the external link.
You've stated you use link locals for this sort of thing, yet you'd be specifying the interface to use as well. That isn't much different to using a subnet number, embedded in the address, to specify either directly attached or remotely reachable subnets. The nice thing about doing it that way is that IPv6 applications are addressing scope agnostic - they just use the address supplied, and ask the underlying OS, which uses the local route table, to direct where the packets go and therefore select the outgoing interface. Link locals + interfaces is more complicated, because now socket options have to be invoked, and only in the case of when a link local address is specified, which also means performing an address type check for the interface option. This code has to be present in ever application, instead of letting the underlying OS taking care of how application packets are directed towards their destinations, and the applications not having to care.
No, I've stated that you could. I have stated that I use link locals for a variety of things.
Usually for this type of thing, I'd use a legitimate GUA prefix whether PI or PA.
That doesn't mean there they only options that will work. I'm guaranteed to have a ULA prefix to solve this problem, because I can generate one myself, and know that it won't collide with a GUA prefix if I get one at a latter date. If I follow the ULA algorithm, it probably also won't collide with any other ULA domains I may interconnect with. I can't be assured of those attributes for a GUA prefix, and may not be able to wait to establish a commercial relationship with an ISP before I get a GUA for use with this purpose.
Huh? You are absolutely guaranteed that a GUA prefix won't collide with anyone else's GUA prefix. You are absolutely guaranteed that it will not collide with anyone else's ULA prefix. You can't generate a GUA yourself, you need to get it from an ISP, and LIR, or an RIR, but, that's the only way to get guaranteed uniqueness.
For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for your internal networks reduces their reliability and availability.
This is also false if you use any form of sanity in applying the assigned PA prefix to your network.
I suppose since they don't have the expertise, you could consider residential end-users insane. You can't make the insane sane just by telling them to be so. Preventing their "insanity" from breaking their Internet service, causing them to call your helpdesk, is the sane thing to do. That is achieved by making their Internet service work with the absolute least operational intervention on their part. It's hard enough to get them to enter their username/password via an embedded web server - to the point where some vendors supply setup CDs to automate the discovery of the device, avoiding the end user having to type an IP address URL into their browser.
Sure, but, why can't you set it up so that you either ship them pre-configured hardware, have their hardware download it's configuration once each time the CONFIGURATION MASTER RESET button is pushed, or, having the hardware learn the configuration via DHCP-PD, but, keeping the configuration until a newer configuration is received?
As I said earlier, CPE isn't always sold or operated by through the ISP the customer will get Internet services from.
So? That doesn't mean what I have proposed can't work. Shipping pre-configured hardware was one of three options I gave above for solving this problem. The other two do not depend on sold or operated by ISP.
All of these provide zero-user-intervention ways to configure their equipment such that they will have a valid PA address locally that survives a link failure.
In this common case of PA, how are you going to justify that "no IPv6 without an IPv6 ISP" view to people who are very remote, such that even intermittent Internet access is very occasional; to people who run IPv6 sensor networks and don't ever want them connected to the Internet; or 3rd world countries where just local connectivity provides a very significant benefit, when global connectivity just isn't affordable? These and similar are cases where only ISP PA or PI aren't acceptable.
Nobody is trying to. This is a fallacy of logic that you keep pushing, but, it's still false. If I wire a PA prefix into my router, it doesn't go away just because the ISP does. All that happens is that I can't reach the internet from it, which is kind of true regardless of the address space used at the point where your ISP goes away.
You haven't ever tried to get a majority of residential end-users to update their firmware have you? You'll have the same luck getting a majority of them to "wire a PA prefix into" their routers.
Why do they have to wire it in? Why can't I wire it in for them?
I know lots of companies that maintain control of the top-level CPE router for just this reason.
as before.
Yes... It's not a one-size fits all solution, it's one way to address one particular problem. I proposed others that are workable in the other situations as well.
Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional.
Why shouldn't PI if it was easy to get? I still don't understand the perceived advantage of ULA vs. PI other than the perception that it is easier to get. If PI is just as easy to get, why is it a problem?
It seems to me your main criticism of ULAs is that people would expect it to be globally routed if they paid enough money. Now you're saying that if PI is really easy to get, people *won't* have a global routing expectation of PI routability? I certainly would if I was given PI. What would be worse is that this "non-routable" PI won't come out of a specific prefix so that it can easily filtered, unlike ULAs.
If you find a provider that will route your PI, no harm done. You're paying enough to get someone to listen to your routes and the internet is accepting them for the time being.
At least your PI is subject to policy and the will of the community.
ULA, on the other hand, has no community oversight, no policy body, and no restrictions whatsoever on who else uses "your ULA". Yet, through creativity and luck, ULA will eventually get routed across more and more of the internet until it starts to look like cheap easy policy free GUA. At that point, the harm is not about your expectations, the harm is about the failed expectations of the rest of the internet with respect to ULA.
I think you under estimate the value of free. With GUA addresses you get free global routability. With ULAs you don't. Why would a network choose to only use ULAs and then try to force upstreams to route it by writing out big cheques (checks), when instantly and persistently globally routable GUA either comes for free with the Internet service, or at a much lower cost than trying to make non-globally routable ULA address space routable - that isn't ever assured of being anywhere near as successful in providing global reachability as using GUAs is.
I don't know. If it weren't for an NDA, I'd give you the names of several companies that you could ask why they chose to try and do this with invalid IPv4 addresses. (IANA reserved free-pool addresses, not even RFC-1918).
2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?'
There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon going to be a way to distribute it via DHCPv6 if the defaults don't suit -
http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09
Sure, now, how many applications have been coded to actually pay attention to what getaddrinfo is telling them about address selection order?
All the ones I use - they all seem to use the first getaddrinfo() response. They should be attempting to successively connect() to all responses in the order that getaddrinfo() returns as connect() failures occur. I don't know if they are (as destination reachability is usually good), however if they aren't, then the application developers haven't used getaddrinfo() correctly. That behaviour wouldn't be exclusive to IPv6 though - IPv4 applications should also be attempting to connect() to successive addresses when multiple are returned. IOW, applications coping with multiple responses to getaddrinfo() is not an exclusive issue to IPv6.
There are well behaved and not so well behaved applications out there with respect to getaddrinfo. I agree with you about the ideal, but, counting on that is sort of like counting on the user to configure something correctly... Not likely to reduce your help desk calls.
With IPv4, the history of applications on the Internet is that they've only tried one connection attempt, due to the nature of gethostbyname(). That has worked very reliably. IOW, that means destination hosts are usually available the majority of the time. So, as I said, ideally applications should try to connect to multiple addresses in turn if multiple addresses are returned. IPv4 history has shown that it isn't actually as important as it may appear to be. Therefore, attempting to connect to each returned address is more of an an optional robustness and resilience mechanism. The need for it in IPv6 might be increased due to the possibility of multiple paths to the destination host, but I don't think it is an all that significant increase. The likelyhood is the first returned address will work most of the time, as it has in IPv4. For highly available services, people choose to put in place mechanisms such as HSRP or VRRP to provide further availability for announced addresses.
Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do. However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main reasons that Google does not publish AAAA records generally today). However, that isn't the issue above. The issue above is about whether or not: getaddrinfo() always returns the addresses to be tried in proper order. Applications are always well behaved in attempting connections in the order returned by getaddrinfo() Whether the deployment of the gal.conf file to hosts in order to give getaddrlinfo() the correct hints about ordering is likely to occur correctly and reliably. etc. There are many dependencies to making source address selection in IPv6 work correctly. They are exacerbated in a ULA environment. If you thought putting a single address (or prefix) into a CPE router by hand was hard, do you really expect the customer to manage a gal.conf file on all their hosts? Seems to me this is much harder than the router configuration.
I actually override the current default IPv6 address rules. Here's my /etc/gai.conf, which makes ULAs override GUAs as that currently isn't in the default address selection rules, and makes tunnelled IPv6 preferred over native IPv4, as I don't currently have native IPv6. The MRS entries are the non-defaults, the rest are from the gai.conf manual page.
You do this for your residential customers? It's fun to watch how this discussion gets steered back to enterprise for places where it works better for you as an enterprise, but, residential customers are suddenly the topic when I give an answer that solves the enterprise problem but may not work for residential.
The problem is you never seem to qualify your statements by saying "For enterprises, ". You make broad statements without qualification, which can only be interpreted to mean that you think they apply to all IPv6 situations. I know of situations, which I think are relevant to this mailing list, where they don't, which is why I point them out.
Fair point. However, so do others in this discussion. I've attempted to align my statements with the users being discussed in the earlier parts of the thread. Qualifying every statement with the covered userbase would be an impractical additional overhead for most people. Owen
In message <CC14FCD0-1924-425A-8879-0C1FA6ADE941@delong.com>, Owen DeLong write s:
On Nov 2, 2010, at 3:08 AM, Mark Smith wrote:
=20 He may or may not be. I don't think it's such a bad idea. =20 =20 How about algorithmically generating these addresses, so that they're near unique, instead of having the overhead of a central registry, and a global routability expectation? =20 Why not just keep a low-overhead central registry and start accepting that PI !=3D global routability. Routability is a discussion between =
On Mon, 1 Nov 2010 18:04:28 -0700 Owen DeLong <owen@delong.com> wrote: =20 the
resource holder and their ISP(s). =20 ULA is the algorithmically generated problem and I think it's a = generally bad idea. It's basically an expectation of uniqueness where it may or may not exist and the potential to fudge the level of routability = into whatever strange definition long-term creativity may evolve. =20 I think it's better to make GUA easy to get and remove the = expectation that GUA =3D=3D Routable. (Ideally, we'd restore that eventually with = a scalable routing paradigm). =20 =20 Is it possible to get GUA from RIRs without making it globally = visible? I think the only current exception is IXes. A couple of years back I'd have liked to have gotten a globally unique IPv4 allocation that = wasn't being announced globally for use with customer facing DNS servers, reducing their DoS attack surface significantly. Wasn't able to. =20 Depends on what you mean by globally visible.
If you mean routed, sure. There is no requirement whatsoever to route your address space and there are specific provisions for non-connected networks to get space. There always have been.
If you mean visible in whois, then, IXes are not exempt and there are no actual exceptions for RIR-isssued addresses.
If you weren't able to get the space you describe, most likely there was some other problem with your application, or, you did not apply under the correct policy for your situation. (assuming this was an ARIN application. I am not as familiar with the other RIRs policies in this regard).
Recently we've seen somebody (on either nanog or ipv6-ops) = proposing to set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 = hour outage is unusual for a always connected broadband service, it = isn't for intermittently connected nodes and networks. =20 The upstream valid lifetime doesn't have a lot to do with what = happens on the internal network if you're smart. =20 =20 Residential end-users aren't "smart" and aren't network engineers - = they pay people like us so that they don't have to be. =20 That still doesn't have a lot to do with enterprise failover which is = what we were talking about. =20 As to residential, residential end users mostly don't care if their = network goes down when their provider goes away. However, for those that do, it still shouldn't be hard for the provider to uncouple circuit = viability from address presence. =20 =20 In some markets, CPE are sold at the local electronics/white goods store. =20 So?
In effect people who suggest using PA GUAs or PI for all IPv6 = addressing are saying you can't run IPv6 unless you have an available IPv6 = ISP connection or you must be able to afford to be able to thrust upon = the world occupation of a global route table slot. They're not = realistic requirements for all potential users of IPv6.=20 =20 No...PI does not require an available IPv6 ISP connection at all. = This is a misstatement that does not become any less false no matter how many times you repeat it. =20 =20 What if you don't have an IPv6 ISP connection? Where do you get your = PA from? Link local isn't good enough, because it can't span more than = a single link. Homes in the future are likely to have multiple = networks - visitor segments, multicast segments for video, children segments, 6LowPAN for home sensor networks etc. =20 It gets configured in your router. =20 By whom? =20 Ideally automation. Potentially either the ISP or the end user.
Why is that such a difficult concept? =20 For me it isn't, but a lot of things are simple to people with the right expertise. For residential customers who don't know what an IP address, I'm sure it is not only difficult but probably for most an=20 impossible concept. =20 This was intended as a suggestion for enterprise customers that cared about reliable failover between providers. If a residential customer is multi-homing and cares about faling over between two providers, I'm pretty sure they have some expertise.
However, this could still be automated even in the case where no expertise is present.
Your home gateway that talks to your internet connection can either get it via DHCP-PD or static configuration. Either way, it could = (should?) be set up to hold the prefix until it gets told something different, = possibly even past the advertised valid time. =20 That breaks the IPv6 spec. Preferred and valid lifetimes are there for a reason. =20 Sure... However, if you have no upstream connectivity there is no harm in hanging on to the prefix until connectivity is restored and you = receive an indication that you should do something different from what you are currently doing.
You've stated you use link locals for this sort of thing, yet you'd = be specifying the interface to use as well. That isn't much different = to using a subnet number, embedded in the address, to specify either directly attached or remotely reachable subnets. The nice thing = about doing it that way is that IPv6 applications are addressing scope agnostic - they just use the address supplied, and ask the underlying OS, which uses the local route table, to direct where the packets go and therefore select the outgoing = interface. Link locals + interfaces is more complicated, because now socket options have to be invoked, and only in the case of when a link = local address is specified, which also means performing an address type = check for the interface option. This code has to be present in ever application, instead of letting the underlying OS taking care of how application packets are directed towards their destinations, and the applications not having to care. =20 No, I've stated that you could. I have stated that I use link locals = for a variety of things. =20 Usually for this type of thing, I'd use a legitimate GUA prefix = whether PI or PA. =20 That doesn't mean there they only options that will work. I'm guaranteed to have a ULA prefix to solve this problem, because I can generate one myself, and know that it won't collide with a GUA prefix if I get one at a latter date. If I follow the ULA algorithm, it
It can delegate subnets using DHCP-PD, but, the point is that the top level router at the site can easily be coded/configured to keep the prefix regardless of the state = of the external link. =20 probably also won't collide with any other ULA domains I may interconnect with. I can't be assured of those attributes for a GUA prefix, and may not be able to wait to establish a commercial relationship with an ISP before I get a GUA for use with this purpose. =20 Huh? You are absolutely guaranteed that a GUA prefix won't collide with anyone else's GUA prefix. You are absolutely guaranteed that it will not collide with anyone else's ULA prefix. You can't generate a GUA yourself, you need to get it from an ISP, and LIR, or an RIR, but, = that's the only way to get guaranteed uniqueness.
For the most common and scalable case of PA, external addressing dependencies reduce reliability, because you can't control them. Completely relying on external connectivity and addressing for = your internal networks reduces their reliability and availability. =20 This is also false if you use any form of sanity in applying the = assigned PA prefix to your network. =20 =20 I suppose since they don't have the expertise, you could consider residential end-users insane. You can't make the insane sane just by telling them to be so. Preventing their "insanity" from breaking =
Internet service, causing them to call your helpdesk, is the sane thing to do. That is achieved by making their Internet service work with the absolute least operational intervention on their part. It's hard enough to get them to enter their username/password via an embedded web server - to the point where some vendors supply setup = CDs to automate the discovery of the device, avoiding the end user = having to type an IP address URL into their browser. =20 Sure, but, why can't you set it up so that you either ship them =
=20 =20 their pre-configured hardware, have their hardware download it's configuration once each = time the CONFIGURATION MASTER RESET button is pushed, or, having the hardware learn the configuration via DHCP-PD, but, keeping the = configuration until a newer configuration is received? =20 =20 As I said earlier, CPE isn't always sold or operated by through the = ISP the customer will get Internet services from. =20 So? That doesn't mean what I have proposed can't work. Shipping pre-configured hardware was one of three options I gave above for solving this problem. The other two do not depend on sold or operated by ISP.
In this common case of PA, how are you going to justify that "no = IPv6 without an IPv6 ISP" view to people who are very remote, such that = even intermittent Internet access is very occasional; to people who run = IPv6 sensor networks and don't ever want them connected to the = Internet; or 3rd world countries where just local connectivity provides a very significant benefit, when global connectivity just isn't = affordable? These and similar are cases where only ISP PA or PI aren't = acceptable. =20 Nobody is trying to. This is a fallacy of logic that you keep =
but, it's still false. If I wire a PA prefix into my router, it = doesn't go away just because the ISP does. All that happens is that I can't reach the internet from it, which is kind of true regardless of the address space used at the point where your ISP goes away. =20 =20 You haven't ever tried to get a majority of residential end-users to update their firmware have you? You'll have the same luck getting = a majority of them to "wire a PA prefix into" their routers.=20 =20 Why do they have to wire it in? Why can't I wire it in for them? =20 I know lots of companies that maintain control of the top-level CPE = router for just this reason. =20 =20 as before. =20 Yes... It's not a one-size fits all solution, it's one way to address = one particular
All of these provide zero-user-intervention ways to configure their equipment such that they will have a valid PA address locally that survives a link failure. =20 pushing, problem.
I proposed others that are workable in the other situations as well.
Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither = should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly = only occasional. =20 Why shouldn't PI if it was easy to get? I still don't understand = the perceived advantage of ULA vs. PI other than the perception that it is easier to get. If PI is just as easy to get, why is it a = problem? =20 =20 It seems to me your main criticism of ULAs is that people would = expect it to be globally routed if they paid enough money. Now you're = saying that if PI is really easy to get, people *won't* have a global = routing expectation of PI routability? I certainly would if I was given PI. What would be worse is that this "non-routable" PI won't come out of = a specific prefix so that it can easily filtered, unlike ULAs. =20 If you find a provider that will route your PI, no harm done. You're = paying enough to get someone to listen to your routes and the internet is accepting them for the time being. =20 At least your PI is subject to policy and the will of the community. =20 ULA, on the other hand, has no community oversight, no policy body, and no restrictions whatsoever on who else uses "your ULA". Yet, through creativity and luck, ULA will eventually get routed across more and more of the internet until it starts to look like cheap easy policy free GUA. At that point, the harm is not about your = expectations, the harm is about the failed expectations of the rest of the internet with respect to ULA. =20 =20 I think you under estimate the value of free. With GUA addresses you = get free global routability. With ULAs you don't. Why would a network choose to only use ULAs and then try to force upstreams to route it by writing out big cheques (checks), when instantly and persistently globally routable GUA either comes for free with the Internet service, or at a much lower cost than trying to make non-globally routable ULA address space routable - that isn't ever assured of being anywhere near as successful in providing global reachability as using GUAs is. =20 I don't know. If it weren't for an NDA, I'd give you the names of = several companies that you could ask why they chose to try and do this with invalid IPv4 addresses. (IANA reserved free-pool addresses, not even RFC-1918).
=20 http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09 =20 Sure, now, how many applications have been coded to actually pay attention to what getaddrinfo is telling them about address selection order? =20 =20 All the ones I use - they all seem to use the first getaddrinfo() response. They should be attempting to successively connect() to all responses in the order that getaddrinfo() returns as connect() failures occur. I don't know if they are (as destination = reachability is usually good), however if they aren't, then the application developers haven't used getaddrinfo() correctly. That behaviour wouldn't be exclusive to IPv6 though - IPv4 applications should also = be attempting to connect() to successive addresses when multiple are returned. IOW, applications coping with multiple responses to getaddrinfo() is not an exclusive issue to IPv6. =20 There are well behaved and not so well behaved applications out there with respect to getaddrinfo. I agree with you about the ideal, but, counting on that is sort of like counting on the user to = configure something correctly... Not likely to reduce your help desk calls. =20 =20 With IPv4, the history of applications on the Internet is that they've only tried one connection attempt, due to the nature of gethostbyname(). That has worked very reliably. IOW, that means destination hosts are usually available the majority of the = time. So, as I said, ideally applications should try to connect to multiple addresses in turn if multiple addresses are returned. IPv4 history has shown that it isn't actually as important as it may appear to be. Therefore, attempting to connect to each returned address is more of an an optional robustness and resilience mechanism. The need for it in IPv6 might be increased due to the possibility of multiple paths to the destination host, but I don't think it is an all that significant increase. The likelyhood is the first returned address will work most of the time, as it has in IPv4. For highly available services, people choose to put in place mechanisms such as HSRP or VRRP to provide further availability for announced addresses. =20 Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do.
=20
> 2) ULA brings with it (as do any options that include multiple > addresses) host-stack complexity and address-selection issues... = 'do I > use ULA here or GUA when talking to the remote host?' >=20 =20 There's an app for that (or rather a library routine called getaddrinfo() and an optional table it consults), and there's soon = going to be a way to distribute it via DHCPv6 if the defaults don't suit =
However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main = reasons that Google does not publish AAAA records generally today).
However, that isn't the issue above. The issue above is about whether or not: getaddrinfo() always returns the addresses to be tried in proper order. Applications are always well behaved in attempting connections in the order returned by getaddrinfo() Whether the deployment of the gal.conf file to hosts in order to give getaddrlinfo() the correct hints about ordering is likely to occur correctly and reliably. etc.
There are many dependencies to making source address selection in IPv6 work correctly. They are exacerbated in a ULA environment. If you thought putting a single address (or prefix) into a CPE router by hand was hard, do you really expect the customer to manage a gal.conf file on all their hosts? Seems to me this is much harder than the router configuration.
You do realise that it is easy to do completly automate this as ULA come from a well defined address block. A simple tool can generate this for the older machines which haven't been updated to know about ULAs If you have a interface configured with a ULA address. Take that address, generate two entries. One for /48 and one for the /64. Preference the ULA/64 addresses first (link). Preference the ULA/48 addresses next (site). Preference the PA/PI/6to4/64 addresses next (link). Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a good way to distribute the site size other than /48 for PA/PI). Preference 2000::/3 next. Preference 2002::/16 next. [2000::/3 2002::/16 reverse order if you don't have any non-ULAs outside of 2002::/16] Preference fc00::/7 last. For ULA/64 destination select a source address from the corresponding ULA/64. For ULA/48 destination select a source address from the corresponding ULA/48. For PA/PI/6to4/64 destination addresses select a source address from the corresponding PA/PI/6to4/64. For PA/PI/6to4/48 destination addresses select a source address from the corresponding PA/PI/6to4/48. For 6to4 destination addresses not already handled select a 6to4 address if available then a PA/PI source address and ULA address last. For 2000::/2 destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last. For ULA destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last. Now is that really so hard? I'm not sure where the IETF is with revising the default address selection rules but ULA came out after the first set of rules was published so it needs to be taken into account if it hasn't already been. If you are merging two sites you just extend the ULA of one to cover the other as well then slowly deprecate the other or tweak the rules above and distribute them via DHCP.
I actually override the current default IPv6 address rules. Here's my /etc/gai.conf, which makes ULAs override GUAs as that currently isn't in the default address selection rules, and makes tunnelled = IPv6 preferred over native IPv4, as I don't currently have native IPv6. = The MRS entries are the non-defaults, the rest are from the gai.conf = manual page. =20 You do this for your residential customers? It's fun to watch how = this discussion gets steered back to enterprise for places where it works better for you as an enterprise, but, residential customers are = suddenly the topic when I give an answer that solves the enterprise problem = but may not work for residential. =20 =20 The problem is you never seem to qualify your statements by saying "For enterprises, ". You make broad statements without qualification, which can only be interpreted to mean that you think they apply to all IPv6 situations. I know of situations, which I think are relevant to this mailing list, where they don't, which is why I point them out. =20 Fair point. However, so do others in this discussion. I've attempted to align my statements with the users being discussed in the earlier parts of the thread. Qualifying every statement with the covered userbase would be an impractical additional overhead for most people.
Owen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
<massive snip>
Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do.
However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main = reasons that Google does not publish AAAA records generally today).
However, that isn't the issue above. The issue above is about whether or not: getaddrinfo() always returns the addresses to be tried in proper order. Applications are always well behaved in attempting connections in the order returned by getaddrinfo() Whether the deployment of the gal.conf file to hosts in order to give getaddrlinfo() the correct hints about ordering is likely to occur correctly and reliably. etc.
There are many dependencies to making source address selection in IPv6 work correctly. They are exacerbated in a ULA environment. If you thought putting a single address (or prefix) into a CPE router by hand was hard, do you really expect the customer to manage a gal.conf file on all their hosts? Seems to me this is much harder than the router configuration.
You do realise that it is easy to do completly automate this as ULA come from a well defined address block. A simple tool can generate this for the older machines which haven't been updated to know about ULAs
Sure, or, you can use PI without ULA and not need to develop a tool.
If you have a interface configured with a ULA address. Take that address, generate two entries. One for /48 and one for the /64.
Preference the ULA/64 addresses first (link). Preference the ULA/48 addresses next (site). Preference the PA/PI/6to4/64 addresses next (link). Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a good way to distribute the site size other than /48 for PA/PI). Preference 2000::/3 next. Preference 2002::/16 next. [2000::/3 2002::/16 reverse order if you don't have any non-ULAs outside of 2002::/16] Preference fc00::/7 last.
For ULA/64 destination select a source address from the corresponding ULA/64. For ULA/48 destination select a source address from the corresponding ULA/48. For PA/PI/6to4/64 destination addresses select a source address from the corresponding PA/PI/6to4/64. For PA/PI/6to4/48 destination addresses select a source address from the corresponding PA/PI/6to4/48. For 6to4 destination addresses not already handled select a 6to4 address if available then a PA/PI source address and ULA address last. For 2000::/2 destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last. For ULA destination addresses not already handled select a PA/PI source address then 6to4 addres and ULA address last.
Now is that really so hard?
It just took you 20+ lines to describe the process in english without producing a single line of code. PI without ULA strikes me as being a lot less complicated.
I'm not sure where the IETF is with revising the default address selection rules but ULA came out after the first set of rules was published so it needs to be taken into account if it hasn't already been.
It doesn't matter where the IETF is. What matters is how many systems are deployed with what address selection rules and how long they would take to change if IETF ever did make up their mind on new standards.
If you are merging two sites you just extend the ULA of one to cover the other as well then slowly deprecate the other or tweak the rules above and distribute them via DHCP.
Or you use PI and don't worry about it at all. You're making a very good case fro why ULA is vastly inferior to PI. Owen
In message <2CE5A700-EB60-453F-85CF-5E679E94EE4C@delong.com>, Owen DeLong write s:
<massive snip>
=20 Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do. =20 However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main =3D reasons that Google does not publish AAAA records generally today). =20 However, that isn't the issue above. The issue above is about whether or not: getaddrinfo() always returns the addresses to be tried in proper order. Applications are always well behaved in attempting connections in the order returned by getaddrinfo() Whether the deployment of the gal.conf file to hosts in order to give getaddrlinfo() the correct hints about ordering is likely to occur correctly and reliably. etc. =20 There are many dependencies to making source address selection in IPv6 work correctly. They are exacerbated in a ULA environment. If you thought putting a single address (or prefix) into a CPE router by hand was hard, do you really expect the customer to manage a gal.conf file on all their hosts? Seems to me this is much harder than the router configuration. =20 You do realise that it is easy to do completly automate this as ULA come from a well defined address block. A simple tool can generate this for the older machines which haven't been updated to know about ULAs =20 Sure, or, you can use PI without ULA and not need to develop a tool.
Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA. If you can get PI *and* get it routed then yes PI is the way to go. PA alone is also not the way to go.
If you have a interface configured with a ULA address. Take that address, generate two entries. One for /48 and one for the /64. =20 Preference the ULA/64 addresses first (link).=20 Preference the ULA/48 addresses next (site). Preference the PA/PI/6to4/64 addresses next (link). Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a = good way to distribute the site size other than /48 for PA/PI). Preference 2000::/3 next.=20 Preference 2002::/16 next. [2000::/3 2002::/16 reverse order if you don't have any non-ULAs = outside of 2002::/16] Preference fc00::/7 last. =20 For ULA/64 destination select a source address from the corresponding = ULA/64. For ULA/48 destination select a source address from the corresponding = ULA/48. For PA/PI/6to4/64 destination addresses select a source address from = the corresponding PA/PI/6to4/64. For PA/PI/6to4/48 destination addresses select a source address from = the corresponding PA/PI/6to4/48. For 6to4 destination addresses not already handled select a 6to4 = address if available then a PA/PI source address and ULA address last. For 2000::/2 destination addresses not already handled select a PA/PI = source address then 6to4 addres and ULA address last. For ULA destination addresses not already handled select a PA/PI = source address then 6to4 addres and ULA address last. =20 Now is that really so hard? =20 It just took you 20+ lines to describe the process in english without = producing a single line of code. PI without ULA strikes me as being a lot less complicated.
And PA alone doesn't work well. As for lines of code they won't be many as basically it is just inserting/removing rules when addresses are assigned/removed to/from interfaces.
I'm not sure where the IETF is with revising the default address selection rules but ULA came out after the first set of rules was published so it needs to be taken into account if it hasn't already been.
It doesn't matter where the IETF is. What matters is how many systems are deployed with what address selection rules and how long they would take to change if IETF ever did make up their mind on new standards.
If you are merging two sites you just extend the ULA of one to cover the other as well then slowly deprecate the other or tweak the rules above and distribute them via DHCP.
Or you use PI and don't worry about it at all.
You're making a very good case fro why ULA is vastly inferior to PI.
Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Nov 3, 2010 at 6:43 PM, Mark Andrews <marka@isc.org> wrote:
Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA.
not everyone's network requires 'routed' ... wrt the internet.
On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote:
In message <2CE5A700-EB60-453F-85CF-5E679E94EE4C@delong.com>, Owen DeLong write s:
<massive snip>
=20 Actually, gethostbyname returns a linked-list and applications should try everything in the list until successfully connecting. Most do. =20 However, the long timeouts in the connection attempt process make that a less than ideal solution. (In fact, this is one of the main =3D reasons that Google does not publish AAAA records generally today). =20 However, that isn't the issue above. The issue above is about whether or not: getaddrinfo() always returns the addresses to be tried in proper order. Applications are always well behaved in attempting connections in the order returned by getaddrinfo() Whether the deployment of the gal.conf file to hosts in order to give getaddrlinfo() the correct hints about ordering is likely to occur correctly and reliably. etc. =20 There are many dependencies to making source address selection in IPv6 work correctly. They are exacerbated in a ULA environment. If you thought putting a single address (or prefix) into a CPE router by hand was hard, do you really expect the customer to manage a gal.conf file on all their hosts? Seems to me this is much harder than the router configuration. =20 You do realise that it is easy to do completly automate this as ULA come from a well defined address block. A simple tool can generate this for the older machines which haven't been updated to know about ULAs =20 Sure, or, you can use PI without ULA and not need to develop a tool.
Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA.
It's very easy to get PIv6 routed for free, so, I don't see the issue there.
If you can get PI *and* get it routed then yes PI is the way to go. PA alone is also not the way to go.
OK, so, PI is the way to go, since you can get it routed for free. (If you don't know how, see http://tunnelbroker.net and look for the subject "BGP tunnel")
If you have a interface configured with a ULA address. Take that address, generate two entries. One for /48 and one for the /64. =20 Preference the ULA/64 addresses first (link).=20 Preference the ULA/48 addresses next (site). Preference the PA/PI/6to4/64 addresses next (link). Preference the PA/PI/6to4/48 addresses next (site). (a RA would be a = good way to distribute the site size other than /48 for PA/PI). Preference 2000::/3 next.=20 Preference 2002::/16 next. [2000::/3 2002::/16 reverse order if you don't have any non-ULAs = outside of 2002::/16] Preference fc00::/7 last. =20 For ULA/64 destination select a source address from the corresponding = ULA/64. For ULA/48 destination select a source address from the corresponding = ULA/48. For PA/PI/6to4/64 destination addresses select a source address from = the corresponding PA/PI/6to4/64. For PA/PI/6to4/48 destination addresses select a source address from = the corresponding PA/PI/6to4/48. For 6to4 destination addresses not already handled select a 6to4 = address if available then a PA/PI source address and ULA address last. For 2000::/2 destination addresses not already handled select a PA/PI = source address then 6to4 addres and ULA address last. For ULA destination addresses not already handled select a PA/PI = source address then 6to4 addres and ULA address last. =20 Now is that really so hard? =20 It just took you 20+ lines to describe the process in english without = producing a single line of code. PI without ULA strikes me as being a lot less complicated.
And PA alone doesn't work well.
Where did PA enter into my statement above?
As for lines of code they won't be many as basically it is just inserting/removing rules when addresses are assigned/removed to/from interfaces.
And then distributing those rules to EVERY host (or you have to pre- distribute the script to EVERY host). <snip> Owen
On Wed, 03 Nov 2010 17:01:32 PDT, Owen DeLong said:
On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote:
Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA.
It's very easy to get PIv6 routed for free, so, I don't see the issue there.
It may be very easy to get it routed for free *now*. Will it be possible to get PIv6 routed for free once there's 300K entries in the IPv6 routing table? Or zillions, as everybody and their pet llama start using PI prefixes? (Hey, if you managed to get PI to use instead of using an ULA, and routing it is "free", may as well go for it, right?)
Hello- Would someone with clue within the Verizon team contact me off-list, please? I'm not seeing rDNS entries for "new" fios ip addresses. Regards, Ed Trdina
If you're going to start a new thread on a mailing list your best bet is to copy the list address to your address book, and create a new message. By replying to another message and changing the topic your message shows up "buried" under the thread you replied to. This is particularly bad when you're trying to get someone's attention (as you are here). :) hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
On 11/3/10 6:51 PM, Edward A. Trdina III wrote:
Hello-
Would someone with clue within the Verizon team contact me off-list, please? I'm not seeing rDNS entries for "new" fios ip addresses.
You should probably start a new thread rather than burying your request inside a really long one that someone who could help could be ignoring. (Hint: changing the subject doesn't do that.) ~Seth
On Nov 3, 2010, at 5:21 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 03 Nov 2010 17:01:32 PDT, Owen DeLong said:
On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote:
Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA.
It's very easy to get PIv6 routed for free, so, I don't see the issue there.
It may be very easy to get it routed for free *now*.
Will it be possible to get PIv6 routed for free once there's 300K entries in the IPv6 routing table? Or zillions, as everybody and their pet llama start using PI prefixes? (Hey, if you managed to get PI to use instead of using an ULA, and routing it is "free", may as well go for it, right?)
Hopefully by the time it gets to that point we'll have finally come up with a scaleable routing paradigm. Certainly we need to do that anyway. I'm not sure why we chose not to do that with IPv6 in the first place. Owen
On Thu, Nov 4, 2010 at 1:31 AM, Owen DeLong <owen@delong.com> wrote:
On Nov 3, 2010, at 5:21 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 03 Nov 2010 17:01:32 PDT, Owen DeLong said:
On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote:
Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA.
It's very easy to get PIv6 routed for free, so, I don't see the issue there.
It may be very easy to get it routed for free *now*.
Will it be possible to get PIv6 routed for free once there's 300K entries in the IPv6 routing table? Or zillions, as everybody and their pet llama start using PI prefixes? (Hey, if you managed to get PI to use instead of using an ULA, and routing it is "free", may as well go for it, right?)
Hopefully by the time it gets to that point we'll have finally come up with a scaleable routing paradigm. Certainly we need to do that anyway. I'm not sure why we chose not to do that with IPv6 in the first place.
because: 1) there were only going to be a limited number of ISP's b) every end site gets PA only iii) no need for pi d) all of the above
On Nov 3, 2010, at 11:02 PM, Christopher Morrow wrote:
On Thu, Nov 4, 2010 at 1:31 AM, Owen DeLong <owen@delong.com> wrote:
On Nov 3, 2010, at 5:21 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 03 Nov 2010 17:01:32 PDT, Owen DeLong said:
On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote:
Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA.
It's very easy to get PIv6 routed for free, so, I don't see the issue there.
It may be very easy to get it routed for free *now*.
Will it be possible to get PIv6 routed for free once there's 300K entries in the IPv6 routing table? Or zillions, as everybody and their pet llama start using PI prefixes? (Hey, if you managed to get PI to use instead of using an ULA, and routing it is "free", may as well go for it, right?)
Hopefully by the time it gets to that point we'll have finally come up with a scaleable routing paradigm. Certainly we need to do that anyway. I'm not sure why we chose not to do that with IPv6 in the first place.
because: 1) there were only going to be a limited number of ISP's b) every end site gets PA only iii) no need for pi d) all of the above
I understand how they rationalized the cop-out. Now, getting back to the real world... Owen
oops, I clipped a little too much from the message before replying... On Mon, Nov 1, 2010 at 5:28 AM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional.
I think there are many cases where a 'disconnected' network will want ipv6, I do NOT believe they should use ULA space except in the most extreme cases. It makes more sense to just get these folks a GUA allocation of their proper size, support their DNS and registry needs. I agree that global connectivity should be optional... I've worked on more than one network that had better never see the light of day, and will most likely need (or already has?) ipv6 deployments in the coming months/years. -chris
On 10/31/2010 9:31 AM, Owen DeLong wrote:
Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either.
And he can justify PI when he first deploys IPv6 with a single provider under which policy? (Assume he is in the ARIN region and that his IPv4 space is currently provider-assigned from a couple of different providers and he's using NAT to do his IPv4 failover management) 1. Quite possibly does not qualify for an IPv4 assigned under the current IPv4 policy (certainly not in a few more months, when *nobody* will qualify except for some transition-space requests) 2. Definitely can't show efficient utilization of all direct IPv4 assignments, as he has none. 3. He's not a community network. So he can't go "straight to PI". He either needs to go PA with the first provider, then through renumbering pain (which he knows all too well about from IPv4, and none of the problems like "change the address of the intranet wiki server in the internal DNS servers" change with IPv6), or use something internal like ULA for things he doesn't want to renumber.
If a site is numbering their internal IPv4 stuff to avoid having to renumber on a provider change, then why would they number their IPv6 stuff from provider space rather than ULA space?
Which gains what vs. PI? Nothing, but PI isn't available to him. See above.
And remember - (a) IPv6 allows machine to easily support multiple addresses and (b) if you have a provider address and a ULA, changing providers only means renumbering a *partial* renumber of the hosts that require external visibility - your internal hosts can continue talking to each other on a ULA as if nothing happened.
If you have PI space, changing providers can be even easier and you can leave multiple providers running in parallel.
That's a big IF, given the above. He doesn't qualify for PI space, thanks to ARIN policies set by people who want routing tables to stay as small as possible, so PI space to be as difficult as possible to obtain for people like him. Matthew Kaufman
On Sun, Oct 31, 2010 at 10:26 AM, Matthew Kaufman <matthew@matthew.at> wrote:
On 10/31/2010 9:31 AM, Owen DeLong wrote:
If you have PI space, changing providers can be even easier and you can leave multiple providers running in parallel.
That's a big IF, given the above. He doesn't qualify for PI space, thanks to ARIN policies set by people who want routing tables to stay as small as possible, so PI space to be as difficult as possible to obtain for people like him.
Would it help if ARIN's policies were changed to allow anyone and everyone to obtain PI space directly from them (for the appropriate fee, of course), and then it was left up to the operating community to decide whether or not to route the smaller chunks of space? Right now, we're trying to keep the two communities somewhat in alignment, so that when people obtain IP space, they have a relatively good feeling about it being routed correctly. If we let the ARIN policies stray too far from what the router operators can/will accept, we're going to end up with an ugly, fragmented internet in which organizations are given PI GUA space, only to discover it's not actually useful for reaching large swaths of the internet. I'd hazard a guess that people would consider that to be a worse scenario than the one in which we limit who can get PI space so that there's a reasonably good probability that when the space is issued and announced via BGP, it will be reachable from most of the rest of the internet...that is to say, our current modus operandi.
Matthew Kaufman
Matt
Would it help if ARIN's policies were changed to allow anyone and everyone to obtain PI space directly from them (for the appropriate fee, of course), and then it was left up to the operating community to decide whether or not to route the smaller chunks of space?
I would probably support something like that with a few caveats. One being that we try to keep things as aggregated as possible. If someone grows out of a /48, they get say, a /46 and don't get additional discontiguous /48 nets. Also, we should wait a while to do that. Once a significant portion of traffic has moved to v6, people might want to make decisions to mitigate routing table bloat with v4. Once v6 traffic exceeds v4 traffic, some of those decisions become easier to make (accept v4 routes from peers and shove any other traffic out to transit with a default, for example, rather than take full v4 routes from multiple transit peers.). I might be willing to accept some sub-optimal routing for v4 once v6 exceeds v4. Maybe others would be willing to, as well.
On Oct 31, 2010, at 10:58 AM, Matthew Petach wrote:
On Sun, Oct 31, 2010 at 10:26 AM, Matthew Kaufman <matthew@matthew.at> wrote:
On 10/31/2010 9:31 AM, Owen DeLong wrote:
If you have PI space, changing providers can be even easier and you can leave multiple providers running in parallel.
That's a big IF, given the above. He doesn't qualify for PI space, thanks to ARIN policies set by people who want routing tables to stay as small as possible, so PI space to be as difficult as possible to obtain for people like him.
Would it help if ARIN's policies were changed to allow anyone and everyone to obtain PI space directly from them (for the appropriate fee, of course), and then it was left up to the operating community to decide whether or not to route the smaller chunks of space?
I really don't expect this to be as much of an issue in IPv6.
Right now, we're trying to keep the two communities somewhat in alignment, so that when people obtain IP space, they have a relatively good feeling about it being routed correctly. If we let the ARIN policies stray too far from what the router operators can/will accept, we're going to end up with an ugly, fragmented internet in which organizations are given PI GUA space, only to discover it's not actually useful for reaching large swaths of the internet.
PI GUA is at least as useful in that context as ULA.
I'd hazard a guess that people would consider that to be a worse scenario than the one in which we limit who can get PI space so that there's a reasonably good probability that when the space is issued and announced via BGP, it will be reachable from most of the rest of the internet...that is to say, our current modus operandi.
Not if they are turning to ULA. Owen
On Oct 31, 2010, at 9:01 AM, Owen DeLong wrote:
Would it help if ARIN's policies were changed to allow anyone and everyone to obtain PI space directly from them (for the appropriate fee, of course), and then it was left up to the operating community to decide whether or not to route the smaller chunks of space? I really don't expect this to be as much of an issue in IPv6.
Why would the commercial interests that have driven ISPs to remove long prefix length filters in IPv4 not apply to IPv6? Regards, -drc
On Oct 31, 2010, at 12:12 PM, David Conrad wrote:
On Oct 31, 2010, at 9:01 AM, Owen DeLong wrote:
Would it help if ARIN's policies were changed to allow anyone and everyone to obtain PI space directly from them (for the appropriate fee, of course), and then it was left up to the operating community to decide whether or not to route the smaller chunks of space? I really don't expect this to be as much of an issue in IPv6.
Why would the commercial interests that have driven ISPs to remove long prefix length filters in IPv4 not apply to IPv6?
I don't expect the IPv6 routing table to be long enough to drive prefix filtration in the foreseeable future. Owen
Define long prefix length. Owen has been fairly forceful in his advocacy of /48s at every site. Is this too long a prefix? Should peers only except /32s and shorter? On Sun, Oct 31, 2010 at 1:12 PM, David Conrad <drc@virtualized.org> wrote:
On Oct 31, 2010, at 9:01 AM, Owen DeLong wrote:
Would it help if ARIN's policies were changed to allow anyone and everyone to obtain PI space directly from them (for the appropriate fee, of course), and then it was left up to the operating community to decide whether or not to route the smaller chunks of space? I really don't expect this to be as much of an issue in IPv6.
Why would the commercial interests that have driven ISPs to remove long prefix length filters in IPv4 not apply to IPv6?
Regards, -drc
On 01 Nov 2010 10:08, Jason Iannone wrote:
Define long prefix length. Owen has been fairly forceful in his advocacy of /48s at every site. Is this too long a prefix? Should peers only except /32s and shorter?
One assumes unpaid peers will accept prefixes up to the maximum length the RIR issues for that block, which is currently either /32 (PA) or /48 (PI). Presumably, "long" means any prefix longer than that; paid peers may accept those as well, but one assumes unpaid peers will not. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
One thing to keep in mind is that your IPv6 router and IP router can be completely different devices. There is no need to forklift your firewall or current setup if you can easily add an IPv6 router to the network. Using multiple ISPs is still something that is a bit tricky. A lot of people have gotten used to the Dual-WAN Firewall appliance boxes that accept connections from two ISPs and handle the failover, depending on NAT to maintain the functionality of the Internal network. Larger organizations can arrange to have IPv6 transit and announce a single prefix over BGP. Most providers won't want to see this setup for an SMB so they're out of luck. One thing that has changed, though, is Metro Ethernet offerings have gotten a lot better. I would say the most painless way to go would be to use one ISP for L3, and two ME providers to give diverse L2 paths to that L3 ISP. It means dealing with more companies, and moving failover to L2, but it's pretty rare that the cause of a connection problem is at the ISP these days (it's more often a bad connection between you and the ISP), so just having redundancy at L2 might be enough. Sadly, that model doesn't really exist in the US right now, and it might take quite a bit of work convincing providers to coordinate to make it all work. The other option, which was the intent of IPv6 when being designed (but that was 10 years ago or so) was that every PC would have a separate address from each ISP. In this situation you could depend on ULA (local addressing) for access to all internal services so that if one of the global prefixes goes away it doesn't impact internal operation, but it does require a device to kind of coordinate that- such a device doesn't exist yet, and there are some issues with getting PCs to handle address selection correctly. I suspect if this does happen (and it could, it's not a horrible model) it will take a few more years before it's "easy". It's too bad they axed the site local scope for this kind of environment. For now, I would recommend just going with a single IPv6 provider since I have yet to encounter IPv6-only content that is mission critical. That will at least give you access to the IPv6 internet now, but give the IPv6 market time to come around to meet the needs of SMB and wanting redundancy in IPv6 access. I'm not aware of any appliance that does a good job at IPv6, yet... If it were me I would build up a Linux box as a IPv6 firewall, router, etc. It's really too bad that there isn't such an appliance yet. You could just use a Cisco ISR (like an 1841) as your IPv6 on a stick router, but the problem is that you really want to keep in mind that once you give out global addresses to hosts they're not behind your NAT firewall for IPv6. So you'll want to implement some sort of stateful firewall for IPv6, or enable host-based IPv6 firewalls. We've decided to disable SLAAC (State-Less Address Auto-Configuration) on almost all our IPv6 networks and use DHCPv6 exclusively. This allows us to only respond with DHCPv6 to the hosts we want to get an IPv6 address instead of enabling it network-wide and crossing your fingers. The disadvantage here is that DHCPv6 client support is still limited (OS X has none for example). The argument is that IPv6 isn't mission critical yet, so we're waiting to see if vendors will come around and include DHCPv6 client support in the future. Another thing you want to do is block rogue RA. RA-Guard is the feature name, but nobody has a working implementation yet. If you have switches that can do port-based access-lists with IPv6 you can create ingress filters to block out incoming RA on a per-port basis which is what we have done. It works rather well. On Thu, Oct 21, 2010 at 12:29 PM, Allen Smith <lazlor@lotaris.org> wrote:
Hi All,
I've inherited a small network with a couple of Internet connections through different providers, I'll call them Slow and Fast.
We use RFC 1918 space internally and have a pair of external firewalls that handle NAT and such.
Due to internal policy (read money), some users default to the Slow connection and some default to Fast. Using probes and policy routing, a failure of one of the ISPs is generally transparent, outside of the usual session resets for things like ssh or remote control sessions).
Looking forward to the next 12 months, we may have clients that are living in IPv6 space. Our ISPs are happy to give us IPv6 allocations and our network gear vendors either have GA IPv6 code now or will soon.
We have been somewhat spoiled by our firewall/NAT boxes, the stuff just works for our needs and the combination of NAT and policy routing keeps people on the circuits they are paying for. Am trying to decide how I would implement this kind of policy in the new world of globally trackable^H^H^H^H^H^H^H routable IPs for my desktops. Solutions seem to be:
1) Purchase some BGP capable routers, grab PI space. Here I can obv choose outbound path, but we are typical in that our inbound to outbound is 6 or 7 to 1.
2) Assign PA space from the ISPs to the appropriate devices. What do I do when I loose a provider?
3) Make loud noises to my firewall vendor to include equivalent NAT/ISP failover functionality (even 6to6 NAT would be fine).
Anyway, another sample of 1, but I do work for a managed services provider and see many small orgs facing similary choices. I personally am happy to use globally routable addresses and will work through the privacy and perceived security implications of NAT/nonat, I just want the same ease of use and flexibility I have today in a SMB environment.
Cheers, -Allen
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote:
We've decided to disable SLAAC (State-Less Address Auto-Configuration) on almost all our IPv6 networks and use DHCPv6 exclusively. This allows us to only respond with DHCPv6 to the hosts we want to get an IPv6 address instead of enabling it network-wide and crossing your fingers. The disadvantage here is that DHCPv6 client support is still limited (OS X has none for example). The argument is that IPv6 isn't mission critical yet, so we're waiting to see if vendors will come around and include DHCPv6 client support in the future.
Ray, how do you convey the default-router information with DHCPv6 only. AFAIK there is no such field in DHCPv6... Luca.
I think you're misunderstanding how DHCPv6 works. Don't think of it like DHCP that you're used to. DHCPv6 requires an IPv6 router advertisement to work. There are three flags of interest in a router advertisement. One of them is the "A" (autonomous) flag which is enabled by default in almost every implementation I've seen. This is what signals a host that it is permitted to use stateless configuration with the prefix. There are also "M" (managed) and "O" other flags. The "M" flag being set signals the host that it should start a DHCPv6 client and make a request for an address, the "O" flag signals that the host should ask for "other" or additional configuration information through DHCPv6 (e.g. DNS servers). None of the flags are exclusive, so you can enable DHCPv6 by setting the M flag, but unless you disable the A flag, hosts will still use stateless configuration (in addition to DHCPv6 and receive two addresses) If you want a DHCPv6-only environment, you simply disable the A flag on the router advertisement. This will stop hosts from using stateless with the advertised prefix. The default gateway for the network is learned through the router advertisement, not through DHCPv6, which is why it doesn't exist in DHCPv6. Example IOS configuration: interface Vlan123 description Test IPv6 Network ipv6 address FD00:1234:5678:9ABC::1/64 no ipv6 unreachables ipv6 nd prefix default 2592000 604800 no-autoconfig ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 nd router-preference High no ipv6 redirects ipv6 verify unicast source reachable-via rx ipv6 eigrp 123 ipv6 dhcp relay destination FD00:1234:5678:9ABC::2 ipv6 dhcp relay destination FD00:1234:5678:9ABC::3 The "ipv6 nd prefix ... no-autoconfig" statement is what you're looking for. You need to type out timers to be able to get to it. The values shown are just the Cisco defaults. On Thu, Oct 21, 2010 at 3:43 PM, Luca Tosolini <bit.gossip@chello.nl> wrote:
On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote:
We've decided to disable SLAAC (State-Less Address Auto-Configuration) on almost all our IPv6 networks and use DHCPv6 exclusively. This allows us to only respond with DHCPv6 to the hosts we want to get an IPv6 address instead of enabling it network-wide and crossing your fingers. The disadvantage here is that DHCPv6 client support is still limited (OS X has none for example). The argument is that IPv6 isn't mission critical yet, so we're waiting to see if vendors will come around and include DHCPv6 client support in the future.
Ray, how do you convey the default-router information with DHCPv6 only. AFAIK there is no such field in DHCPv6...
Luca.
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Also, Keep in mind that DHCPv6 uses a DUID for host identification and not a MAC address. Here is an example ISC DHCPd configuration for an IPv6 network without open pool allocation (it will only respond for hosts in the config). # subnet6 for each network subnet6 FD00:1234:5678:9ABC::/64 { option dhcp6.name-servers FD00:1234:5678:9ABC::2, FD00:1234:5678:9ABC::3; } # host for each host host soucy-desktop.domain.net { host-identifier option dhcp6.client-id 00:01:00:01:11:ee:71:12:00:1a:a0:da:ba:7f; fixed-address6 FD00:1234:5678:9ABC::A; } I believe the new version of ISC DHCPd has added code to be able to determine the MAC address instead of using a DUID, but I haven't tested it personally. On Thu, Oct 21, 2010 at 3:59 PM, Ray Soucy <rps@maine.edu> wrote:
I think you're misunderstanding how DHCPv6 works. Don't think of it like DHCP that you're used to.
DHCPv6 requires an IPv6 router advertisement to work. There are three flags of interest in a router advertisement.
One of them is the "A" (autonomous) flag which is enabled by default in almost every implementation I've seen. This is what signals a host that it is permitted to use stateless configuration with the prefix.
There are also "M" (managed) and "O" other flags. The "M" flag being set signals the host that it should start a DHCPv6 client and make a request for an address, the "O" flag signals that the host should ask for "other" or additional configuration information through DHCPv6 (e.g. DNS servers).
None of the flags are exclusive, so you can enable DHCPv6 by setting the M flag, but unless you disable the A flag, hosts will still use stateless configuration (in addition to DHCPv6 and receive two addresses)
If you want a DHCPv6-only environment, you simply disable the A flag on the router advertisement. This will stop hosts from using stateless with the advertised prefix.
The default gateway for the network is learned through the router advertisement, not through DHCPv6, which is why it doesn't exist in DHCPv6.
Example IOS configuration:
interface Vlan123 description Test IPv6 Network ipv6 address FD00:1234:5678:9ABC::1/64 no ipv6 unreachables ipv6 nd prefix default 2592000 604800 no-autoconfig ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 nd router-preference High no ipv6 redirects ipv6 verify unicast source reachable-via rx ipv6 eigrp 123 ipv6 dhcp relay destination FD00:1234:5678:9ABC::2 ipv6 dhcp relay destination FD00:1234:5678:9ABC::3
The "ipv6 nd prefix ... no-autoconfig" statement is what you're looking for. You need to type out timers to be able to get to it. The values shown are just the Cisco defaults.
On Thu, Oct 21, 2010 at 3:43 PM, Luca Tosolini <bit.gossip@chello.nl> wrote:
On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote:
We've decided to disable SLAAC (State-Less Address Auto-Configuration) on almost all our IPv6 networks and use DHCPv6 exclusively. This allows us to only respond with DHCPv6 to the hosts we want to get an IPv6 address instead of enabling it network-wide and crossing your fingers. The disadvantage here is that DHCPv6 client support is still limited (OS X has none for example). The argument is that IPv6 isn't mission critical yet, so we're waiting to see if vendors will come around and include DHCPv6 client support in the future.
Ray, how do you convey the default-router information with DHCPv6 only. AFAIK there is no such field in DHCPv6...
Luca.
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
And since someone asked me for it off-list, example PACL for IOS to filter RAs and DHCPv6 server traffic on incoming ports: On each switch: ipv6 access-list RA_Guard deny icmp any any router-advertisement deny udp any eq 547 any eq 546 permit any any end And on each switchport: ipv6 traffic-filter RA_Guard in Your mileage may vary. This was written for Catalyst 3560s and 3750s. Obviously you wouldn't apply it on the port your uplink is on. On Thu, Oct 21, 2010 at 4:08 PM, Ray Soucy <rps@maine.edu> wrote:
Also,
Keep in mind that DHCPv6 uses a DUID for host identification and not a MAC address.
Here is an example ISC DHCPd configuration for an IPv6 network without open pool allocation (it will only respond for hosts in the config).
# subnet6 for each network subnet6 FD00:1234:5678:9ABC::/64 { option dhcp6.name-servers FD00:1234:5678:9ABC::2, FD00:1234:5678:9ABC::3; }
# host for each host host soucy-desktop.domain.net { host-identifier option dhcp6.client-id 00:01:00:01:11:ee:71:12:00:1a:a0:da:ba:7f; fixed-address6 FD00:1234:5678:9ABC::A; }
I believe the new version of ISC DHCPd has added code to be able to determine the MAC address instead of using a DUID, but I haven't tested it personally.
On Thu, Oct 21, 2010 at 3:59 PM, Ray Soucy <rps@maine.edu> wrote:
I think you're misunderstanding how DHCPv6 works. Don't think of it like DHCP that you're used to.
DHCPv6 requires an IPv6 router advertisement to work. There are three flags of interest in a router advertisement.
One of them is the "A" (autonomous) flag which is enabled by default in almost every implementation I've seen. This is what signals a host that it is permitted to use stateless configuration with the prefix.
There are also "M" (managed) and "O" other flags. The "M" flag being set signals the host that it should start a DHCPv6 client and make a request for an address, the "O" flag signals that the host should ask for "other" or additional configuration information through DHCPv6 (e.g. DNS servers).
None of the flags are exclusive, so you can enable DHCPv6 by setting the M flag, but unless you disable the A flag, hosts will still use stateless configuration (in addition to DHCPv6 and receive two addresses)
If you want a DHCPv6-only environment, you simply disable the A flag on the router advertisement. This will stop hosts from using stateless with the advertised prefix.
The default gateway for the network is learned through the router advertisement, not through DHCPv6, which is why it doesn't exist in DHCPv6.
Example IOS configuration:
interface Vlan123 description Test IPv6 Network ipv6 address FD00:1234:5678:9ABC::1/64 no ipv6 unreachables ipv6 nd prefix default 2592000 604800 no-autoconfig ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 nd router-preference High no ipv6 redirects ipv6 verify unicast source reachable-via rx ipv6 eigrp 123 ipv6 dhcp relay destination FD00:1234:5678:9ABC::2 ipv6 dhcp relay destination FD00:1234:5678:9ABC::3
The "ipv6 nd prefix ... no-autoconfig" statement is what you're looking for. You need to type out timers to be able to get to it. The values shown are just the Cisco defaults.
On Thu, Oct 21, 2010 at 3:43 PM, Luca Tosolini <bit.gossip@chello.nl> wrote:
On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote:
We've decided to disable SLAAC (State-Less Address Auto-Configuration) on almost all our IPv6 networks and use DHCPv6 exclusively. This allows us to only respond with DHCPv6 to the hosts we want to get an IPv6 address instead of enabling it network-wide and crossing your fingers. The disadvantage here is that DHCPv6 client support is still limited (OS X has none for example). The argument is that IPv6 isn't mission critical yet, so we're waiting to see if vendors will come around and include DHCPv6 client support in the future.
Ray, how do you convey the default-router information with DHCPv6 only. AFAIK there is no such field in DHCPv6...
Luca.
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Using multiple ISPs is still something that is a bit tricky. A lot of people have gotten used to the Dual-WAN Firewall appliance boxes that accept connections from two ISPs and handle the failover, depending on NAT to maintain the functionality of the Internal network.
Larger organizations can arrange to have IPv6 transit and announce a single prefix over BGP. Most providers won't want to see this setup for an SMB so they're out of luck.
Actually, ANY size organization can do this. Most providers won't want to set this up over native DSL, CMTS, or PON cheap circuits. There are options there. Do BGP over tunnels using your native circuits as L2 transport, for one. (This is working quite well for me and hasn't been all that hard to implement).
One thing that has changed, though, is Metro Ethernet offerings have gotten a lot better. I would say the most painless way to go would be to use one ISP for L3, and two ME providers to give diverse L2 paths to that L3 ISP. It means dealing with more companies, and moving failover to L2, but it's pretty rare that the cause of a connection problem is at the ISP these days (it's more often a bad connection between you and the ISP), so just having redundancy at L2 might be enough.
I'm not convinced that's the best approach. If I were doing that, I'd use the two metro-E connections to reach different providers and run BGP. It's just not that hard. Especially if your BGP is accept default, advertise _myroute_.
Sadly, that model doesn't really exist in the US right now, and it might take quite a bit of work convincing providers to coordinate to make it all work.
Another argument in favor of the L2/L3 topologies matching. (There are also reliability and simplicity arguments to favor doing so).
The other option, which was the intent of IPv6 when being designed (but that was 10 years ago or so) was that every PC would have a separate address from each ISP. In this situation you could depend on ULA (local addressing) for access to all internal services so that if one of the global prefixes goes away it doesn't impact internal operation, but it does require a device to kind of coordinate that- such a device doesn't exist yet, and there are some issues with getting PCs to handle address selection correctly. I suspect if this does happen (and it could, it's not a horrible model) it will take a few more years before it's "easy". It's too bad they axed the site local scope for this kind of environment.
Please stop promulgating the fiction that IPv6 addressing from your provider depends on reachability to your provider to continue functioning on your internal network. It simply isn't true unless you are getting those addresses via DHCPv6 or SLAAC. If you have a topology, SLAAC is a non-starter and it would have to be DHCPv6-PD or static. If you have static, there's no need whatsoever for ULA. No sane business would go for having their IPv6 addresses delivered to them via DHCPv6-PD.
For now, I would recommend just going with a single IPv6 provider since I have yet to encounter IPv6-only content that is mission critical. That will at least give you access to the IPv6 internet now, but give the IPv6 market time to come around to meet the needs of SMB and wanting redundancy in IPv6 access.
This is a very solvable problem to day, but, it does require a tiny amount of training/learning to implement the solution.
I'm not aware of any appliance that does a good job at IPv6, yet...
Depends on your definition of Appliance. If you would consider an SRX-100 an appliance, it works reasonably well. It cost less than several of the other appliances in my house.
If it were me I would build up a Linux box as a IPv6 firewall, router, etc. It's really too bad that there isn't such an appliance yet. You could just use a Cisco ISR (like an 1841) as your IPv6 on a stick router, but the problem is that you really want to keep in mind that once you give out global addresses to hosts they're not behind your NAT firewall for IPv6. So you'll want to implement some sort of stateful firewall for IPv6, or enable host-based IPv6 firewalls.
Linux box is a fine alternative, ip6tables works well, but, Linux box vs. SRX-100, the cost difference isn't that large.
We've decided to disable SLAAC (State-Less Address Auto-Configuration) on almost all our IPv6 networks and use DHCPv6 exclusively. This
Ouch... Sounds painful.
allows us to only respond with DHCPv6 to the hosts we want to get an IPv6 address instead of enabling it network-wide and crossing your fingers. The disadvantage here is that DHCPv6 client support is still limited (OS X has none for example). The argument is that IPv6 isn't mission critical yet, so we're waiting to see if vendors will come around and include DHCPv6 client support in the future.
It also means that you are even more subject to the issues of rogue RA and RA Spoofing.
Another thing you want to do is block rogue RA. RA-Guard is the feature name, but nobody has a working implementation yet. If you have switches that can do port-based access-lists with IPv6 you can create ingress filters to block out incoming RA on a per-port basis which is what we have done.
You must have a really hostile user base. I agree RA-Guard is a good idea and it does work on some switches. Where it is most glaringly lacking is in Wireless configurations, meaning that having a real RA is actually a limited measure of protection vs. having no RA.
Owen
(Response inline). On Thu, Oct 21, 2010 at 9:01 PM, Owen DeLong <owen@delong.com> wrote:
We've decided to disable SLAAC (State-Less Address Auto-Configuration) on almost all our IPv6 networks and use DHCPv6 exclusively. This
Ouch... Sounds painful.
Really? I don't know. Maybe as a consultant you don't see it, but I can't run a non-trivial network without having control over which hosts get an IPv6 address (and knowing which address they get) without creating a lot more work running around putting out fires. From a "buy-in" standpoint, SLAAC was a non-starter, giving people an option where they could enable IPv6 on a host-by-host basis ended up being the quickest path to adoption without IPv6 getting a black eye because of a security issue that couldn't be quickly dealt with, or older systems (RHEL 3 comes to mind) having an IPv6 bug triggered and crashing. IPAM is a critical component of IPv6 for any non-trivial deployment IMHO, I know Apple disagrees, but OK.
allows us to only respond with DHCPv6 to the hosts we want to get an IPv6 address instead of enabling it network-wide and crossing your fingers. The disadvantage here is that DHCPv6 client support is still limited (OS X has none for example). The argument is that IPv6 isn't mission critical yet, so we're waiting to see if vendors will come around and include DHCPv6 client support in the future.
It also means that you are even more subject to the issues of rogue RA and RA Spoofing.
How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts...
Another thing you want to do is block rogue RA. RA-Guard is the feature name, but nobody has a working implementation yet. If you have switches that can do port-based access-lists with IPv6 you can create ingress filters to block out incoming RA on a per-port basis which is what we have done.
You must have a really hostile user base. I agree RA-Guard is a good idea and it does work on some switches. Where it is most glaringly lacking is in Wireless configurations, meaning that having a real RA is actually a limited measure of protection vs. having no RA.
Again, it sounds like you think DHCPv6 means no RA? This is not the case. I consider filtering RA (accidental or malicious) critical for any network, regardless of whether IPv6 is deployed or not. Just above you were complaining about me having problems with rogue RA... Now you're saying I'm being paranoid? I know you work for HE and everything, but really? If you don't block RA, you can get mis-configured hosts (Windows ICS comes to mind) hijacking traffic without even knowing about it on networks that you don't have IPv6 deployed on. That's the accidental side, though. On the malicious side, I consider IPv6 one of todays most effective attack vectors. I can easily jump on a network that doesn't even monitor IPv6, declare myself as a router, advertise myself as IPv6 DNS, and proxy all traffic on a network, often without setting off alarms. Remember, hosts by default usually have IPv6 enabled, and usually prefer IPv6 over IP. In the case of servers, most administrators who are diligent about making sure host-based firewalls are in place completely forget about IPv6, because they haven't deployed it yet. Just because you haven't deployed IPv6 doesn't mean it's not running on your network. This is especially true in an academic setting where people bring their own computers on to your network. Not filtering rogue RA seems a little insane, IMHO. I'm still shocked that RA-Guard hasn't become the default in modern switching... but if you don't think it's a problem, that works too. What are the odds that there will be a virus, worm, or tojan that decides to turn infected hosts into IPv6 routers, anyway... I really don't buy the argument that "advertising IPv6 yourself with a high priority will mitigate the impact of rogue RA". As mentioned, DHCPv6 still requires RA to work... by design, so your point is moot. But regardless, that mindset only protects against accidental rogue RA, not malicious RA, which is a significant security threat and _should_ be filtered as a best practice when possible. I would go as far as to argue it's worth pushing up switch upgrades to make sure you have hardware capable of doing so, but maybe I am just being paranoid. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On 10/21/2010 8:39 PM, Ray Soucy wrote:
How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts...
Actually, the last I checked, there are implementation of DHCPv6 without RA. Jack
On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote:
On 10/21/2010 8:39 PM, Ray Soucy wrote:
How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts...
Actually, the last I checked, there are implementation of DHCPv6 without RA.
I'll go out on a limb here and say that RA is not needed for DHCPv6. A DHCPv6 client multicasts all its messages to the well-known all-relays-and-servers address. A client needs only its link-local address to do this. The relay (or server if it happens to be on the same link) can thus talk to the client in the complete absence of RA. 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 Fri, 22 Oct 2010 15:52:08 +1100 Karl Auer <kauer@biplane.com.au> wrote:
On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote:
On 10/21/2010 8:39 PM, Ray Soucy wrote:
How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts...
Actually, the last I checked, there are implementation of DHCPv6 without RA.
I'll go out on a limb here and say that RA is not needed for DHCPv6.
RAs are still needed to convey the M/O bit values, so that end-nodes know they need to use DHCPv6 if necessary. As there are two address configuration methods, there is always going to be a need to express a policy to end-nodes as to which one they need to use.
A DHCPv6 client multicasts all its messages to the well-known all-relays-and-servers address. A client needs only its link-local address to do this. The relay (or server if it happens to be on the same link) can thus talk to the client in the complete absence of RA.
There isn't a method to specify a default gateway in DHCPv6. Some people want it, however it seems a bit pointless to me if you're going to have RAs announcing M/O bits anyway - you may as well use those RAs to announce a default router too. Regards, Mark.
On Oct 22, 2010, at 12:55 AM, Mark Smith wrote:
On Fri, 22 Oct 2010 15:52:08 +1100 Karl Auer <kauer@biplane.com.au> wrote:
On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote:
On 10/21/2010 8:39 PM, Ray Soucy wrote:
How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts...
Actually, the last I checked, there are implementation of DHCPv6 without RA.
I'll go out on a limb here and say that RA is not needed for DHCPv6.
RAs are still needed to convey the M/O bit values, so that end-nodes know they need to use DHCPv6 if necessary. As there are two address configuration methods, there is always going to be a need to express a policy to end-nodes as to which one they need to use.
You can actually force a client to assume the M bit if you cause it to launch a DHCPv6 client through other means. You don't have to have RA for that. Policy can be expressed by RA, or, it can be expressed by other means.
A DHCPv6 client multicasts all its messages to the well-known all-relays-and-servers address. A client needs only its link-local address to do this. The relay (or server if it happens to be on the same link) can thus talk to the client in the complete absence of RA.
There isn't a method to specify a default gateway in DHCPv6. Some people want it, however it seems a bit pointless to me if you're going to have RAs announcing M/O bits anyway - you may as well use those RAs to announce a default router too.
Actually, it's not pointless at all. The RA system assumes that all routers capable of announcing RAs are default routers and that virtually all routers are created equal (yes, you have high/medium/low, but, really, since you have to use high for everything in any reasonable deployment...) There are real environments where it's desirable to have a way to tell different clients on a network to use different default gateways or default gateway sets. Owen
On Fri, 22 Oct 2010 01:10:08 -0700 Owen DeLong <owen@delong.com> wrote:
On Oct 22, 2010, at 12:55 AM, Mark Smith wrote:
On Fri, 22 Oct 2010 15:52:08 +1100 Karl Auer <kauer@biplane.com.au> wrote:
On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote:
On 10/21/2010 8:39 PM, Ray Soucy wrote:
How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts...
Actually, the last I checked, there are implementation of DHCPv6 without RA.
I'll go out on a limb here and say that RA is not needed for DHCPv6.
RAs are still needed to convey the M/O bit values, so that end-nodes know they need to use DHCPv6 if necessary. As there are two address configuration methods, there is always going to be a need to express a policy to end-nodes as to which one they need to use.
You can actually force a client to assume the M bit if you cause it to launch a DHCPv6 client through other means. You don't have to have RA for that. Policy can be expressed by RA, or, it can be expressed by other means.
We used to hand wind cars to start them. We don't have to anymore. An RA is single, periodic, in the order of 100s of seconds, multicast packet. If you're arguing against the cost of that, then I think you're being a bit too precious with your packets. Any argument for manual configuration is an argument for increasing complexity and opportunity for error.
A DHCPv6 client multicasts all its messages to the well-known all-relays-and-servers address. A client needs only its link-local address to do this. The relay (or server if it happens to be on the same link) can thus talk to the client in the complete absence of RA.
There isn't a method to specify a default gateway in DHCPv6. Some people want it, however it seems a bit pointless to me if you're going to have RAs announcing M/O bits anyway - you may as well use those RAs to announce a default router too.
Actually, it's not pointless at all. The RA system assumes that all routers capable of announcing RAs are default routers and that virtually all routers are created equal (yes, you have high/medium/low, but, really, since you have to use high for everything in any reasonable deployment...)
No it doesn't. You can set the router lifetime to zero, which indicates to the end-node that the RA isn't announcing a default router. In this case, it may be announcing M/O bit, prefix or other parameters.
There are real environments where it's desirable to have a way to tell different clients on a network to use different default gateways or default gateway sets.
Owen
On Sat, 2010-10-23 at 03:48 +1030, Mark Smith wrote:
An RA is single, periodic, in the order of 100s of seconds, multicast packet. If you're arguing against the cost of that, then I think you're being a bit too precious with your packets.
Just to be clear on this: I was taking issue solely with the idea that DHCPv6 requires RA. It doesn't. 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
Actually, it's not pointless at all. The RA system assumes that all routers capable of announcing RAs are default routers and that virtually all routers are created equal (yes, you have high/medium/low, but, really, since you have to use high for everything in any reasonable deployment...)
No it doesn't. You can set the router lifetime to zero, which indicates to the end-node that the RA isn't announcing a default router. In this case, it may be announcing M/O bit, prefix or other parameters.
DHCPv6 can selectively give different information to different hosts on the same wire segment. RA cannot.
There are real environments where it's desirable to have a way to tell different clients on a network to use different default gateways or default gateway sets.
Owen
On Fri, 22 Oct 2010 15:42:41 -0700 Owen DeLong <owen@delong.com> wrote:
Actually, it's not pointless at all. The RA system assumes that all routers capable of announcing RAs are default routers and that virtually all routers are created equal (yes, you have high/medium/low, but, really, since you have to use high for everything in any reasonable deployment...)
No it doesn't. You can set the router lifetime to zero, which indicates to the end-node that the RA isn't announcing a default router. In this case, it may be announcing M/O bit, prefix or other parameters.
DHCPv6 can selectively give different information to different hosts on the same wire segment.
RA cannot.
That was not the assertion you made. You said that "The RA system assumes that all routers
capable of announcing RAs are default routers"
and I said, no, that is not the case if you set the RA lifetime to zero. To cite explicitly, RFC4861 says, Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default Narten, et al. Standards Track [Page 20] ^L RFC 4861 Neighbor Discovery in IPv6 September 2007 router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. I was not making any statements about whether DHCPv6 could be selective about providing certain options to selected end-nodes. You might think I'm being overlay pedantic, however changing the question to then disagree with answer that doesn't agree with yours is being disingenuous.
There are real environments where it's desirable to have a way to tell different clients on a network to use different default gateways or default gateway sets.
I wouldn't necessarily disagree, although in my experience they're really quite rare, to the point where segmenting them into a separate subnet, via e.g. a different VLAN, becomes a somewhat better and easier option. Regards, Mark.
On Oct 23, 2010, at 7:26 AM, Mark Smith wrote:
On Fri, 22 Oct 2010 15:42:41 -0700 Owen DeLong <owen@delong.com> wrote:
Actually, it's not pointless at all. The RA system assumes that all routers capable of announcing RAs are default routers and that virtually all routers are created equal (yes, you have high/medium/low, but, really, since you have to use high for everything in any reasonable deployment...)
No it doesn't. You can set the router lifetime to zero, which indicates to the end-node that the RA isn't announcing a default router. In this case, it may be announcing M/O bit, prefix or other parameters.
DHCPv6 can selectively give different information to different hosts on the same wire segment.
RA cannot.
That was not the assertion you made.
You said that
"The RA system assumes that all routers
capable of announcing RAs are default routers"
and I said, no, that is not the case if you set the RA lifetime to zero. To cite explicitly, RFC4861 says,
Right... I oversimplified the point I was attempting to make and you called me on it... Move on.
Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default
Narten, et al. Standards Track [Page 20] ^L RFC 4861 Neighbor Discovery in IPv6 September 2007
router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields.
I was not making any statements about whether DHCPv6 could be selective about providing certain options to selected end-nodes.
You might think I'm being overlay pedantic, however changing the question to then disagree with answer that doesn't agree with yours is being disingenuous.
There are real environments where it's desirable to have a way to tell different clients on a network to use different default gateways or default gateway sets.
I wouldn't necessarily disagree, although in my experience they're really quite rare, to the point where segmenting them into a separate subnet, via e.g. a different VLAN, becomes a somewhat better and easier option.
While I would agree with you operationally, sometimes they involve software that discovers other devices by broadcast and does not permit other mechanisms. I've seen environments where they're able to deal with this in IPv4 because of this flexibility in DHCPv4 and would be limited to static addressing in IPv6 because it lacks this ability. Owen
In a message written on Fri, Oct 22, 2010 at 06:25:18PM +1030, Mark Smith wrote:
There isn't a method to specify a default gateway in DHCPv6. Some people want it, however it seems a bit pointless to me if you're going to have RAs announcing M/O bits anyway - you may as well use those RAs to announce a default router too.
There are some folks (like me) who advocate a DHCPv6 that can convey a default gateway AND the ability to turn off RA's entirely. That is make it work like IPv4. There are pros, and cons; but I can think of a number of deployment scenarios where it would be a vast improvement and beleive strongly operators should have the choice. Unfortunately the folks in the IETF don't even want to listen, to the point a working group chair when I tried to explain why I wanted such a feater told the rest of the group "He's an operator and thus doesn't understand how any of this works, ignore him." That's when I gave up on the IETF, and started working on my vendor for the solution. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 10/22/2010 8:38 AM, Leo Bicknell wrote:
Unfortunately the folks in the IETF don't even want to listen, to the point a working group chair when I tried to explain why I wanted such a feater told the rest of the group "He's an operator and thus doesn't understand how any of this works, ignore him." That's when I gave up on the IETF, and started working on my vendor for the solution.
It's popped around multiple times. The drafts won't stop until it's implemented. The lack of it in DHCPv6, despite obvious desire for it, seems to indicate a bias on the part of the IETF. Here's a current draft http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05 Jack
On Fri, Oct 22, 2010 at 7:06 AM, Jack Bates <jbates@brightok.net> wrote:
On 10/22/2010 8:38 AM, Leo Bicknell wrote:
Unfortunately the folks in the IETF don't even want to listen, to the point a working group chair when I tried to explain why I wanted such a feater told the rest of the group "He's an operator and thus doesn't understand how any of this works, ignore him." That's when I gave up on the IETF, and started working on my vendor for the solution.
It's popped around multiple times. The drafts won't stop until it's implemented. The lack of it in DHCPv6, despite obvious desire for it, seems to indicate a bias on the part of the IETF.
The interesting thing is that while the IETF may have a certain bias, the hardware manufacturers have a different bias; they do what needs to be done to sell hardware. And while we may be 'just operators', if we tell vendors we won't buy their hardware unless they support draft-X-Y-Z, you can believe they'll listen to that a lot more closely than they will the IETF. The IETF has teeth only so long as those with money to spend on vendors support their decisions. When a vendor is forced to choose between complying with the IETF, or getting a $5M purchase order from a customer, they're going to look long and hard at what the customer is requesting. We've gotten knobs added to software that go explicitly against standards that way; they're off by default, they're hidden, and they have ugly names like "enable broken-ass-feature-for-customer-X" but the vendors *do* put them in, because without them, they don't get paid. Matt
Here's a current draft http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05
Jack
Amen! On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell <bicknell@ufp.org> wrote:
There are some folks (like me) who advocate a DHCPv6 that can convey a default gateway AND the ability to turn off RA's entirely. That is make it work like IPv4.
I'd also love to turn off stateless autoconfig altogether and not be coerced to assign /64s to single LANs, which I am becoming convinced that it was a poor decision on the IETFs part. Stateless autoconfig works very well, It would be just perfect if the network boundary was configurable (like say /64 if you really want it, or /80 - /96 for the rest of us) cheers Carlos -- -- ========================= Carlos M. Martinez-Cagnazzo http://cagnazzo.name =========================
Stateless autoconfig works very well, It would be just perfect if the network boundary was configurable (like say /64 if you really want it, or /80 - /96 for the rest of us)
Why do you feel it's a poor decision to assign /64's to individual LANs? Best Regards, Nathan Eisenberg
On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote:
Amen!
On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell <bicknell@ufp.org> wrote:
There are some folks (like me) who advocate a DHCPv6 that can convey a default gateway AND the ability to turn off RA's entirely. That is make it work like IPv4.
I'd also love to turn off stateless autoconfig altogether and not be coerced to assign /64s to single LANs, which I am becoming convinced that it was a poor decision on the IETFs part.
Nah... The /64 thing is fine. If they hadn't done that, we likely would have only a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are fine. What would be nice would be if we changed the semantics a bit and made it 16+48+64 where the first 16 of the dest+source could be re-assembled into the destination ASN for the packet and the remaining 48 identified a particular subnet globally with 64 for the host. Unfortunately, that ship has probably sailed.
Stateless autoconfig works very well, It would be just perfect if the network boundary was configurable (like say /64 if you really want it, or /80 - /96 for the rest of us)
There really is no need for anything smaller than /64. What, exactly, do you think you gain from a smaller netmask? Owen
What would be nice would be if we changed the semantics a bit and made it 16+48+64 where the first 16 of the dest+source could be
re-assembled
into the destination ASN for the packet and the remaining 48 identified a particular subnet globally with 64 for the host. Unfortunately, that ship has probably sailed.
Well, since ASNs are now 32-bit, yeah.
What would be nice would be if we changed the semantics a bit and made it 16+48+64 where the first 16 of the dest+source could be
re-assembled
into the destination ASN for the packet and the remaining 48 identified a particular subnet globally with 64 for the host. Unfortunately, that ship has probably sailed.
On the other hand, it probably would have been easier (and more widely adopted already) to simply go to an "internet of internets" model where you break the planet up into 32-bit regions, each with their own 32-bit "internets" and just use what amounts to IPIP tunneling between them and enlarge the standard MTU from 1500 to accommodate that without further packet fragmentation. And speaking of changing MTU, is there any reason why private exchanges shouldn't support jumbo frames? Is there any reason nowadays that things that are ethernet end to end can't be MTU 9000 instead of 1500? It certainly would improve performance and reduce the packets/sec and increase performance on latent links. Why are we still using 1500 MTU when peering? Is there any gear at peering points that DOESN'T support jumbo frames these days?
On 10/24/2010 5:05 AM, George Bonser wrote:
And speaking of changing MTU, is there any reason why private exchanges shouldn't support jumbo frames? Is there any reason nowadays that things that are ethernet end to end can't be MTU 9000 instead of 1500? It certainly would improve performance and reduce the packets/sec and increase performance on latent links. Why are we still using 1500 MTU when peering? Is there any gear at peering points that DOESN'T support jumbo frames these days?
Probably no reason at all, though probably little perceived benefit. 1492 is common enough that google/youtube already runs lower MTU's just to avoid common broken PPPoE setups (which often could run higher MTU, but weren't configured that way). Not uncommon for cell companies to request 1600 MTU or more for their layer 2 transport, which one vendor had to custom patch 1648 into their gear to even support that much. Of course, it will be lowered by a variety of tags/tunnels/etc by the time it gets to the cell phone. It cracks me up that SONET interfaces default 4470, and ethernet still defaults to 1500. I've yet to see an MTU option in standard circuit setup forms, which would indicate to me that asking for a higher MTU might get me one extra link before dropping back to 1500ish. Jack
In a message written on Sun, Oct 24, 2010 at 11:09:28AM -0500, Jack Bates wrote:
variety of tags/tunnels/etc by the time it gets to the cell phone. It cracks me up that SONET interfaces default 4470, and ethernet still defaults to 1500. I've yet to see an MTU option in standard circuit setup forms, which would indicate to me that asking for a higher MTU might get me one extra link before dropping back to 1500ish.
I've had pretty good luck asking for higher MTU's on both customer and peering links. I'd say about an 80% success rate for dedicated GigE's. It's generally not on the forms though, and sometimes you get what I consider weird responses. For instance I know several providers who won't going higher than 4470 on ethernet. If more folks asked for higher MTUs it might become part of the standard forms... -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
I've had pretty good luck asking for higher MTU's on both customer and peering links. I'd say about an 80% success rate for dedicated
GigE's.
It's generally not on the forms though, and sometimes you get what I consider weird responses. For instance I know several providers who won't going higher than 4470 on ethernet.
If more folks asked for higher MTUs it might become part of the standard forms...
That is what I am thinking as well. For example, in the past week I have seen someone here asking about data center locations and mentioned data replication between them. If you are on both coasts of the US and are backing up or otherwise replicating data between the two, even going to a MTU of 3000 is a measurable win depending on the amount of data you are moving and the protocols you are using. Load on routers and even hosts is generally caused by packets per second, not bits per second. If you cut the number of packets in half you reduce the load on every single piece of gear in the path. Gee, I wonder how much energy consumption that would save on a global basis if everyone did that. Coming across Phil Dykstra's paper from 1999 is what got me thinking about it (well, that and moving a lot of data between Europe and the West coast of the US). http://sd.wareonearth.com/~phil/jumbo.html http://staff.psc.edu/mathis/MTU/
Coming across Phil Dykstra's paper from 1999 is what got me thinking about it (well, that and moving a lot of data between Europe and the West coast of the US).
Found more good information here: http://noc.net.internet2.edu/i2network/maps--documentation/policy-statem ents.html#Jumbo%20Frames It might not be a bad idea to take some of what is learned on Inet2 and backport it to the 'net where possible. I also discovered that Linux will do RFC4821 PMTU discovery if you set /proc/sys/net/ipv4/tcp_mtu_probing to the proper value. It is turned off by default. Solaris is on by default it appears.
Probably no reason at all, though probably little perceived benefit. 1492 is common enough that google/youtube already runs lower MTU's just to avoid common broken PPPoE setups (which often could run higher MTU, but weren't configured that way).
I run into that already with people doing various things inside their net (MPLS, GRE, IPIP?) that shorten the effective MTU but they block the ICMP unreachable packets and break PMTU discovery. That blanket blocking of ICMP unreachable type 3 code 4 is evil, in my opinion. If your traffic passes through a Cisco ASA series device (and maybe other vendors, too) your MTU is effectively 1380 anyway as that is the maximum MSS that it advertises (or can even be configured to advertise) when it establishes an outbound connection and in some versions of its code will drop a packet from an endpoint that doesn't honor the advertised MSS. It is a real performance killer across the Internet in my opinion and better performance could be had, particularly for long distance links where you are limited by the number of "in flight" packets if those packets could be bigger. The problem is that even if you have two end points that are jumbo capable, the networks in the path don't seem to support >1500 MTU. If everyone configured their peering and internal gear to support a 9216 byte frame size and set their MTUs to 9000, that change would be transparent to the connections flowing though it and people who wanted to send larger frames could do so without impacting anyone using a shorter size.
In a message written on Sat, Oct 23, 2010 at 05:23:14PM -0700, Owen DeLong wrote:
On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote:
On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell <bicknell@ufp.org> wrote:
There are some folks (like me) who advocate a DHCPv6 that can convey a default gateway AND the ability to turn off RA's entirely. That is make it work like IPv4.
I'd also love to turn off stateless autoconfig altogether and not be coerced to assign /64s to single LANs, which I am becoming convinced that it was a poor decision on the IETFs part.
Nah... The /64 thing is fine. If they hadn't done that, we likely would have only a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are fine.
I think the 64-bit boundry is fine (from a DHCP perspective). I do think if we're going to update the DHCP spec it should support a netmask option, just because leaving it out is short sighted to the future, but I would use it with /64's today.
There really is no need for anything smaller than /64. What, exactly, do you think you gain from a smaller netmask?
There is a slippery slope here, if users make do with smaller providers may give out smaller blocks, and so on. That said, if a provider does hand out a /64, I would very much like technology to make 16 bits of subnet + 48 bits of host, with EUI-48 used directly for autoconf as an option. Particularly when we talk about 6rd and other things that use a lot of space this option would be huge. Users would still get 16 bits of subnet, and host space so big they could never fill it. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Oct 24, 2010, at 6:48 AM, Leo Bicknell wrote:
In a message written on Sat, Oct 23, 2010 at 05:23:14PM -0700, Owen DeLong wrote:
On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote:
On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell <bicknell@ufp.org> wrote:
There are some folks (like me) who advocate a DHCPv6 that can convey a default gateway AND the ability to turn off RA's entirely. That is make it work like IPv4.
I'd also love to turn off stateless autoconfig altogether and not be coerced to assign /64s to single LANs, which I am becoming convinced that it was a poor decision on the IETFs part.
Nah... The /64 thing is fine. If they hadn't done that, we likely would have only a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are fine.
I think the 64-bit boundry is fine (from a DHCP perspective). I do think if we're going to update the DHCP spec it should support a netmask option, just because leaving it out is short sighted to the future, but I would use it with /64's today.
My understanding was DHCPv6 did support prefixes other than /64.
There really is no need for anything smaller than /64. What, exactly, do you think you gain from a smaller netmask?
There is a slippery slope here, if users make do with smaller providers may give out smaller blocks, and so on.
Yeah, that could be worse than neutral. Still there's no gain to smaller than /64, only loss...
That said, if a provider does hand out a /64, I would very much like technology to make 16 bits of subnet + 48 bits of host, with EUI-48 used directly for autoconf as an option. Particularly when we talk about 6rd and other things that use a lot of space this option would be huge. Users would still get 16 bits of subnet, and host space so big they could never fill it.
I think that ship has pretty well sailed, but, it might be a good future workaround if providers start doing stupid pet tricks like assigning single /64s to end customers. Owen
The design of IPv6 is that DHCPv6 and RA work together. This is why there is no method to express the default gateway using DHCPv6, that task is handled by the RA. I suppose you could run DHCPv6 on a subnet to give hosts addresses but never give them a default gateway, but that would be a little useless no? Please stop confusing people about DHCPv6. There is already enough misinformation out there. It's starting to feel like Fox News here, next there will be another post citing yours saying "experts on NANOG have said that DHCPv6 doesn't require RA" and make users spend hours looking for how to set the gateway address. On Thu, Oct 21, 2010 at 10:05 PM, Jack Bates <jbates@brightok.net> wrote:
On 10/21/2010 8:39 PM, Ray Soucy wrote:
How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts...
Actually, the last I checked, there are implementation of DHCPv6 without RA.
Jack
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On 10/22/2010 7:12 AM, Ray Soucy wrote:
The design of IPv6 is that DHCPv6 and RA work together. This is why there is no method to express the default gateway using DHCPv6, that task is handled by the RA. I suppose you could run DHCPv6 on a subnet to give hosts addresses but never give them a default gateway, but that would be a little useless no?
Works great when you don't need routing. DHCPv6 doesn't have an option for a default gateway/router There. No confusion. RA isn't the only way to load a route. It's just the most supported. Jack
On Fri, Oct 22, 2010 at 08:55:49AM -0500, Jack Bates wrote:
I suppose you could run DHCPv6 on a subnet to give hosts addresses but never give them a default gateway, but that would be a little useless no?
Works great when you don't need routing.
Or the default route should point out a different interface. Think e.g. of DHCP used for a management network. You don't want a default route, but in case of a routed management network, signal a set of specific routes. http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05, there we go. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Oct 21, 2010, at 9:29 AM, Allen Smith wrote:
Hi All,
I've inherited a small network with a couple of Internet connections through different providers, I'll call them Slow and Fast.
We use RFC 1918 space internally and have a pair of external firewalls that handle NAT and such.
Due to internal policy (read money), some users default to the Slow connection and some default to Fast. Using probes and policy routing, a failure of one of the ISPs is generally transparent, outside of the usual session resets for things like ssh or remote control sessions).
Looking forward to the next 12 months, we may have clients that are living in IPv6 space. Our ISPs are happy to give us IPv6 allocations and our network gear vendors either have GA IPv6 code now or will soon.
We have been somewhat spoiled by our firewall/NAT boxes, the stuff just works for our needs and the combination of NAT and policy routing keeps people on the circuits they are paying for. Am trying to decide how I would implement this kind of policy in the new world of globally trackable^H^H^H^H^H^H^H routable IPs for my desktops. Solutions seem to be:
My suggestion: 1. Get a /48 from your friendly neighborhood RIR. 2. Get an ASN to go with it. 3. Accept that your inbound is going to get topologically divided between the two links rather than customer-specific. If that's not an option, then: 1. Get /48s from both providers. 2. Provide appropriate RAs to your users so that the users that should prefer provider SLOW get RAs with a higher preference to provider SLOW and the users that should prefer provider FAST get RAs with a higher preference for provider FAST. 3. Update your probes/policy routing scripts so that they will deprecate the broken RA (you can do this by sending a poisoned final RA with a very short valid time to the all hosts multicast address of each subnet). Option 3 is a very bad idea and I hope your vendor would refuse. Owen
1) Purchase some BGP capable routers, grab PI space. Here I can obv choose outbound path, but we are typical in that our inbound to outbound is 6 or 7 to 1.
2) Assign PA space from the ISPs to the appropriate devices. What do I do when I loose a provider?
3) Make loud noises to my firewall vendor to include equivalent NAT/ISP failover functionality (even 6to6 NAT would be fine).
Anyway, another sample of 1, but I do work for a managed services provider and see many small orgs facing similary choices. I personally am happy to use globally routable addresses and will work through the privacy and perceived security implications of NAT/nonat, I just want the same ease of use and flexibility I have today in a SMB environment.
Cheers, -Allen
From: Ray Soucy Sent: Thursday, October 21, 2010 5:49 AM To: Owen DeLong Cc: NANOG list Subject: Re: IPv6 fc00::/7 - Unique local addresses
See... You're falling into the same elitist mindset that I was trapped in a year ago.
Perception is a powerful thing. And Joe IT guy at Mom and Pop dot com (who's network experience involves setting up a Linksys at home) loves his magical NAT box firewall appliance. Over the last year I've been trying to fight the NAT war and have gotten pretty beat down. It doesn't matter if *we* know NAT is wrong, undesirable, and breaks the Internet... we all live in the large scale, multi-homed, BGP, mega Internet land.
And BetaMAX was a much better format than VHS, too, from a technical standpoint. It doesn't matter which is "better", it matters what people want. Telling people they can't have what they want leads to someone somewhere providing them with what they want and making a fortune on it.
Start working with smaller shops, and you'll find the typical setup is a bunch of switches and a "VPN Firewall" picked up from Best Buy, or maybe a Sonicwall or something. These guys couldn't manage public IPv4 let alone public IPv6, because the term "private" gives them that warm and fuzzy false sense of security and lets them change their ISP without reconfiguring a single thing (they often wouldn't know where to start anyway).
I am not sure there really is a such thing as a "secure" network. If you can somehow get a host inside a network to send the first packet to you, you are in. Yeah, all those filters and NATs prevent you from being able to send the first packet, but as long as people are dragging in laptops, thumb drives, opening email attachments, and browsing the web, there is no such thing as a "secure" network if it has internet access. Even the deepest packet inspection won't make you secure of the traffic going back and forth abides by the protocol rules. Is that really a file upload and download going on, or is it a bi-directional tunnel disguised as file transfers that never end and is someone now doing a complete scan of your network from one of your employee's workstations? Having a lock on the door is fine, but for a door to be useful, you must be able to open it from the inside. And when you take a delivery, are you sure what is in that box is what is really on the packing slip? And if you take it out of the box and look on it, is it still *really* what it says on the packing slip? Sort of like a birthday cake arriving at a prison.
They *will* fight you, and tell you to your face that if you want to take NAT away from them it will be from their cold dead hands.
And it isn't NAT in and of itself that is attractive. Those people aren't talking about static NAT where you are just translating the network prefix. They are talking dynamic port-based PAT so that the translation doesn't exist until the first packet goes in the outbound direction. Like it or not, that DOES provide some barrier of entry to someone outside wishing to initiate a connection from the outside. You cannot predict in advance what outside address/port will be associated with which inside address/port or if any such association even exists and a lot of people have already made up their minds that the breakage that causes for various things is offset by the perceived benefit of that barrier and worth the price of dealing with that breakage.
Why? Because we've had 10 years of "consultants" selling NAT as the best thing for security since sliced bread.
Maybe we could get them to do it the right way if they had some sort of IPv6 appliance that dumbed things down, but it simply doesn't exist yet. When it is created, it will be created by the people with the NAT mindset wishing to maintain the status quo.
At least that's my prediction...
I tend to agree with that. Not saying that I think that is the best way to go, mind you, just saying that I can see such a thing happening and all the jumping up and down on NANOG isn't going to change that because it is the end user that decides in the end what gets built and what doesn't. So either put into the protocol a specific prohibition of NAT, engineer the protocol so NAT can't possibly work, or get ready to accept that you are going to be dealing with it.
We need to keep in mind that most on this list is likely at a completely different level than anything you'd find in the SMB community.
I have tried making that point privately to many individuals but it doesn't seem to click and is taken as if I am "defending" or somehow rationalizing that "dumbed down" behavior when I am simply acknowledging the existence of it. Sort of like when your daughter starts dating that ne'er-do-well up the street. Sometimes it just is what it is and you can point out the potential problems until the cows come home but it isn't really going to matter. There are billions more of "them" than there are of "us" to put it in tribal terms. In fact, I will say that the lack of such NAT features is exactly WHY IPv6 hasn't caught on in many networks. They can't afford to hire "networking" people, they hire
"IT" people who are tasked with anything related to technology and usually completely understaffed. Thus they want the quick, painless, easy solution.
If it doesn't have a GUI checkbox, it doesn't exist. So they configure a NAT pool, and maybe put a packet filter on the router ahead of it and they are "done" as far as they are concerned. Changing providers means touching the network in two places.
They *will* fight you, and tell you to your face that if you want to take NAT away from them it will be from their cold dead hands.
And it isn't NAT in and of itself that is attractive. Those people aren't talking about static NAT where you are just translating the network prefix. They are talking dynamic port-based PAT so that the translation doesn't exist until the first packet goes in the outbound direction. Like it or not, that DOES provide some barrier of entry to someone outside wishing to initiate a connection from the outside. You cannot predict in advance what outside address/port will be associated with which inside address/port or if any such association even exists and a lot of people have already made up their minds that the breakage that causes for various things is offset by the perceived benefit of that barrier and worth the price of dealing with that breakage.
Ah... You've actually just pointed out that it is _NOT_ the NAT that does that, but, the stateful inspection that happens before the NAT. Stateful inspection can occur and require a matching state table entry to permit inbound packets with or without the header-mangling that we call NAT, NPAT, NAPT, PAT, etc. True, overloaded NAT cannot exist without stateful inspection, but, that's largely irrelevant to security. What is relevant is the need for a good stateful inspection engine with a default-deny-inbound policy. Owen
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Thursday, October 21, 2010 5:26 AM To: Ray Soucy Cc: NANOG list
If you're using IPv4 with multiple providers giving you different NAT pools, then, you're looking at outbound, not inbound resiliency and the DNS stuff you described is irrelevant. As long as your outbound gateway(s) have some way to detect provider down-ness (all the same tactics that work for IPv4 here work for IPv6 with pretty much the same flaws), you can do the same thing. The difference is that in IPv6, you have to tell the hosts which IPv6 source prefix to use. The easy way to do that is to alter the desired/valid lifetimes in your internal RAs accordingly. This isn't hard to script.
That doesn't really work because both of your providers may be "up" but one of them is not reachable by the network at the other end. You cannot predict ahead of time which address a remote network will be able to reach. Being multihomed with one block of addresses solves that problem in that as long as the distant end is getting routing information originated by either of the upstreams, you are good. Also, announcing two network blocks for the same service is a bad idea. If one becomes unreachable while a transaction is in progress, you can't fail over until the connection times out and it reconnects on the other IP. And of the application at the other end is some "secure" java application, it might cache that unreachable IP forever until the application is bounced or until its default cache TTL expires which might be a different TTL than in the DNS information.
If you're using IPv4 with BGP and advertising the same prefix(es) to multiple providers, the same thing works in IPv6 with nearly identical processes.
Yeah, that's the only way that really works.
I don't see what NAT gives you for EITHER of those things.
Ok, say you have your machines multinetted with two GUA nets on the same interface. Which IP does the application choose to source traffic from when it originates an outbound connection to the world? You can't predict which one is "broken" somewhere along the path. Load balancing inbound is a much simpler model than load balancing outbound and unless you want to push your entire BGP table down to the host, well, it just doesn't work. What *does* work is having your internal net addressed in some stable way that doesn't change when your upstream changes and in IPv4 you simply change your NAT pools to reflect the change. Done, your entire network is "renumbered" as far as the Internet is concerned. If your hosts are numbered in PA space, changing providers means potentially touching the configurations of all machines. A network provider will love that because it discourages customers from changing providers and makes the customer stickier to them. A customer might not feel so comfortable about that and want more independence of the provider's network.
-----Original Message----- From: Ray Soucy > Sent: Thursday, October 21, 2010 5:00 AM To: Jeroen van Aart Cc: NANOG list Subject: Re: IPv6 fc00::/7 - Unique local addresses
The mindset of using RFC1918 space, throwing everything behind a NAT box, and not having to re-configure systems when you change ISP doesn't exist in IPv6. There is no IPv6 NAT (yet).
And that is one of the real challenges here. An office that is not multihomed and has only a short commit to a provider may be reluctant to number their network in that provider's PA space if they really do not want to remain "sticky" to that provider. I can understand that position as I tend not to want to be "sticky" to a provider either. Things change quickly in the world and market rates for connectivity can change rapidly. Short term agreements that give the user the flexibility to move easily to a different provider can be desirable but it might also be impossible to convince the CFO that they need to obtain two providers in order to get their own address block. The issue driving many small networks to multihome isn't really so much that they NEED to multihome, it is because they really want to be able to change providers without renumbering their network/services. RFC-1918 with NAT gave them that flexibility with v4. LUA doesn't really give them that as it currently stands. You can number your networks with both, but that can lead to some interesting RA configurations and can be fun to watch depending on what gear is in place.
If you wanted to setup an "island" of IPv6 that would never talk to the Internet, then you could use ULA, but that would only be needed if you plan on routing between LANs. Remember that by default every IPv6 host has a link-local address allowing it to talk to any directly connected hosts without configuration. So if you're simply looking for some sort of ad-hoc network, it's likely already there.
The problem is in putting such link local addresses into the local DNS so hosts can find each other. I generally consider link local IPs in DNS to be a "bad idea" unless it is in a subdomain dedicated that that specific subnet. Given a flat network that isn't routed and is used for clustering machines together, it is a "flat" layer 2 net with no layer3 interfaces except for the hosts themselves (no router interfaces on the network) then having a subdomain just for the hosts on that specific subnet that include the link local IPs on that specific subnet might work. But that is the right application of ULA. That subnet will never get routed off the site so what the heck. In fact, it will never get routed at all.
As much as I hate NAT and want to see it go away. I think the biggest transition mechanism for people to get online with IPv6 will be some sort of appliance that does NAT of global IPv6 addresses to private IPv4 addresses to keep all the people living in the NAT world from having to redesign their networks. It's ugly, but its the path of least resistance and that's likely what will happen when we see IPv6 become required to do business... at least as a stepping stone.
That is going to be a tough sell to the network operators. The enterprise guys are all going to say "we need stable addressing that is not tied to a provider" the network operators are going to say "multihome and get your own block" and the enterprise guys are going to say "we already have two connections to our primary provider and can tolerate an outage, this isn't a business killing critical network and it would take a major failure of our current provider or the TELCO to cause us to be completely unreachable, we can't make the business case to justify two transit provider contracts but we DO need stable address space because there are just so many problems with autoconfiguration that we can't make that work in a reliable way". And maybe fixing autoconfiguration is where the key lies to this problem. Having RA announce multiple prefixes is a challenge, though, and as far as I know there is no standard way of saying: "get all available prefixes from the router and use that prefix to mask this host address". For example, say I have configured the host with a "static host mask", for lack of a better name, that uses a ULA address as the mask. Say the mask is fdf7:77d7:b935:123:1b The router is announcing fd11:d148:570f:aaaa:/64 (a ULA subnet), and 2001:200:c000:f473::/64 (some random thing I pulled out of BGP plus some randomness representing some assigned space). So I overlay those prefixes onto the "default" host IP mask. I end up configuring fd11:d148:570f:aaaa:123:1b/64 2001:200:c000:f473:123:1b/64. As I am applying a unique local mask to either a unique local or unique global prefix, I should end up with a unique address either way and can then configure my interface in several subnets in a stable manner that doesn't change over time no matter what provider prefixes I might have and it won't care what the mask is of the subnet prefix being announced by the router as long as it is longer than a /8, I am ok. I route f700::/7 via fd11:d148:570f:aaaa::/64 net gateway and ::/0 via the 2001:200:c000:f473::/64 gateway and I am all set. If my provider changes in the future, I change the prefixes announced from the router and up/down the interface and I am done. The problem is in getting autoconfiguration and RA to do all that exactly the same way with all hosts and all routers of all vendors. Having autoconfig on the host with an option to use a "default address mask" in addition to being able to calculate an EUI-64 can provide a network with some stability and predictability. As for the other problem with trying to use two separate PA blocks, forget it. If you are multihomed, get your own block. That is the only good way forward.
participants (45)
-
Adrian Chadd -
Allen Smith -
Arifumi Matsumoto -
Ben Jencks -
Brandon Ross -
Carlos Martinez-Cagnazzo -
Christopher Morrow -
Daniel Roesen -
David Conrad -
Deepak Jain -
Doug Barton -
Edward A. Trdina III -
George Bonser -
Graham Beneke -
Jack Bates -
James Hess -
Jason Iannone -
Jay Ford -
Jen Linkova -
Jeroen Massar -
Jeroen van Aart -
Joe Hamelin -
Joel Jaeggli -
Karl Auer -
Leo Bicknell -
Luca Tosolini -
Mark Andrews -
Mark Smith -
Matthew Kaufman -
Matthew Petach -
Mikael Abrahamsson -
Nathan Eisenberg -
Owen DeLong -
Phil Regnauld -
Randy Bush -
Randy Carpenter -
Ray Soucy -
Robert E. Seastrom -
Seth Mattinen -
Skeeve Stevens -
Stephen Sprunk -
Steve Meuse -
Tim Franklin -
Valdis.Kletnieks＠vt.edu -
William Herrin