"Hemant Singh (shemant)" <[EMAIL PROTECTED]> writes: > [4. Redirect Clarifications
> Redirects are not sent by aggregation routers except when two hosts > behind the same bridge CPE, with no router between the host and the > aggregation router, communicate with each other. The aggregation router > sends a Redirect to a source host which communicates with a destination > host behind the same bridge CPE if the router can make a determination > that the two hosts lie behind the same bridge CPE.=20 OK. > The ICMP field of the Redirect message has a Target Address field. In > the presence of a Target link-layer address option included in the > Redirect, the host MUST NOT issue an NS to resolve the destination. No. A node MUST always be allowed to send out an NS if it has been told a destination is on-link (whether by PIO or by a redirect). Sure, in most cases after a redirect it shouldn't need to do so, but it must have the option of doing so. What if garbage collections times-out the associated link-layer address? > In the absence of any Target link-layer address option included in > the Redirect, host behavior depends upon the type of the target.=20 > If the target is a router, that router's link-local address is the > Target Address. The source IP address of a Redirect is always a > link-local address. If the target link-local address matches the source > IP address, then the L2 header of the Redirect message tells the host > the link-layer address of the target. I do not believe ND has ever _required_ looking at the L2 header to extract information. I.e, that is why we have Link-Layer Adress options as part of ND, so that the ND processing can be media-idependent. > The purpose of such a Redirect message is to tell a host that a > destination which the host assumes to be on-link is in fact > off-link. If the target address does not match the source IP > address, then the Redirect target is another router than the router > that issued the Redirect. In this case, the host MUST issue an NS to > resolve the link-local address of the target if the host does not > already have this address in its neighbor cache. This last sentence is not needed, as one always issues an NS to do address resolution if one doesn't have the necessary information.. That is pretty basic stuff. > This Redirect indicates that the destination is off-link, but the > host MUST use a different router than the one issuing the Redirect > in order to reach the destination. In summary, if the target of a > Redirect is a router, then the destination is off-link and the host > MUST NOT issue an NS to resolve a destination other than a > link-local address.=20 I don't know why all this MUST NOT stuff is needed. The host doesn't need to explicitly know that a destination is on or off-link. This all just happens correctly as part of ND processing. > If the target is a host, the target address is the same value as the > ICMP Destination address. On receiving this Redirect, the source host > MUST issue an NS to resolve a non-link-local destination if the host > does not already have this information in its neighbor cache. Once the > destination host responds to the NS, the source host will thereafter > send packets directly to the destination host. ] Again, I do not understand how the above text clarifies or otherwise changes anything in ND. > Such new text belongs in RFC 4861 but we ain't writing a 4861bis just > yet. So where does such text go? It has been included in our > on-and-off-link draft! Bottom line. I don't get why we continue to have this discussion. I remain unconvinced that there is a real problem here that needs fixing. The one thing that _might_ be worth putting in a document somewhere is a statement to the effect: A node only considers destinations to be on-link, if it has received an explicit indication that the target address is on-link (via a redirect) or if the address is covered by a prefix on-link indication (per a PIO option). Packets for all other destinations are forwarded through a neighboring router. But that said, ND has been around for more than 10 years now, has been implemented many times, and the vast majority of implementors have not been confused on this point from what I can tell. Even the implementation that triggered this discussion seems to concede it is not following the spec. Thus, I think the issue (to the degree that there might be one) is being blown way out of proportion. Don't we have real work to do here? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
