Subject: RE: [psg.com #245] Mixed host/router behavior

From: "Soliman Hesham" <[email-masked]>
Date: Sat, 26 Jun 2004 21:30:19 -0400

> > => Not really. This is just a definition. When it comes to
 > > which interface forwards to which other interface this is 
 > > a matter of policy/configuration. If we were writing a document
 > > about VPNs I would understand your expectation, but this is 
 > > just a definition which applies, regardless of which interface
 > > is forwarding to any other interface.
 > 
 > 	as the Subject; line of the email says, once you define 
 > host/router
 > 	be per-interface thing, you will need to describe 
 > router behavior for
 > 	every possible combination of mixture of interface.  i 
 > still think
 > 	we did not finish describing simple all-host-interface 
 > behavior nor 
 > 	all-router-interface-without-virtual-router behavior, i strongly
 > 	object to the change.

=> ok I don't see that need to describe forwarding between 
interfaces in 2461bis. I also prefer to make a clear definition
than leave it empty. I'll let others say what they think
before I keep or remove the text.

I don't think there is a doc that describes a host/router
for v4 or v6. I find it difficult to see the reason for such
doc.

Hesham

 > > => Please see above. The change is only intended to indicate
 > > that the forwarding is on a per interface basis and is not
 > > intended to explain to vendors/operators how to build VPNs.
 > > 
 > > For instance, the definition of a router is a node that forwards
 > > packets, intended for other nodes, from one interface to another. 
 > > This definition stands regardless of the type of interface
 > > a router might use (physical, tunnel ...etc). 
 > 
 > 	see my objection above again.  we do not have a 
 > document unambiguously
 > 	describes simple host-or-router nodes.  we have to 
 > finish documenting
 > 	simple case first.  other stuff (like 
 > some-interfaces-are-host-and-
 > 	some-are-not box) can become different document, if necessary.
 > 
 > itojun
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 28 Jun 2004 18:15:18 +0900

(Forgive me for the late comment, too)

>>>>> On Sat, 26 Jun 2004 21:30:19 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

> for v4 or v6. I find it difficult to see the reason for such

I tend to agree with itojun in that it is not so trivial to define the
"mixed host/router behavior".

We have once discussed related points in the context of rfc2462bis.
See, for example, the following messages:

  http://www1.ietf.org/mail-archive/web/ipv6/current/msg01521.html
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg01524.html
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg01525.html

As pointed out in msg01521.html, the notion of "the per-interface
router" has not been well defined.  RFC2460 talks about something on
this, but it's still not clear whether a "mixed router" can
*forward-to* a host-side interface (see msg01525.html).  Perhaps the
clear definition itself is not in the scope of rfc2461bis, but I don't
think it makes sense to discuss how the mixed behavior is configured
in rfc2461bis (e.g., with the "IsRouter" variable Hesham proposed)
before clarifying the definition.

Regarding rfc2461bis, if we allow the mixed behavior, we also need to
clarify (at least) some other things that include:

- whether a mixed node can receive an RA on a "host" interface to
  configure a default router list
- if it can, how the configured default route interacts (or does not
  interact) with other routes used for forwarding on "router"
  interfaces.
- whether a mixed node can receive an ND redirect on a "host"
  interface to adjust the route to a particular destination
- if it can, how the adjusted route interacts (or does not
  interact) with other routes used for forwarding on "router"
  interfaces.

Considering the lack of the base definition of the "mixed behavior"
and the complexity of the additional clarifications, I'd rather
concentrate on "all host" or "all router" nodes in rfc2461bis.  And
for that matter, I reached the same conclusion in rfc2462bis and
edited the 02 version that way (after confirming the decision on the
list).

Meanwhile, if we concentrate on the "simple" cases, I think we need to
clarify one thing.  RFC2461 has the notion of "advertising
interfaces".  An advertising interface is to control whether to send
router advertisement, and is, of course, defined per-interface basis.
It seems to me the existence of this notion is one source of the
confusion on whether the ND specification allows the mixed behavior or
not.  So, (if we concentrate on the "simple" cases), I think we should
emphasize 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, etc).

One last point: I hear that some implementations explicitly support
the "mixed behavior" (perhaps the Windows implementation?).  We may
(or may not) need to care about those existing implementations to edit
wording for rfc2461bis (at least we will not want to "invalidate"
those by this revise work).

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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 02:44:32 -0700 (PDT)

>   configure a default router list

Why? Per RFC 2461 the per router list is per interface.
There is an issue for the implementations (probably all implementations)
which have a per-node default router list, but from the perspective
of the RFC 2461 specification it has already punted on all aspects of
multi-interfaced hosts.

> So, (if we concentrate on the "simple" cases), I think we should
> interface, etc)

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.

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Jun 2004 15:24:58 +0900

>>>>> On Mon, 28 Jun 2004 02:44:32 -0700 (PDT), 
>>>>> Erik Nordmark <[email-masked]> said:

> Why?

Are you asking why (I'm saying) we need to "clarify" this point?  If
so, it's because I believe the point would be unclear (see below).

> Per RFC 2461 the per router list is per interface.

Yes, so if we allow the mixed behavior, then it is probably reasonable
to allow the node to accept RAs on a "host" interface and to configure
default routers on that interface.  My point is that we should
*explicitly* note that the rule for the multi-interfaced hosts also
applies to the host-side interfaces on a mixed-behavior node.

> since another router might redirect hosts to use the router that doesn't

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)

- if we allow the mixed behavior, then we should emphasize in
  rfc2461bis that even if a "router-behavior" interface is not an
  advertising interface, the node still acts as a router on that
  interface.

					JINMEI, Tatuya

---

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

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

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

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.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jun 2004 00:55:59 -0700 (PDT)

> applies to the host-side interfaces on a mixed-behavior node.

But it would be odd to do that only for the mixed case.
We have this discrepancy between 2461 and relality for the host case already
so shouldn't we also then explicitly note that the rule for the
multi-interfaced hosts apply to the multi-interfaced hosts?

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.

So without a specification that covers multi-interfaced hosts I don't
see how we can effectively build upon the multi-interfaced hosts behavior
to create multi-interfaced mixed-mode behavior; we do not have a stable
foundation to do this.

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.

Then separately, if folks want to work on multi-interfaced hosts
(which I think would be important given the discrepancy between reality
and RFC 2461), that could be done as a separate short specification.
Likewise if folks want to specify more of the issues about mixed-mode
nodes and/or offer solutions to them, that should be a separate specification.

   Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Jun 2004 21:27:07 +0900

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

> multi-interfaced hosts apply to the multi-interfaced hosts?

Perhaps we should.  I just thought that the notion of the "mixed"
behavior is quite new and might be more confusing for readers and so
we should be more vocal.  But this is probably a matter of taste.

(I guess the rest of your message will require more intensive
discussion, so I'm only answering the easiest part for now.)

					JINMEI, Tatuya