RFC 2460 provides this note in the terminology section: Note: it is possible, though unusual, for a device with multiple interfaces to be configured to forward non-self-destined packets arriving from some set (fewer than all) of its interfaces, and to discard non-self-destined packets arriving from its other interfaces. Such a device must obey the protocol requirements for routers when receiving packets from, and interacting with neighbors over, the former (forwarding) interfaces. It must obey the protocol requirements for hosts when receiving packets from, and interacting with neighbors over, the latter (non-forwarding) interfaces.
I believe this covers this scenarios described below. Organizations have already started to define v6 requirements based on this note using host on 1 interface / router on another interface model. It would be nice to have specific terminology definitions for this configuration but changes would need to be made to 2460 as well. Brian Russell Systems Engineer Booz Allen Hamilton [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of JINMEI Tatuya / ?_-?'B?A Sent: Thursday, February 05, 2004 7:28 AM To: [EMAIL PROTECTED] Subject: [rfc2462bis issue 278] 2462bis for "routers" There was an issue about how much we should allow a router (not a host) to use the RFC2462 spec to configure itself. Specifically, a) if a router can configure a global address by stateless autoconf b) if a router can configure a link-local address in a way described in RFC 2462 c) if a router can configure itself about "other" configuration information and I suggested in Minneapolis "a=NO, b=YES, c=NO". I then noticed this was actually pretty clear in the original RFC2462. It says in Introduction that: The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface. So, my current resolution for this is "do nothing". However, we may have to clear whether the definition of a "router" is per-interface basis. The current definition in RFC2462 is: router - a node that forwards IP packets not explicitly addressed to itself. which I would NOT call per-interface basis. If we agree on adopting the per-interface definition, we'll probably need to revise the definition in the "TERMINOLOGY" section. Additionally, adopting this definition also opens up the possibility of a "half-host, half-router" node, like: ------(I1)Node(I2)------- (I3) | | where I1 and I2 are "normal" interfaces for which the node is acting as a router, and I3 is an interface to a "back-door" for which the node is acting as a host. This node can accept a router advertisement on interface I3 to configure an address or even configure a "default route" to I3 (though the latter part is out of scope of 2462bis). Should we, if adopting the per-interface definition, explicitly mention this type of configuration in rfc2462bis? 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
