Thomas, >>> 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?
that is indeed the intention. this also appears to work well regardless of a node implementing 3484 or not. >> 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. :-) thanks. ;-) cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
