On Sun, 15 Aug 2010 16:17:53 -0400 Jared Mauch <[email protected]> wrote:
> > 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. > I'm don't understand at all how DHCPv6 prefix-length/mask would prevent the situation that redirects are trying to address. The situation occurs when a router knows more about the prefixes/nodes on the link than the onlink node that sent the packet in the first place. It seems to me that redirects are there to fill in the sending node's prefix knowledge gap, during a transient situation. If nodes fully know all the onlink prefixes, via correctly configured RA PIO options, then redirects won't occur. It seems to me that arguing against redirects is actually arguing for having a common case, rather than an transient one, of nodes that don't have full onlink prefix knowledge. I think having all nodes attached to the link (i.e. both hosts and routers) being fully aware of all onlink prefixes is a much better idea. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
