Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Thu, Nov 4, 2010 at 1:31 AM, Owen DeLong o...@delong.com wrote: On Nov 3, 2010, at 5:21 PM, valdis.kletni...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 3, 2010, at 11:02 PM, Christopher Morrow wrote: On Thu, Nov 4, 2010 at 1:31 AM, Owen DeLong o...@delong.com wrote: On Nov 3, 2010, at 5:21 PM, valdis.kletni...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Wed, 3 Nov 2010 04:14:51 + (UTC) Sven Olaf Kamphuis s...@cb3rob.net wrote: I've had a recent experience of this. Some IPv6 CPE I was testing had a fault where it dropped out and recovered every 2 minutes - a transient network fault. I was watching a youtube video over IPv6. Because of the amount of video buffering that took place, and because the same IPv6 prefixes were assigned to the connection once it recovered, the youtube video kept playing. That was a great end-user experience and it was somewhat addictive to watch the PPP light go off and come back on while the video kept playing faultlessly. thats primarily due to partial http downloads aka http status 206 rather than 202 where you can just specify at which offset in the file you want the httpd to start reading the file to you, most flash movie players, however, don't support this. connection lost = movie has to be fully reloaded. There's a whole lot of speculation and no evidence in that statement ... as it said, it was faultless, so I very strongly doubt there was any restarting the stream.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 2, 2010, at 3:26 PM, Karl Auer wrote: On Tue, 2010-11-02 at 09:03 -0700, Owen DeLong wrote: About the only hack I can see that *might* make sense would be that home CPE does NOT honour the upstream lifetimes if upstream connectivity is lost, but instead keeps the prefix alive on very short lifetimes until upstream connectivity returns. Which is exactly what was being proposed when Tim responded that it would break the IPv6 spec. Yes it does. But as long as there is no upstream connectivity, it doesn't matter. Personally I don't think it makes a *lot* of sense, but it does make some. Sounds like we're in violent agreement. Owen
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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 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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
In message 2ce5a700-eb60-453f-85cf-5e679e94e...@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 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: ma...@isc.org
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Wed, Nov 3, 2010 at 6:43 PM, Mark Andrews ma...@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.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote: In message 2ce5a700-eb60-453f-85cf-5e679e94e...@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 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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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?) pgpO3n6zJfVdQ.pgp Description: PGP signature
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 3, 2010, at 5:21 PM, valdis.kletni...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, 1 Nov 2010 18:04:28 -0700 Owen DeLong o...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
About the only hack I can see that *might* make sense would be that home CPE does NOT honour the upstream lifetimes if upstream connectivity is lost, but instead keeps the prefix alive on very short lifetimes until upstream connectivity returns. Yep, that's the hack I was getting at. As a non-technical end-user, once my CPE has got a prefix from my ISP and advertised it to the devices on my LAN, the same prefix should keep working until: -my ISP assigns a different one -the end of time whichever comes first :) Having my PC not be able to talk to my printer any more because my DSL / cable / wimax / whatever has been down for too long is not acceptable. Regards, Tim.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On 11/02/2010 01:26 PM, Tim Franklin wrote: About the only hack I can see that *might* make sense would be that home CPE does NOT honour the upstream lifetimes if upstream connectivity is lost, but instead keeps the prefix alive on very short lifetimes until upstream connectivity returns. Yep, that's the hack I was getting at. As a non-technical end-user, once my CPE has got a prefix from my ISP and advertised it to the devices on my LAN, the same prefix should keep working until: -my ISP assigns a different one -the end of time whichever comes first :) Having my PC not be able to talk to my printer any more because my DSL / cable / wimax / whatever has been down for too long is not acceptable. Regards, Tim. Interresting enough, this is the exact opposite I want to have when only IPv6 does down on the ISP-side, when IPv4 is still working I would like to still be able to use that connection (I have experience with that, I have an IPv6-tunnel at home right now). As IPv6 is always preferred, otherwise you get all kinds of errors or delays before getting to the real content. I say, use a seperate prefix for home-users (maybe let the home-router generate an ULA one time ?). Maybe the same for small businesses. For the enterprise you might want PI (possible not globally routed). They have the money and incentive. Or just use IPv4 for internal. Easier to remember (instead of the many IPv6-bits) and Windows XP needs it for DNS anyway. Disable zeroconf for IPv6 ?
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Tue, 2 Nov 2010 10:51:44 + (GMT) Tim Franklin t...@pelican.org wrote: 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. And end-users want things to Just Work. And I want their networks to work so well that I don't even want them to rely in an ISPs addressing being available, valid, or even having an ISP - which could easily be the case if they go and sign up for a new broadband service, bring home brand new CPE, yet don't get ISP service connectivity for 5 to 10 business days. Surely they should be able to hook up their internal network and have their TV talking to their computer or NAS during this period without an Internet service. The ISP in question may not be prepared to give them a permanent GUA address at the time of sign up, because the ISP may wish to have static addressing as a product distinguisher for SOHO/SME products, or have the flexibility of phasing semi-dynamic addressing in and out over time to suit their IPv6 address management requirements. The CPE vendor that finds a hack that lets the LAN carry on working while the WAN goes away and manages to slap the With Home Network Resilience! label on the box correctly will presumably do quite nicely out of it. For this kind of site, I can't see what is *actually* going to break if the CPE keeps sending RAs for the prefix beyond the valid lifetime while the WAN is down. As long as it advertises a short valid lifetime itself, such that if the real prefix changes[0] when the WAN comes back up it can renumber everything on the LAN quickly, it looks a lot like a Just Works scenario to me... Prefix lifetimes don't work that way - there is no such thing as a flash renumbering. The goal was to be able to phase new addressing in, transition to it as either older communcations sessions cease (e.g. TCP connections), or new ones are established, then phase out the old addressing over a more significant time period than one measured in minutes or seconds. Regards, Mark. Regards, Tim. [0] Which it won't, of course, because residential users are going to get proper static connections by default, rather than another round of business class price-gouging :)
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Tue, 2010-11-02 at 23:23 +1030, Mark Smith wrote: Prefix lifetimes don't work that way - there is no such thing as a flash renumbering. The lifetimes are reset with every RA the nodes see. If I reconfigure my router to start sending out RAs every N seconds, it will take a a maximum of N seconds for a new preferred lifetime to be established on all active nodes on the link. If the new preferred lifetime is zero, any addresses in the prefix will be deprecated immediately, causing other prefixes on the link to be preferred. The new valid lifetime will be the remaining valid lifetime (if less than two hours), the newly advertised valid lifetime (if using SEND), or two hours in all other cases. That seems pretty close to flash renumbering... at least for SLAAC. DHCPv6 needs more planning. Regards, K. -- ~~~ Karl Auer (ka...@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 signature.asc Description: This is a digitally signed message part
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 2, 2010, at 4:55 AM, Karl Auer wrote: On Tue, 2010-11-02 at 10:51 +, Tim Franklin wrote: That breaks the IPv6 spec. Preferred and valid lifetimes are there for a reason. And end-users want things to Just Work. The CPE vendor that finds a hack that lets the LAN carry on working while the WAN goes away and manages to slap the With Home Network Resilience! label on the box correctly will presumably do quite nicely out of it. But - preferred and valid lifetimes do *exactly that*. The address is fully usable up to the end of the preferred lifetime. It is then deprecated (but not unusable) until the end of the valid lifetime. Only after the valid lifetime does it become unusable. DHCPv6 lifetimes are exactly the same as RA lifetimes - and of course there is nothing that says the RA lifetimes have to be the same as the DHCPv6 lifetimes (though some sensible relationship would be advisable). So loss of connectivity to the upstream is not going to blow away a home network. It will keep working fine, even if the upstream goes away for a while. It's up to the upstream to use lifetimes that are a good compromise between flexibility and stability. About the only hack I can see that *might* make sense would be that home CPE does NOT honour the upstream lifetimes if upstream connectivity is lost, but instead keeps the prefix alive on very short lifetimes until upstream connectivity returns. Which is exactly what was being proposed when Tim responded that it would break the IPv6 spec. Owen
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 2, 2010, at 3:08 AM, Mark Smith wrote: On Mon, 1 Nov 2010 18:04:28 -0700 Owen DeLong o...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Wed, 03 Nov 2010 00:25:34 +1100 Karl Auer ka...@biplane.com.au wrote: On Tue, 2010-11-02 at 23:23 +1030, Mark Smith wrote: Prefix lifetimes don't work that way - there is no such thing as a flash renumbering. The lifetimes are reset with every RA the nodes see. If I reconfigure my router to start sending out RAs every N seconds, it will take a a maximum of N seconds for a new preferred lifetime to be established on all active nodes on the link. If the new preferred lifetime is zero, any addresses in the prefix will be deprecated immediately, causing other prefixes on the link to be preferred. The new valid lifetime will be the remaining valid lifetime (if less than two hours), the newly advertised valid lifetime (if using SEND), or two hours in all other cases. That seems pretty close to flash renumbering... I consider flash renumbering to mean that addressing can be changed without disrupting established and ongoing communications sessions e.g. doesn't break TCP connection or UDP streams. I know that renumbering without disrupting transport protocols is fundamentally impossible to achieve regardless of what the IPv6 preferred and valid lifetimes are because transport protocols are using locators as identifiers. However, the goal should be to make transient network faults, such as a broadband service link flap, have as minimal impact as possible. Changing addresses every time that type of fault occurs makes the consequences higher for transient faults than they need to be. I've had a recent experience of this. Some IPv6 CPE I was testing had a fault where it dropped out and recovered every 2 minutes - a transient network fault. I was watching a youtube video over IPv6. Because of the amount of video buffering that took place, and because the same IPv6 prefixes were assigned to the connection once it recovered, the youtube video kept playing. That was a great end-user experience and it was somewhat addictive to watch the PPP light go off and come back on while the video kept playing faultlessly. Some people argue that applications should be built to deal with this type of situation. I think that is again asking application developers to expend effort overcoming what are networking layer faults, as it has been with NAT. I think problems are best solved where they're caused, not necessarily where their effects are worst felt. I think it's better to hide transient network faults from applications than have to make each and every application include code to deal with them. The time spent writing that code could be better spent on bug fixing, improving the application functions themselves, or writing a different one. Regards, Mark. at least for SLAAC. DHCPv6 needs more planning. Regards, K. -- ~~~ Karl Auer (ka...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Tue, 2010-11-02 at 09:03 -0700, Owen DeLong wrote: About the only hack I can see that *might* make sense would be that home CPE does NOT honour the upstream lifetimes if upstream connectivity is lost, but instead keeps the prefix alive on very short lifetimes until upstream connectivity returns. Which is exactly what was being proposed when Tim responded that it would break the IPv6 spec. Yes it does. But as long as there is no upstream connectivity, it doesn't matter. Personally I don't think it makes a *lot* of sense, but it does make some. Regards, K. -- ~~~ Karl Auer (ka...@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 signature.asc Description: This is a digitally signed message part
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
In message cc14fcd0-1924-425a-8879-0c1fa6ade...@delong.com, Owen DeLong write s: On Nov 2, 2010, at 3:08 AM, Mark Smith wrote: On Mon, 1 Nov 2010 18:04:28 -0700 Owen DeLong o...@delong.com wrote: =20 =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 = 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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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 d...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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 K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, 1 Nov 2010 10:24:31 + (GMT) Tim Franklin t...@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.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, Nov 1, 2010 at 5:28 AM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 1, 2010, at 2:28 AM, Mark Smith wrote: On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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. OK, sorry, I think we're addressing different points of the same comment. I was looking very much at the second half of all residential users get PI so that if their ISP disappears their network doesn't break, ie the reason *why* they'd want PI. I assumed that was disappears as in has an outage, rather than goes bust, user changes ISP etc - and if you've only got one ISP, you don't need PI or ULA to have *local* connectivity work through an ISP outage. I agree, on the current routing platforms we have, PI for every end site is insanity. Whether we should be looking for routing platforms (or a different architecture - LISP?) that allows PI for every end user is a different question... Regards, Tim.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
oops, I clipped a little too much from the message before replying... On Mon, Nov 1, 2010 at 5:28 AM, Mark Smith na...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, 1 Nov 2010 09:20:41 -0700 Owen DeLong o...@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.li...@gmail.com wrote: On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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 :::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 :::0:0/96 10 --
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Nov 1, 2010, at 9:07 AM, Mark Smith wrote: On Mon, 1 Nov 2010 10:24:31 + (GMT) Tim Franklin t...@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.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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. ;) pgpxeM2XKtzB0.pgp Description: PGP signature
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Sun, Oct 31, 2010 at 12:31 PM, Owen DeLong o...@delong.com wrote: On Oct 31, 2010, at 7:22 AM, valdis.kletni...@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.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Sun, Oct 31, 2010 at 10:26 AM, Matthew Kaufman matt...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Oct 31, 2010, at 10:58 AM, Matthew Petach wrote: On Sun, Oct 31, 2010 at 10:26 AM, Matthew Kaufman matt...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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
RE: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses)
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.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses)
On Sun, Oct 31, 2010 at 2:01 PM, George Bonser gbon...@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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@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
RE: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses)
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.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses)
In message aanlktimsb6uj-jpoglg08q-rzdub-+c9c5kmzcktq...@mail.gmail.com, Chri stopher Morrow writes: On Sun, Oct 31, 2010 at 2:01 PM, George Bonser gbon...@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: ma...@isc.org
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 — Unique local addresses)
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!
RE: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 — Unique local addresses)
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.
Re: Failover IPv6 with multiple PA prefixes ( Was: IPv6 fc00::/7 — Unique local addresses )
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
Re: Failover IPv6 with multiple PA prefixes ( Was: IPv6 fc00::/7 — Unique local addresses )
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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 — Unique local addresses)
In message 20101021170258.ge61...@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: ma...@isc.org
RE: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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
RE: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 — Unique local addresses)
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.
RE: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses)
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.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
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
