>> I'd like to recommend that it SHOULD NOT be enabled by default.
> Please understand one point I made earlier on this thread. The IPv6
> node-req-bis document is capturing what is specified already in RFC 4861
> for Redirect. So if you want the node-req-bis document to specify
> anything contrary to RFC 4861 and Redirect, you have to take that up as
> a separate discussion on RFC 4861 and Redirect.
seems to me that, first, we should try to understand what is the right
engineering. then the professional standards folk can figure out how to
make sausage out of it.
> We should not stall the node-req-bis document.
when someone tells me it's a rush, i slow down and look around and
wonder why i am being asked to rush.
> Redirect functionality is a SHOULD for router since RFC 2461 and has
> continued to be a SHOULD in RFC 4861.
should implement or should enable by default? 8.2 says
A router SHOULD send a redirect message, subject to rate limiting,
whenever it forwards a packet that is not explicitly addressed to
itself (i.e., a packet that is not source routed through the router)
in which:
- the Source Address field of the packet identifies a neighbor,
and
- the router determines (by means outside the scope of this
specification) that a better first-hop node resides on the same
link as the sending node for the Destination Address of the
packet being forwarded, and
and i am trying to understand this from two viewpoints
o is this specifying default behavior? i think you can make a case
for this. so, if we think it is best engineering not to have it
default, this would need to be clarified.
o what this says about p2p links, in particular how this affects the
discussion of /127 p2p links. that second condition might be
construed as not being satisfied. could someone please clarify?
> since the fact is known about the Redirect default on a router to be
> enabled, one can always disable the functionality before use of the
> router in their network.
or vice versa.
randy, who has been bitten by interfaces being chatty by default so is
still trying to understand
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------