Linux and ULA support and default route

[Holger Zuleger]

On 14.10.2016 14:33, 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?

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: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20161014/25234815/attachment.p7s>