Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

On Mon, 1 Nov 2010 18:04:28 -0700
Owen DeLong <owen () delong com> wrote:

> > > >
> > > He may or may not be. I don't think it's such a bad idea.
> >
> > How about algorithmically generating these addresses, so that
> > they're near unique, instead of having the overhead of a central
> > registry, and a global routability expectation?
> Why not just keep a low-overhead central registry and start accepting
> that PI != global routability. Routability is a discussion between the
> resource holder and their ISP(s).
>
> ULA is the algorithmically generated problem and I think it's a generally
> bad idea. It's basically an expectation of uniqueness where it may or
> may not exist and the potential to fudge the level of routability into whatever
> strange definition long-term creativity may evolve.
>
> I think it's better to make GUA easy to get and remove the expectation
> that GUA == Routable. (Ideally, we'd restore that eventually with a
> scalable routing paradigm).

Is it possible to get GUA from RIRs without making it globally visible?
I think the only current exception is IXes. A couple of years back I'd
have liked to have gotten a globally unique IPv4 allocation that wasn't
being announced globally for use with customer facing DNS servers,
reducing their DoS attack surface significantly. Wasn't able to.

> > > > Recently we've seen somebody (on either nanog or ipv6-ops) proposing to
> > > > set valid lifetimes of 24 hours on ISP GUA prefixes. While a 24 hour
> > > > outage is unusual for a always connected broadband service, it isn't
> > > > for intermittently connected nodes and networks.
> > > The upstream valid lifetime doesn't have a lot to do with what happens on
> > > the internal network if you're smart.
> >
> > Residential end-users aren't "smart" and aren't network engineers - they
> > pay people like us so that they don't have to be.
> That still doesn't have a lot to do with enterprise failover which is what we
> were talking about.
>
> As to residential, residential end users mostly don't care if their network
> goes down when their provider goes away. However, for those that do,
> it still shouldn't be hard for the provider to uncouple circuit viability from
> address presence.

In some markets, CPE are sold at the local electronics/white goods
store.

> > > > In effect people who suggest using PA GUAs or PI for all IPv6 addressing
> > > > are saying you can't run IPv6 unless you have an available IPv6 ISP
> > > > connection or you must be able to afford to be able to thrust upon the
> > > > world occupation of a global route table slot. They're not realistic
> > > > requirements for all potential users of IPv6. 
> > > No...PI does not require an available IPv6 ISP connection at all. This
> > > is a misstatement that does not become any less false no matter how
> > > many times you repeat it.
> >
> > What if you don't have an IPv6 ISP connection? Where do you get your PA
> > from? Link local isn't good enough, because it can't span more than a
> > single link. Homes in the future are likely to have multiple networks -
> > visitor segments, multicast segments for video, children
> > segments, 6LowPAN for home sensor networks etc.
> It gets configured in your router.

By whom?

> Why is that such a difficult concept?

For me it isn't, but a lot of things are simple to people with the
right expertise. For residential customers who don't know what an IP
address, I'm sure it is not only difficult but probably for most an 
impossible concept.

> Your home gateway that talks to your internet connection can either
> get it via DHCP-PD or static configuration. Either way, it could (should?)
> be set up to hold the prefix until it gets told something different, possibly
> even past the advertised valid time.

That breaks the IPv6 spec. Preferred and valid lifetimes are there for
a reason.

> It can delegate subnets using
> DHCP-PD, but, the point is that the top level router at the site can
> easily be coded/configured to keep the prefix regardless of the state of the
> external link.
>
> > You've stated you use link locals for this sort of thing, yet you'd be
> > specifying the interface to use as well. That isn't much different to
> > using a subnet number, embedded in the address, to specify either
> > directly attached or remotely reachable subnets. The nice thing about
> > doing it that way is that IPv6 applications are addressing scope
> > agnostic - they just use the address supplied, and ask the
> > underlying OS, which uses the local route table, to
> > direct where the packets go and therefore select the outgoing interface.
> > Link locals + interfaces is more complicated, because now socket
> > options have to be invoked, and only in the case of when a link local
> > address is specified, which also means performing an address type check
> > for the interface option. This code has to be present in ever
> > application, instead of letting the underlying OS taking care of how
> > application packets are directed towards their destinations, and the
> > applications not having to care.
> No, I've stated that you could. I have stated that I use link locals for
> a variety of things.
>
> Usually for this type of thing, I'd use a legitimate GUA prefix whether
> PI or PA.

That doesn't mean there they only options that will work. I'm
guaranteed to have a ULA prefix to solve this problem, because I can
generate one myself, and know that it won't collide with a GUA prefix
if I get one at a latter date. If I follow the ULA algorithm, it
probably also won't collide with any other ULA domains I may
interconnect with. I can't be assured of those attributes for a GUA
prefix, and may not be able to wait to establish a commercial
relationship with an ISP before I get a GUA for use with this purpose.

> > > > For the most common and scalable case of PA, external addressing
> > > > dependencies reduce reliability, because you can't control them.
> > > > Completely relying on external connectivity and addressing for your
> > > > internal networks reduces their reliability and availability.
> > > This is also false if you use any form of sanity in applying the assigned
> > > PA prefix to your network.
> >
> > I suppose since they don't have the expertise, you could consider
> > residential end-users insane. You can't make the insane sane just by
> > telling them to be so. Preventing their "insanity" from breaking their
> > Internet service, causing them to call your helpdesk, is the sane
> > thing to do. That is achieved by making their Internet service work
> > with the absolute least operational intervention on their part. It's
> > hard enough to get them to enter their username/password via an
> > embedded web server - to the point where some vendors supply setup CDs
> > to automate the discovery of the device, avoiding the end user having
> > to type an IP address URL into their browser.
> Sure, but, why can't you set it up so that you either ship them pre-configured
> hardware, have their hardware download it's configuration once each time
> the CONFIGURATION MASTER RESET button is pushed, or, having the
> hardware learn the configuration via DHCP-PD, but, keeping the configuration
> until a newer configuration is received?

As I said earlier, CPE isn't always sold or operated by through the ISP
the customer will get Internet services from.

> All of these provide zero-user-intervention ways to configure their
> equipment such that they will have a valid PA address locally that
> survives a link failure.
>
> > > > In this common case of PA, how are you going to justify that "no IPv6
> > > > without an IPv6 ISP" view to people who are very remote, such that even
> > > > intermittent Internet access is very occasional; to people who run IPv6
> > > > sensor networks and don't ever want them connected to the Internet; or
> > > > 3rd world countries where just local connectivity provides a very
> > > > significant benefit, when global connectivity just isn't affordable?
> > > > These and similar are cases where only ISP PA or PI aren't acceptable.
> > > Nobody is trying to. This is a fallacy of logic that you keep pushing,
> > > but, it's still false. If I wire a PA prefix into my router, it doesn't go
> > > away just because the ISP does. All that happens is that I can't
> > > reach the internet from it, which is kind of true regardless of the
> > > address space used at the point where your ISP goes away.
> >
> > You haven't ever tried to get a majority of residential end-users
> > to update their firmware have you? You'll have the same luck getting a
> > majority of them to "wire a PA prefix into" their routers. 
> Why do they have to wire it in? Why can't I wire it in for them?
>
> I know lots of companies that maintain control of the top-level CPE router
> for just this reason.

as before.

> > > > Permanent connectivity to the global IPv6 Internet, while common,
> > > > should not be essential to being able to run IPv6, and neither should
> > > > PI. All you should need to run IPv6 reliably is stable internal
> > > > addressing. Global connectivity should be optional, and possibly only
> > > > occasional.
> > > Why shouldn't PI if it was easy to get? I still don't understand the
> > > perceived advantage of ULA vs. PI other than the perception that
> > > it is easier to get. If PI is just as easy to get, why is it a problem?
> >
> > It seems to me your main criticism of ULAs is that people would expect
> > it to be globally routed if they paid enough money. Now you're saying
> > that if PI is really easy to get, people *won't* have a global routing
> > expectation of PI routability? I certainly would if I was given PI.
> > What would be worse is that this "non-routable" PI won't come out of a
> > specific prefix so that it can easily filtered, unlike ULAs.
> If you find a provider that will route your PI, no harm done. You're paying
> enough to get someone to listen to your routes and the internet is
> accepting them for the time being.
>
> At least your PI is subject to policy and the will of the community.
>
> ULA, on the other hand, has no community oversight, no policy body,
> and no restrictions whatsoever on who else uses "your ULA". Yet,
> through creativity and luck, ULA will eventually get routed across
> more and more of the internet until it starts to look like cheap easy
> policy free GUA. At that point, the harm is not about your expectations,
> the harm is about the failed expectations of the rest of the internet
> with respect  to ULA.

I think you under estimate the value of free. With GUA addresses you get
free global routability. With ULAs you don't. Why would a network
choose to only use ULAs and then try to force upstreams to route it by
writing out big cheques (checks), when instantly and
persistently globally routable GUA either comes for free with the
Internet service, or at a much lower cost than trying to make
non-globally routable ULA address space routable - that isn't ever
assured of being anywhere near as successful in providing
global reachability as using GUAs is.


> > > > > 2) ULA brings with it (as do any options that include multiple
> > > > > addresses) host-stack complexity and address-selection issues... 'do I
> > > > > use ULA here or GUA when talking to the remote host?'
> > > >
> > > > There's an app for that (or rather a library routine called
> > > > getaddrinfo() and an optional table it consults), and there's soon going
> > > > to be a way to distribute it via DHCPv6 if the defaults don't suit -
> > > >
> > > > http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09
> > > Sure, now, how many applications have been coded to actually
> > > pay attention to what getaddrinfo is telling them about address
> > > selection order?
> >
> > All the ones I use - they all seem to use the first getaddrinfo()
> > response. They should be attempting to successively connect() to all
> > responses in the order that getaddrinfo() returns as connect()
> > failures occur. I don't know if they are (as destination reachability
> > is usually good), however if they aren't, then the application
> > developers haven't used getaddrinfo() correctly. That behaviour
> > wouldn't be exclusive to IPv6 though - IPv4 applications should also be
> > attempting to connect() to successive addresses when multiple are
> > returned. IOW, applications coping with multiple responses to
> > getaddrinfo() is not an exclusive issue to IPv6.
> There are well behaved and not so well behaved applications out
> there with respect to getaddrinfo. I agree with you about the ideal,
> but, counting on that is sort of like counting on the user to configure
> something correctly... Not likely to reduce your help desk calls.

With IPv4, the history of applications on the Internet is that they've
only tried one connection attempt, due to the nature of
gethostbyname(). That has worked very reliably. IOW, that
means destination hosts are usually available the majority of the time.
So, as I said, ideally applications should try to connect to multiple
addresses in turn if multiple addresses are returned. IPv4 history has
shown that it isn't actually as important as it may appear to be.
Therefore, attempting to connect to each returned address is more of
an an optional robustness and resilience mechanism. The need for it
in IPv6 might be increased due to the possibility of multiple paths to
the destination host, but I don't think it is an all that significant
increase. The likelyhood is the first returned address will work most
of the time, as it has in IPv4. For highly available services, people
choose to put in place mechanisms such as HSRP or VRRP to provide
further availability for announced addresses.

> > I actually override the current default IPv6 address rules. Here's
> > my /etc/gai.conf, which makes ULAs override GUAs as that currently
> > isn't in the default address selection rules, and makes tunnelled IPv6
> > preferred over native IPv4, as I don't currently have native IPv6. The
> > MRS entries are the non-defaults, the rest are from the gai.conf manual
> > page.
> You do this for your residential customers? It's fun to watch how this
> discussion gets steered back to enterprise for places where it works
> better for you as an enterprise, but, residential customers are suddenly
> the topic when I give an answer that solves the enterprise problem but
> may not work for residential.

The problem is you never seem to qualify your statements by saying
"For enterprises, ". You make broad statements without qualification,
which can only be interpreted to mean that you think they apply to all
IPv6 situations. I know of situations, which I think are relevant
to this mailing list, where they don't, which is why I point them out.

Regards,
Mark.