On Aug 14, 2010, at 7:46 PM, Hemant Singh (shemant) wrote: > > Again, sorry to be a nag but such a question should have been raised > when RFC 2461 or RFC 4861 were being discussed in the IETF. The > Node-Req document is only putting in text for what is already agreed > upon in an RFC like the RFC 4861. I suppose the community did find a > need for Redirect and that is why this functionality was added to IPv6 > ND. However, here is one use case and let anyone else chime from the > RFC 2461 and RFC 4861 development days for more use cases.
I'd like to suggest the premise that people who have not been around and involved since low level numbered RFCS not be told they should have retroactively raised their concerns when not involved. :) (Also, apologies for jumping in mid-process for the rest of my life ...) > Therefore, I am still for what Brian Carpenter suggested. Here is > proposed new text for Redirect. > > "Redirect functionality SHOULD be supported. If the node is a router, > Redirect functionality MUST be implemented and SHOULD be enabled by > default." I'd like to recommend that it SHOULD NOT be enabled by default. There are a number of cases where some default behavior (eg: "ip directed-broadcast") future becomes an operational risk. Now this may be something that is left up to the discretion of a vendor and that wiggle room is available here. I certainly don't mind if a CMTS solution has redirects enabled for DHCPv6 clients, but the idea they would get a delegation without prefix-length information in v6 seems to be broken IMHO. Pushing this requirement onto a network core because it is a "router" is perhaps not the best solution due to someones arguably "broken" edge. That certainly does not exist within IPv4 and I'm not sure why someone would set out to degrade the services provided in IPv4. Additionally, the role of a device in the network may dictate the necessity of the redirect capability. I certainly don't see a need of devices in a core role to be generating or listening to such noise. Vendors have typically starved CPU resources on devices based on long-term supply chain capabilities making it hard or impossible to upgrade a devices that needs to handle such items in the software-path vs hardware. (Yes, the rate-limiters help here, but any node that appears to misbehave does create customer-support inquiries even if it's not actually a problem, eg: high ping/traceroute times when "bgp scanner" runs in IOS). Fixing DHCPv6 and adding prefix-length/mask seems a much more elegant solution vs pushing redirect capability upon a large swath of devices. - Jared (Willing to be educated if items are incorrect here). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
