Linux and ULA support and default route

[Holger Zuleger]

On 14.10.2016 15:26, otroan at employees.org wrote:
> Holger,
> 
>>>
>>>>>> Imagine a setup with *two* routers.  One of them has broken Internet,
>>>>>> the other is working.  How can the hosts decide if both keep announcing
>>>>>> themselves as "I can reach anything"?
>>>>>
>>>>> in the general case the host still has to take the 'I can reach anything' announcement with a pinch of salt.
>>>>> and it should be able to try both (or more) connections and react accordingly when one fails.
>>>> ...which is the default host behaviour if the OS supports RFC4861.
>>>> Sadly some "user friendly" network mangers breaks this and setting a
>>>> static route with a better metric to just one(!) router.
>>>
>>> not really. that only covers the first hop. any failure anywhere else along the path would not be dealt with by 4861.
>> Yes, of course, you're right.
>>
>> But coming back to Brians problem.
>> The behavior of his router is confirm to RFC7084:
>>
>> "G-4:  By default, an IPv6 CE router that has no default router(s) on
>>         its WAN interface MUST NOT advertise itself as an IPv6 default
>>         router on its LAN interfaces.  That is, the "Router Lifetime"
>>         field is set to zero in all Router Advertisement messages it
>>         originates [RFC4861]."
>>
>> But this would break local connectivity if the router does not also
>> fulfill L-3
>>
>> "L-3:   An IPv6 CE router MUST advertise itself as a router for the
>>          delegated prefix(es) (and ULA prefix if configured to provide
>>          ULA addressing) using the "Route Information Option" specified
>>          in Section 2.3 of [RFC4191].  This advertisement is
>>          independent of having or not having IPv6 connectivity on the
>>          WAN interface."
>>
>> So far so good. But if the host doesn't honour the RIO then again local
>> connectivity is broken.
>>
>> So take a look at the reasons for this. The second paragraph of 3.2.1 says:
>>
>> "At the time of this writing, several host implementations do not
>>   handle the case where they have an IPv6 address configured and no
>>   IPv6 connectivity, either because the address itself has a limited
>>   topological reachability (e.g., ULA) or because the IPv6 CE router is
>>   not connected to the IPv6 network on its WAN interface.  To support
>>   host implementations that do not handle multihoming in a multi-prefix
>>   environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not,
>>   as detailed in the requirements below, advertise itself as a default
>>   router on the LAN interface(s) when it does not have IPv6
>>   connectivity on the WAN interface or when it is not provisioned with
>>   IPv6 addresses.  For local IPv6 communication, the mechanisms
>>   specified in [RFC4191] are used."
>>
>> At the end, the whole behavior is because some host have problems in
>> handling situations where they have an IPv6 address configured and now
>> internet connectivity. But the solution to this requires that the host
>> is able to understand and work with RIO options, which seams to be "at
>> the time" not generally the case.
>>
>> Do we replace one evil by another?
> 
> Yes, we did.
> This work was done at the time of "host IPv6 brokenness".
> Perhaps time to revisit those decisions?

Personally I think it's not worth the effort. I believe that we end up
with quite more complex home network environments in the near (ok "near"
has to be defined somehow) future.

Better let's work on those...
And in the meantime fight for correct host behaviour and (just as one
example) RIO support.

By the way: Does anyone know if (or when) Cisco will support Route
Information Options in router advertisements? :-)

BR
 Holger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4160 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20161014/b07f2a12/attachment.bin