> > Can someone explain to me the rationale for mandating 4191 in 6204?
> > What was the scenario that was envisioned that necessitates 4191? 

> it was the only way we found to keep support for ULA prefixes.  the
> scenario is if you have a home CPE with ULA enabled, but no upstream
> IPv6 connectivity.  if that router advertises itself as a router for
> default, as opposed to router for ULA, host implementations that
> don't do 3484bis, and don't handle ICMPs, will contribute to IPv6
> breakage. e.g. 75 second time outs per TCP connection.

Seems to me, the real issue is the following (from RFC 6204):

   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].

   G-5:  By default, if the IPv6 CE router is an advertising router and
         loses its IPv6 default router(s) on the WAN interface, it MUST
         explicitly invalidate itself as an IPv6 default router on each
         of its advertising interfaces by immediately transmitting one
         or more Router Advertisement messages with the "Router
         Lifetime" field set to zero [RFC4861].

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.

Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to