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

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 25 Jun 2004 23:00:45 -0400

> > For each multicast interface:
 > > 
 > >    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. 
 > > 
 > > This issue is now resolved
 > 
 > 	sorry about late comment, but how far would you like to go?
 > 	like interface A forwards to B (and vice versa), and C-D, ...
 > 	how would you describe?

=> I don't understand the comment. The definition implies that you
can't forward from a non-routing interface. Perhaps you mean
that you should be able to forward _to_ a non-routing interface?

 > 
 > 	i'm for simple "router or host" in document, and leave 
 > per-interface
 > 	"router" as a exercise for reader ("virtual router" 
 > concept is not new
 > 	so vendors will make such device anyways).

=> The issue at hand is that the doc is not clear on 
nodes that are both hosts and routers. Do you see any
harm in making the definition per interface? 

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

===========================================================
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: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 26 Jun 2004 12:27:43 +0900 (JST)

> that you should be able to forward _to_ a non-routing interface?

	no.  by making "router" per-interface, you could have multiple
	set of interfaces which forward packet to/from.  for instance,
	your router has 10 interfaces, and #1 is host mode, #2-#4 exchange
	traffic as router, #5-#9 exchange traffic as router (it's separate
	from #2-#4), and #10 is host mode.  once you go into "router/host is
	a per-interface thing" you need to describe such combinaions in full
	detail.  do you see my point?

> harm in making the definition per interface? 

	yes.  i see a big harm and disambiguity introduced by the change.
	again, keep the document simple, and let vendors do funny/complex
	things if they want to.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 26 Jun 2004 12:49:55 +0900 (JST)

> 	again, keep the document simple, and let vendors do funny/complex

	s/disambiguity/ambiguity/

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 01:04:23 -0700 (PDT)

How about a compromise that makes it clear that
 - isRouter and all other ND configuration and state is per interface
   thus there is nothing in the specification which prevents a node
   being a host on some interfaces and a router on other interfaces.
   The behavior of such nodes on a particular interface is specified
   in this document.
 - the details of how such nodes work across interfaces i.e. how the node
   determines which interfaces forward packets between each other etc
   are out of scope for the document.

  Erik

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 28 Jun 2004 18:37:01 +0900 (JST)

>    are out of scope for the document.

	i do not like this way.  i would like to put:
	- a node is either a host or a router.  it is a per-host property,
	  not per-interface property.  "advertising interface" has nothing
	  to do with host/router (as jinmei described)
	- (if really necessary) in Appendix, talk about mixed mode node,
	  and benefits/caveats/pitfalls in doing so.  even if we do not write
	  it up, vendors will do it anyways so my preference is not to mention
	  mixed mode at all.

itojun

---

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

> 	  it up, vendors will do it anyways so my preference is not to mention

If folks have already built such things or are thinking about building them
I think we need to write down at least as much necessary for the ND
protocol to still interoperate with those boxes. Thus I don't think
we need to write down how to make such boxes "work" in general,
but we do need to write down how they should act on the
interfaces on which they prentend to be a router and on the interfaces
on which they pretend to be hosts as it pertains to the ND messages
that are sent and received.

  Erik

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 28 Jun 2004 08:06:41 -0400

IPsec security gateways often find themselves in the "mixed
host/router" role, acting as a host on some links and as a router on
others.

If the IPv6 WG declines to define mixed host+router node behavior, the
IPsec WG might find itself needing So.

The same might be true for other WG's as well.

We might end up with multiple conflicting specs for mixed behavior
nodes.

						- Bill

---

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

>>>>> On Mon, 28 Jun 2004 08:06:41 -0400, 
>>>>> Bill Sommerfeld <[email-masked]> said:

> We might end up with multiple conflicting specs for mixed behavior

At least regarding forwarding aspects of the "mixed" behavior
(i.e,. from which interface to which packets can be forwarded), I
think it's beyond the scope of rfc2461bis.  I don't have a particular
opinion on whether the ipv6 wg can/should take the role of the
definition, but IMO it's even not specific to IPv6 (perhaps as you
implicitly indicated above), so it seems to me the best place is
somewhere else (probably in the routing area?).

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

---

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

>>>>> On Mon, 28 Jun 2004 01:04:23 -0700 (PDT), 
>>>>> Erik Nordmark <[email-masked]> said:

>    are out of scope for the document.

If the "details" is limited to non-ND issues like forwarding stuff, I
can live with this compromise.  (I still prefer the "simplest" way,
but I also admit the opinions may vary on this.)

However, I still want to have detailed clarifications on ND-related
implications on this, including the ones I pointed out in a separate
message:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg02912.html

Otherwise, the implementors (including myself!) will soon wonder how
we should implement this, and I believe it's irresponsible for spec
writers to just say "it's out of scope of this doc" if they dare to
open Pandora's box.

BTW: if we take this compromise, do you also want to take similar
approach in rfc2462bis?

					JINMEI, Tatuya