Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Mark Smith
  • Date: Mon Nov 01 05:29:02 2010

On Sun, 31 Oct 2010 21:32:39 -0400
Christopher Morrow <morrowc.lists@gmail.com> wrote:

> On Sun, Oct 31, 2010 at 3:10 PM, David Conrad <drc@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?

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.

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. 

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.

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.

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.

> 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


Regards,
Mark.





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.