In message <b8aa2a26-3b41-4427-90f6-26eb9e6be...@delong.com>, Owen DeLong write s: > >>> > >> I keep hearing this and it never makes sense to me. > >> > >> If your provider will assign you a static /48, then, you have stable > >> addresses when your provider link is down in GUA. Who needs ULA? > > > > You used the word "if". Reverse the sense of the "if" and see if > > it still doesn't makes sense to use ULA addresses. I get a mostly > > stable IPv4 address from my cable provider (DHCP). That address > > changes without notice about once a year. I can configure a 6to4 > > prefix based on that address (effectively a PA prefix). I use ULA > > addresses internally and 6to4 (PA) externally. Same for 6rd. Same > > for PD. > > > I use the dynamic address from my cable provider to terminate a set > of GRE tunnels to my colo routers. < > I use the static address from my DSL provider to terminate other > GRE tunnels to my colo routers. > > The DSL tunnels are all carrying both IPv4 and IPv6. > > When the cable address changes, the BGP sessions over those > GRE tunnels drop and my network connection slows down. > When I repair the tunnels with the new end-point address, > everything goes back to fast.
You've gone way past what the average home user can or should be expected to handle here. Your well into advanced user territory. I've done the same sort of thing but I don't see myself as a average home user. The average home user should be able to plug in a home router into the network connection from the ISP. Plug that into a 10/100/1000 switch or turn on WiFi and plug in there hosts / enable WiFi on the hosts and have the network work regardless of whether the upstream is working or not. If they have bought the multi-upstream router then plug all isps in (Cable/DSL/WiMax/....) and have the whole thing work regardless of how many upstream links are working. > > DHCP derived 6to4, DHCP derived 6rd, DHCP derived Terado and PD all > > give you leased prefixes. They are not guarenteed to be STABLE. > > For internal communication you really do want stable prefixes. ULA > > gives you those stable prefixes. > > Yep... Makes much more sense to have at least one provider with static > and do native IPv6 than to use 6to4, 6rd, Teredo, or PD. Well when you can get agreements from all the residential ISPs to provide static IPv6 address come back to me. In the meantime I'm going to plan how to handle non static assignments, > >>> You talk to the world using PA addresses, directly for IPv6 and > >>> indirectly via PNAT for IPv4. These can change over time. > >>> =3D20 > >> Or, if you don't want your IPv6 addresses to change over time, you = > can > >> get a prefix from your friendly RIR. > > > > You really think I'm going to go to my RIR and get a addresses block > > for my home network then my cable provider will route it for me? > > > No... I think you might go to your RIR and get an address block > for your home network then find a way to use your cable provider > for L2 transport and route it. That solution works quite well for me. You still had to have someone route it somewhere be it the cable provider or someone else you reach over the cable provider. > >>> Similarly, ULA + 6to4 works well provided the 6to4 works when you > >>> are connected. When your IPv4 connection is renumbered you have a > >>> new external addresses but the internal addresses stay the same. > >>> > >> That's a big "provided that"... > > > > Not really. It works for lots of people. > > > Then how come I hear a lot more 6to4 horror stories than 6to4 > success stories? It's not like I don't talk to lots of people using > these protocols on a daily basis. Because people complain when things break. They are silent when things work. > > And you expect the routing system to cope when 2 billion homes do the > > same thing? > > As a matter of fact, I think the routing system damn well better start > planning to cope with just that scenario. I think it is inevitable in > one form or another. > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org