Re: RFC3484 destination address selection rule 2 is buggy

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

At Wed, 26 Mar 2008 07:49:42 +0200 (EET),
Pekka Savola <[e-mail]> wrote:

> > v4:{site-local,global} is special and is not that harmful as long as
> > the network is properly configured (I know we cannot always assume
> > that, though).  When a link-local address is the only available
> > address for host, there should normally be no IPv6 default router
> > either.
> 
> The scenario where a router advertises the default route yet does not 
> advertise any prefix information (or prefix information does not set 
> the autoconfig bit) is still a valid scenario (e.g., I could imagine 
> DHCPv6-only deployments using this; in fact I believe if you want to 
> run DHCPv6-only this is the only choice to for deploying default 
> route) and it should be addressed.

In this case I'd expect the host has a valid global address obtained
through DHCPv6, so the original assumption in this thread (link-local
only host) doesn't hold (unless you're talking about the very short
period after receiving an RA and before getting a global address via
DHCPv6).

> Iljitsch noted in the original mail that his default route existed 
> even though he moved to ietf-464nat network (the nexthop was answering 
> to ping but was not sending RAs).

I understand the case, and agree that it's weird.  But at least
conceptually, the (non-)router should set the Router flag off in NA it
sends because it doesn't act as a forwarding router on that
interface.  Then the host should be able to remove that router from
its default router list pretty quickly.  I suspect the "router" in the
464nat kept the router flag on while it's not forwarding the packet.
I feel sympathy about the behavior implementation-wise, especially if
that node acts as a forwarding router for other interfaces, but it's
still due to a non-compliant implementation behavior, rather than an
inevitable protocol-level problem.

> It is true that the case made in draft-ietf-v6ops-v6onbydefault-03 is 
> already somewhat mitigated by implementations which no longer 
> implement the "on-link by default" rule but that alone does not seem 
> sufficient.
> 
> Is moving from one network to another (using the same interface) a 
> scenario where you should purge the default route? (Even if the 
> nexthop is still responsive?)  Should you purge the default route if 
> the link goes down (I suspect not -- e.g. with 802.11 link with bad 
> coverage this could be a problem)?

I admit it's difficult to solve the case with a nomadic host moving
from one link to another (but I'd say it's generally a different issue
from "v6:{link-local,global} vs v4:{site-local,global}).  In fact, the
BSD implementation I wrote tries to keep current set of addresses as
long as possible exactly to be sustainable while temporary link/router
failure.  But I also know that it does not always work and could
rather be harmful in some cases.

> It seems to me that there are also valid scenarios where exactly the 
> same problem appears in addition to many scenarios which are usually 
> due to misconfiguration.  I believe our protocols should be robust 
> enough to cover both valid scenarios and (if there aren't major 
> drawbacks) common misconfigurations.

In general, I don't disagree.  My point is that there are several
levels of the problems, from one that is inevitable within the current
protocol to one that could be avoided by properly implementing and
operating the protocol.  The former type of problem would warrant a
protocol-level update more strongly, while the solution for the latter
of the problem may be controversial.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------