Linux and ULA support and default route
otroan at employees.org
otroan at employees.org
Fri Oct 14 15:26:08 CEST 2016
>>>>> 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?
More information about the ipv6-ops