Ole Troan <otr...@employees.org> writes: > > That is, a CPE router with multiple LAN interfaces is not allowed to > > advertise itself as a default router (when it loses internet > > connectivity), when that is arguably a fine thing for it to do. > > > > I have to wonder whether RFC 6204 has gotten this wrong. It is very > > CPE centric, assuming it is the only router on the home network. It > > has conflated the notion of a router being fine as a default router > > for the hosts attached to the same link (i.e., via RAs) and the the > > more traditional router notion of default route. > > > > I.e., if the CPE router has multiple LAN interfaces, each with a ULA > > (or other prefix) assigned to it, advertising itself as a default > > router seems like a perfectly reasonable thing to do.
> indeed, but unfortunately that causes IPv6 breakage. this is not at > all CPE centric, from the CPE perspective advertising itself as a > default router is obviously not an issue. the problem is host > implementations that have a ULA address and a default route (but no > connectivity to the IPv6 Internet). these hosts will choose IPv6 > first when connecting to dual-stack destinations, this leads to > multi-minute time outs. Let me be sure I understand. Which 3484 rule comes into play that has an impact here? Is it: Rule 1: Avoid unusable destinations. If DB is known to be unreachable or if Source(DB) is undefined, then prefer DA. Similarly, if DA is known to be unreachable or if Source(DA) is undefined, then prefer DB. I.e., if trying to reach a site, and the IPv6 address is "unreachable" per above, choose the v4 address? (Sounds great in theory!). So the CPE rule that says you MUST NOT advertise yourself as a default router if you don't have real IPv6 connectivity is intended to result in all destinations (other than local ones) showing up as "unreachable" when the above rule happens? Is this the intention, or am I looking at the wrong scenario here? > we had some very extensive discussions on this exact point during > the last call of RFC6104. I hope we do not have to rehash those > here. I'll try not to. :-) Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
