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

[Owen DeLong <owen () delong com>]

On Nov 1, 2010, at 9:07 AM, Mark Smith wrote:

> On Mon, 1 Nov 2010 10:24:31 +0000 (GMT)
> Tim Franklin <tim () pelican org> wrote:
>
> > > Surely your not saying "we ought to make getting PI easy, easy enough
> > > that the other options just don't make sense" so that all residential
> > > users get PI so that if their ISP disappears their network doesn't
> > > break?
> >
> > I've seen this last point come up a few times, and I really don't get it.
> >
> > If you're multihomed with multiple PA GUAs, yes, you'd want each RA to track its corresponding WAN availability so 
> > your devices are using a prefix that has connectivity.
> >
> > If you're a single-homed leaf network, why on earth wouldn't you want to generate RAs for your statically-assigned 
> > prefix all the time, regardless of the state of your WAN connection?
>
> This isn't to do with anything low level like RAs. This is about
> people proposing every IPv6 end-site gets PI i.e. a default free zone
> with multiple billions of routes instead of using ULAs for internal,
> stable addressing. It's as though they're not aware that the majority
> of end-sites on the Internet are residential ones, and that PI can
> scale to that number of end-sites. I can't see any other way to
> interpret "we ought to make getting PI easy, easy enough that the other
> options just don't make sense".
Making it easy enough to get PI that anyone who wants it can get
it will not result in most residential customers choosing to go with PI.

Most residential customers will continue with PA.

This discussion was originally about businesses needing failover
between providers which is an environment where I will continue
to advocate PI over other solutions.

For a single-homed residence that doesn't care, PA will remain easier
on multiple levels than PI even if the RIRs were not involved at all.

As to the ability to scale PI, that is a deficiency in the current routing
paradigm which must be fixed eventually anyway. It's unfortunate that
we chose not to address this in IPv6, but, so it is and we are where we
are. Hopefully we can find a way to address it without needing another
major rev. of the protocol that is application affecting since that's the
actual hard part of the IPv6 migration.

Owen

> Regards,
> Mark.