On Sun, 25 Apr 2010 16:42:31 -0700 Owen DeLong <owen@delong.com> wrote:
On Apr 25, 2010, at 3:50 PM, Mark Smith wrote:
On Sun, 25 Apr 2010 13:21:16 -0400 Richard Barnes <richard.barnes@gmail.com> wrote:
Moreover, the general point stands that Mark's problem is one of bad ISP decisions, not anything different between IPv4/RFC1918 and IPv6.
My example, although a bit convoluted to demonstrate a point, is about robustness against Internet link failure. I don't think people's internal connectivity should be dependent on their Internet link being available and being assigned global address space. That's what the global only people are saying.
Your internet connectivity, by definition, depends on an internet link being available. No link, no connection. Simple as that.
Now, if you're talking about multihoming, I, as one of the global only people, am suggesting that you get your global addresses from ARIN and advertise it to both of your upstreams.
I know this is not popular with many of the ISPs out there because there is a cost to that and a scale factor that still has yet to be addressed in the IP routing paradigm. However, I think that will happen anyway.
Alternatively, even if you want to do some funky NAT-based solution, there's nothing wrong with using GUA on the internal side of the NAT to your PA prefixes outside. That way, when you get the opportunity to remove that NAT cruft from your environment, you already have usable addresses and you don't have to renumber.
(how is the customer going to access the CPE webserver to enter ISP login details when they get the CPE out of the box, if hasn't got address space because it hasn't connected to the ISP ...)
That's what Link Local is for.
fe80::<EUI-64>%<interface>
For example, if the CPE is connected to the customer's network on eth0 and the CPE mac address is 00:45:4b:b9:02:be, you could go to:
Would you want to be asking residential customers (your other half, mother, father, sister etc. - not a tech like you) to work that out and then type that in? Would you want to be running the helpdesk that supports those customers, considering the chance of error there is (selecting the wrong interface, typos etc. etc.) The IPv6 Internet needs to be at least as user friendly as IPv4, so asking residential customers to type in anything harder than an IPv4 address is unacceptable. Adding in an interface name to a literal IPv6 address is effectively specifying a subnet, without specifying a subnet. ULAs (announced in RAs) make this easier, because you're not creating the requirement for applications to have to understand both literal LL IPv6 addresses as well as qualifying interface names. Regards, Mark.