> I see the point in that we should try to fill in the gap between the > reality and 2461bis/2462bis. However, I still don't see if this means > we need to introduce the new notion of IsRouter as a per interface > variable, allowing the mixed host/router behavior. In fact, the fact > you are not sure about implementations that has a per-interface > default router list seems to indicate the "mixed" behavior does not > exist in reality. Then why should we bother to introduce the > additional complexity? > > (Previously I said I heard of an implementation that can act as a > router/host per interface within a single node -perhaps an Windows > implementation. If this is really the case, that can surely be an > example of the real world. But no one has confirmed that information > in this thread yet)
I think the high-order question is whether mixed-mode implementations exist or whether folks are working on building such things. If not we can limit any text in 2461bis to what's needed for folks to not be confused by the footnote in rfc 2460 about per-interface behavior. I vaguely recall that the text was added to 2460 because there was some interest in mixed-mode nodes. Does anybody recall more of the background? > Anyway, if there is surely a gap between the current specification and > the real world implementations, > > > Which is why I think 2461bis should > > - state that because the protocol operates separately per interface > > there is nothing which precludes a node from being a router on > > some interfaces and a host on other interfaces. But that there > > are significant issues, all out of scope, terms of building such > > mixed mode nodes. > > - (optionally) Create an appendix, akin to appendix A for hosts, > > which state the known issues for mixed-mode nodes. > > I can personally live with this approach, as long as we make it clear > that there are (many) open issues to actually make it work and do not > pretend that it is easy/trivial to realize. > > Others who objected to including the mixed behavior in rfc2461bis may > still have a different opinion, though. I haven't seen any objections so far. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
