>>>>> On Tue, 29 Jun 2004 00:55:59 -0700 (PDT),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
> I think the right solution is to fill in the gap between 2461 and reality
> where in reality implementations handle multiple interfaces yet 2461
> is silent on the issue (except saying that everything is maintained per
> interface). I sure don't know of an implementation which has a per-interface
> default router list.
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)
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.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
