Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update might break current ULA+IPv4 hostnames

[Ole Troan <[e-mail]>]

David,

> > Normally, Host A's ULA address should have a path through the local
> > network to Host B's ULA address and vice versa, so Host A and B's ULA
> > addresses should be preferred over Host A and Host B's GUA addresses.
> 
> Come to think about it. Wouldn’t RFC6724 also fail in the MPMH case?
> 
> Yes, it will fail in some cases but succeed in others.
>   Source host A with GUA1+GUA2 (from ISPA AND ISPB)
> And destination host B with GUA3. 
> 
> 6724 will return the source address with the longest matching prefix to GUA3. So only one of these:
> 
> {GUA1, GUA3}
> {GUA2, GUA3}
> 
> The SA determines exit path, so depending on which ISP is down. Communication will fail.
> Redundancy is the whole point of multi-homing…
> 
> If there is a soft failure of the provider of the selected SA, there will be a failure. If there is a hard enough failure to cause the withdrawal of one of the RAs, then redundancy will work.

Using addressing as a reachability indicator is wrong. RAs may only work when hosts are  directly connected to exit. 

>   The other case I am concerned about is the one where within a single network multiple routers make up their own ULA and use that to assign addresses to directly connected hosts but do not participate in routing. We then have multiple disjointed ULA domains within the network. With RFC7078 and SNAC routers I am not sure if we can avoid that. This would possibly have been cleaner with site-locals.
> 
> In many cases you refer to, the disjoint ULA domains are likely to be ULA-only domains. If there are ULA-only domains, there will only be ULA destinations to try, and they will be reachable or not. When we mix ULA, GUA, and IPv4, things get really complicated. ULA-only domains should be relatively straightforward.

Just working through all the cases where the 6724 approach fails.
From a 4007 point of view it’s possible to deploy ULAs in a more complex (and convoluted) fashion than site-locals.

Anyway, from a pure 6724 perspective. Why isn’t the correct solution to return all candidate sources for a given destination, instead of only the “best”. Then it’s up to the upper layers to walk through the list of candidate sources / candidate destinations until one or multiple connections is achieved.

As Brian has pointed out this may have some consequences for the Linux APIs, but then again we aren’t standardising this for only one implementation either.

O.