>> "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).
i suspect that the problem many folk may have with saying "If the node is a router, redirect functionality MUST be implemented but SHOULD NOT be enabled by default," is that they fear that it will not get turned on in the vast majority of cases, many where it would 'help' (fix brokenness). it's like what i call "do-gooder software," when it patches over something broken, people never notice and say thanks. when it makes one error, all hell breaks out. i think you make the point that the latter is gonna happen. > Fixing DHCPv6 and adding prefix-length/mask seems a much more elegant > solution vs pushing redirect capability upon a large swath of devices. heresy!!! we're not hear to make moving from v4 to v6 easy. we're here to show infidels the 'right' way of doing things. randy -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
