Alain Durand <adur...@juniper.net> writes: > I have a question about draft-ietf-6man-node-req-bis-05.txt. > Section 5.2:
> Redirect functionality SHOULD be supported. If the node is a router, > Redirect functionality MUST be supported. > However, draft-ietf-6man-node-req-bis-05.txt refer to the normative > text on Neighbor Discovery, ie RFC4861 that says: Section 8.2: > 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 > - the Destination Address of the packet is not a multicast > address. > It seems that the Node requirement text is going above and beyond > what is required by RFC4861, transforming the SHOULD into a MUST. Note, this change was actually made by RFC 4294, way back when. The current ID hasn't changed that. > I might have missed (or do not remember) the discussion, is there a > reason for this change? And shouldn't the ND spec have been changed > first to allow to upgrade the SHOULD into A MUST? One the realities we have to deal with is that some of our specs were written a long time ago, and things you might think today need to be said explicitly, simply weren't. My recollection as a co-author of ND is that it was always assumed that *all* routers would implement redirects. This was so obvious, it just wasn't deemed necessary to write explicitly in the draft. The SHOULD language above, is about when to actually send a redirect, not about whether to implement the functionality itself. There are times when (for a given packet) it wouldn't be appropriate to send one. But that would be a run time decision, not an "implement or not" decision. > For the record, I support the SHOULD in RFC4861 and I would rather > like to see the node requirements document say the same thing. The other problem we are now dealing with is that IETF documents have exactly two classes of devices: hosts and routers. And maybe even more explicitly, routers and non-routers. This comes from the basic definition (from RFC 2460): > host - any node that is not a router. [See Note below]. > > router - a node that forwards IPv6 packets not explicitly > addressed to itself. [See Note below]. The reality is that the Internet ecosystem has a wide variety of devices now, and many don't cleanly fit into either category. Even routers are hosts, when they act as the sender or originator of traffic. Even with routers, this thread talks about edge routers (those on networks where hosts connect) and SP internal links (which are mostly or always p2p). Clearly, we could could think of functionality critical for one type of device but irrelevant (or maybe worse) for the other. I don't think we are in a position with the node requirements document to try and slice those kinds of hairs. We'll never get anywhere... FWIW, I'm in favor of MUST implement, since the idea of a generic edge router not implementing redirects seems like something we should not encourage. Also, I'm not convinced yet that the cost of implementing redirects is particularly a problem in the general case, which is what this document is all about. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
