>
>>>>>> "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?
>
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?
> 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.
> 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.
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.
> 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.
> 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.
> 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.
>> 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 -
>
> 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.
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.
