Re: Extending a /64

[[e-mail]]

Philip,

>> Agree with regards to lifetimes.  Addressing != Routing.  You
>> shouldn't use a change in reachability to renumber your network.
>> Imagine what happens if that link flaps once a second.
> 
> As a consumer, by and large Addressing = Routing. If I move to a different
> ISP, my address(es) will change. If I take my devices from home to work
> and back, address will change. If my phone connects to wifi then typically
> it drops the mobile connection and addresses change. If I multi-home I 
> will have two (or more) set of addresses, each tied to a specific uplink.
> 
> So by and large, for a consumer if routing changes, addressing also changes.

I think that statement is in the general wrong.

> I link flags once a second, then there is something wrong with that link.
> DAD takes longer than one second. 

DAD isn't triggered on a downstream interface if an upstream interface flaps.
Withdrawing the addresses learnt from the upstream interface from all downstream interfaces would break all sessions.
Even for just a 1s link-flap. Implying that using a reachability event to withdraw addressing is a poor idea.

> 
> I'm not saying that address should change when a link drops and gets
> re-established. I'm saying that from a software point of view, if a link
> drops, the software has to be prepared to receive new addresses when the
> link is re-established.

I doubt there is a general correlation there.
A host stack needs to be prepared for a new address at any point in time.
And in most cases the host will not even see l2 indications. Although that could be part of the heuristics to detect that the reachability of your current address set is in doubt.

> If take Fernando's example in renumbering, even equipment permanent installed
> in a datacenter may see a link getting moved from one vlan to another.
> 
>> The reachability check verifies that the next-hop router has a
>> forwarding entry for our route.  It does not guarantee anything
>> else.  e.g. in a multi-prefix multi-homed network, the host is the
>> only entity that can verify end to end reachability, and it has to
>> do it by probing (with all combinations of SA/DA).  The host stack
>> must treat addresses as candidates, where all have potential
>> different reachability.  Therefore, having stale addresses doesn't
>> so much matter.
> 
> This kind of probing is extremely tricky. The easiest way to do happy eyeballs
> is to just set up parallel connections to every possible address. Hosts have
> more than enough resources to do that.

Yes, and that's typically how a more advanced transport layer would work. Ref MP-TCP.

> This was quickly rejected by content providers who don't want to see the
> number of connects double. Instead happy eyeballs tries IPv6 first and only
> tries IPv4 after some time. 
> 
> For this reason, it is important to weed out broken addresses locally. If
> we can't use a shotgun approach to try all addresses at once, then we have
> to void trying the ones that don't work anyhow.

If a host has an address that has no reachability it has no cost to the far end destination that the host tries it. The packet gets dropped quickly anyway.

In the multi-prefix multi-home case you cannot weed out all "broken" addresses.
Some applications also wants to optimize for the best path, and that requires using all available paths and measure. And if you think about the multi-homing problem you will realise that it has overlapping solutions with the renumbering case.

Cheers,
Ole