Thomas, Sorry, there was a typo in a statement I made in which "router" should be "host". The erroneous statement is snipped below.
"it's left to the vendor if they would like to do any optimized processing of Redirect along with L2 header when the router has all information for L2 media type." Hemant -----Original Message----- From: Hemant Singh (shemant) Sent: Friday, December 14, 2007 12:16 PM To: Thomas Narten Cc: [EMAIL PROTECTED]; Erik Nordmark; IETF IPv6 Mailing List; Suresh Krishnan; Josh Littlefield (joshl) Subject: RE: Here is the reference to 6.3.4 text that is ambigious text Thomas, Thanks for this email. First, here is a running list of why we think our on-and-off-link draft should exist. 1. We presented to the IPv6 community that RFC 4861 does not include in section 8.3, a case for when Redirect does not include Target Link-layer address option (TLLAO). Such a Redirect is common to be encountered in an IPv6 network. Therefore either a 4861bis discusses it or our draft does. 2. Since Redirect can suggest a better first-hop that could be on- or off-link, our intent is to dissect Redirect more carefully because we have found show stopper issues with on- vs. off-link determination in an aggregation routed network. We think we do provide ample evidence in line below for our case of confusion related to on- vs. off-link in the ND RFC. 3. We see hosts are confused between the boundary of what should DHCPv6 handle and dole out vs. what should ND handle and dole out. Can the community show what text in RFC 3315 or RFC 4861 and 4862 defines such boundaries or the justification for such boundaries - this is a deployment that includes both a DHCPv6 server and an IPv6 default router. Our draft is defining such boundaries, although that is not the primary intent of our draft. An example of hosts being confused about this boundary is shown in bug 2.3 of our ND implementation draft - draft-wbeebee-nd-implementation-problems-00. Now, please see in line below for our responses included between <hs> and </hs> or <wb> and </wb>. -----Original Message----- From: Thomas Narten [mailto:[EMAIL PROTECTED] Sent: Friday, December 14, 2007 8:54 AM To: Hemant Singh (shemant) Cc: Josh Littlefield (joshl); Erik Nordmark; IETF IPv6 Mailing List; [EMAIL PROTECTED]; Suresh Krishnan Subject: Re: Here is the reference to 6.3.4 text that is ambigious text "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? <hs> Garbage collection will need to issue a unicast NS that is a Neighbor Unreachability detection. Our text says MUST NOT issue an NS to resolve the destination - this is a multicast NS. But if NUD fails, you are totally correct that the node will have to send out an NS. This texts need rewording in our draft. </hs> > 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. <hs> Makes sense to have ND processing be media-independent. However, we should still have such text but preceded by comments like, "it's left to the vendor if they would like to do any optimized processing of Redirect along with L2 header when the router has all information for L2 media type." Makes sense to have a router vendor have such flexibility. </hs> > 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. <hs> Sounds fine. We can remove such a statement. </hs> > 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. <wb> The consequences of "correct ND processing" need to be ironed out because: 1) hosts don't always implement ND in the same way, 2) routers need to know what behavior to expect from hosts, and 3) RFC 3756, section 4.2.5 (Bogus On-Link Prefix) states "If a sending host thinks the prefix is on-link, it will never send a packet for that prefix to the router." <wb> <hs> 4) If a host incorrectly assumed a packet destination to be on-link when the host was supposed to treat the destination as off-link, the host can issue an NS to resolve the destination. The router may not respond to this NS and the host eventually times out sending the packet out. In an Ethernet LAN, the router will respond, but in an aggregated routed network, the aggregation router does not respond to any address resolution for non-link-local address from any client on the router upstream. The aggregated routed network for IETF folks is a point to point link topology. An example of such a router is a cable router terminating over 60,000 IPv6 cable modems with IPv6 hosts behind the modems. We have explained the aggregation router in numerous emails to IETF mailer. </hs> > 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. <hs> We have this paragraph to discuss the Redirect case when no TLLAO is included in Redirect. We have to complete the no TLLAO text for the case when the Target was a host vs. a router. </hs> > 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. <hs> Hmm, the text above still does not cover the two cases for on-link as specified in section 2.1 of the on-link definition. - a Neighbor Advertisement message is received for the (target) address, or - any Neighbor Discovery message is received from the address. For a third case, the on-link definition in section 2.1 of RFC 4861 does not mention the fact that manual configuration in out of scope of the ND RFC. Manual configuration is a can of worms that can mess up prefixes, prefix length, on- and off-link determination, and can cause security problems. Do you know what do host vendors tell us when we complained to them that their host was incorrectly adding a default route from a conjured up prefix and prefix length based on what the host got for a DHCPv6 address? The incorrect behavior causes a Show Stopper data forwarding problem in cable router for an IPv6 host. They tell us, gee, how do we know you didn't configure the default router manually? Do you want to deal with such comments. I would rather put some text in the RFC that says manual configuration is out of scope. That is why we have bullet 2 in our on-and-off-link drafts that says: [The on-link definition in section 2.1 of RFC 4861 (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)," September 2007.) [ND] describes the only means for on-link determination. DHCPv6 or any other configuration on the host MUST NOT be used for on-link determination. Manual configuration of a host introduces its own set of security considerations and is beyond the scope of this document. Note that the on-link definition as specified by RFC 4861 (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)," September 2007.) [ND] does not include manual configuration.] Further, Josh Littlefield from Cisco said something similar to your suggested text last week. We have to have ND specify that the default mode is off-link. See how even an author of the ND RFC can say one thing in an email when the ND RFC says another thing. Hesham emailed the text in double quotes below. "Instead, clearing the L flag means that the host should not assume that an address derived from this prefix is on-link." But the RFC text says the following about the same issue shown below in square brackets. [Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link.] We have to be careful when we say "not assume off-link" vs. "not assume on-link" or both. I think such text in the ND RFC is confusing when one could remove all this text about "not assuming on-link" and "not assuming off-link" in the RFC and replace it by what Josh suggested first- the default mode is off-link. Then reword some text around that. I will re-send Josh's email to this mailer soon. </hs> 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. <hs> I suspect for the past ten years ND has been tested in Ethernet LAN networks (wired or wireless), or any cellular networks, and that too in on-link mode. We started testing ND eight months back with off-link since that is the only model for an aggregation router hosts. In our off-link test, a host is sent an RA with no PIO, but the host did not send all non-link-local traffic to the default router. Instead the host assumed on-link and when the host was asked to forward a packet out, the host issued an NS to resolve the destination. Since the aggregation router does not reply to any address resolution for non-link-local addresses from hosts on the router's upstream, the host keeps sending NS's while holding the packet in a queue. Eventually the host timed out and failed to send the packet out. The same problem exists when another destination pings this host and when host has to send a ping reply, the host tries again to issue NS and fails to send the reply. Incorrect on- vs. off-link determination caused this Showstopper problem in an aggregation router network. See bug 2.1 in draft-wbeebee-nd-implementation-problems-00.txt that reports this problem. Do NOTE this bug occurs in an Ethernet LAN too, but the effect of the bug is less severe in Ethernet LAN because the router can respond to the NS. We want on-and-off-link iron clad in the RFC because if a slight mistake is made, one can see a show stopper problem for data forwarding. First, congratulations are due to the ND authors for designing ND well to work in yet another network like the cable aggregated routed network. But welcome to some minor demands from folks form such a network. </hs> I hope Alain Durand from Comcast is listening on this thread. Hemant Don't we have real work to do here? Thomas - Wes and Hemant -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
