Subject: Re: RFC2461bis: Semantics of "advertising interface"

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 15 Jul 2004 16:30:46 +0900

(Catching up some old messages...sorry for the delayed response.)

>>>>> On Tue, 29 Jun 2004 00:52:23 -0700 (PDT), 
>>>>> Erik Nordmark <[email-masked]> said:

> [New subject since this is a separate issue. How do we get an issue
> number allocated?]

As far as I know, only the main editor (as well as the site
administrators of course) can create a new issue.  In this case,
you'll need to ask Hesham to create a new one.

>> > Whether or not we concentrate on the "simple" case, I think it
>> > makes sense to state that a non-advertising interface is still
>> > one that behaves as a router e.g. the R-bit in the NA should be set
>> > since another router might redirect hosts to use the router that doesn't
>> > advertise itself.
>> 
>> Hmm, I agree.  Let me rephrase this point then:
>> 
>> - if we concentrate on the "simple" cases, then we should emphasize in
>> rfc2461bis that even if an interface is not an advertising interface
>> the node still acts as a router on that interface (e.g., it can
>> forward from/to that interface, exchange routing information on that
>> interface, set the R-bit in NAs, etc)

> Minor issue: RFC 2461 doesn't talk about exchanging routing information
> now so for consistency we shouldn't introduce that in only one place.
> Either we carefully introduce it where needed, or we don't introduce it at
> all.

I concur.  Actually, I just expressed what I'd envision as a router,
and did not intend to recommend rfc2461bis to have the exact wording.
I think it makes sense to not introduce "routing exchange" at all.

> Major issue: RFC 2461 actually says that in 6.2.2:
>       - enabling IP forwarding capability (i.e., changing the system
>         from being a host to being a router), when the interface's
>         AdvSendAdvertisements flag is TRUE.

> This is not how I recall the intent when we wrote the spec. But RFC 2461
> is consistent on this point; a router has AdvSendAdvertisements set.
> If it doesn't want to be a default router the RAs would
> have a router lifetime of zero.

That's right, so I'm not sure how this can be a new issue.  Do you
want additional clarification on this in rfc2461bis?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 15 Jul 2004 17:23:22 +0900

>>>>> On Tue, 29 Jun 2004 00:55:59 -0700 (PDT), 

> 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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 28 Jul 2004 06:47:08 -0700 (PDT)

> example of the real world.  But no one has confirmed that information

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?

> still have a different opinion, though.

I haven't seen any objections so far.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 28 Jul 2004 06:58:38 -0700 (PDT)

> want additional clarification on this in rfc2461bis?

It seems like in 2461bis-00.txt that the introduction of IsRouter in
6.2.1 is inconsistent with the text in 6.2.2 about AdvSendAdvertisements.

RFC 2461 reads as if a node "advertises" itself as a router (by sending RAs
and setting the R-flag in NAs any time AdvSendAdvertisements is set.
Thus the "AdvSendIsRouter" is really the same as AdvSendAdvertisements.
(Note that reusing "IsRouter" is confusing since that is the name of
the conceptual per-neighbor cache entry variable.)

Thus I think we can accomplish the intended clarification by changing section 
6.2.1 FROM
      IsRouter       A flag indicating whether routing is enabled on
                     this interface. Enabling routing on the interface
                     would imply that a router can forward packets
                     to or from the interface.

                     Default: FALSE

      AdvSendAdvertisements
                     A flag indicating whether or not the router sends
                     periodic Router Advertisements and responds to
                     Router Solicitations.
TO
      AdvSendAdvertisements
                     A flag indicating whether or not the node performs all of
			- sends periodic Router Advertisements, 
			- responds to Router Solicitations, and
			- forwards packets to or from the interface.
		     In short, whether or not the node behaves as a router
		     on the interface.
		     In particular, AdvSendAdvertisements affects whether
		     the R-flag in the Neighbor Advertisement messages is set.

   Erik