Re: [v6ops] PI [ULA draft revision #2 Regarding isolated networks]

[joel jaeggli <[e-mail]>]

On 6/1/14, 7:10 PM, Ted Lemon wrote:
> On Jun 1, 2014, at 9:59 PM, joel jaeggli <[e-mail]> wrote:
>> Ted I think you need rethink what you're claiming. for one rfc
>> 6555 makes no claims about ipv6 address selection between multiple
>> addresses. it in fact sets aside the issue of having more than the
>> two address familes to chose from. I daresay if you have six v6
>> routes you probably don't want to make six requests and see which
>> one is fastest as a general rule.
> 
> How is this different than doing happy eyeballs between v4 and v6?
> Is it different because you're sextuply multi-homed?   I agree that
> that begins to look a bit problematic, but the more usual
> two-provider case is pretty much the same as regular happy eyeballs.
> 
>> you'remore likely to do ecmp if you simply treat all nexthops as
>> though they were equivalent, which you might not want to do if they
>> aren't (backup via LTE is probably not something you want to 
>> exercise all the time even if it's equivlant speed to your cable 
>> connection because it's more costly and has a datacap).
> 
> Right, that's a problem.
> 
>> source address selection based on nexthop is pretty straight
>> forward. most unixes can do that. invalidating a nexthop when the
>> route should no longer be used is propertly the domain of routing.
>> This is not even a benifit of ipv6 in the sense that it can work in
>> ipv4 as anyone with an appropriately configured router  can attest
>> (it's what the multihomed nat box actually does after all).
> 
> I've never operated one of these, but I'll take your word for it.
> The fact that it works with IPv4 and NAT isn't very interesting to
> me.
> 
> Correct me if I am wrong, but what you have written appears to be a
> more detailed way of saying "happy eyeballs for multihoming won't
> happen, in my opinion, and multihoming for connection originators
> probably won't happen either, at least without NAT."

nope that's not what  I said.

>   If so, that's
> a fine opinion to have, and may even be correct, but it's not an
> opinion I am willing to just accept without trying to do better
> (according to my opinion as to what's "better").

So don't asssume that every application needs to be aware of and test
for which path is working, not only is that needless complexity pushed
up into the stack. let your routers do their job and cease routing when
their upstream connectivity is lacking.

>