Ralph, Vendors seem to have been testing IPv6 with only on-link prefixes including our own company in Cisco. Soon as we guys in Cisco began testing IPv6 in off-link mode, bugs in hosts began showing up. These off-link tests don't even exist in TAHI IPv6 host tests but TAHI has certified hosts as IPV6 ready :-). If not for any other reason, 6man should document these bugs in the format of RFC 2525 and let TAHI write up new test cases. In the past six months, I have contacted TAHI but the process with them seems slow. They still haven't added our test cases for off-link in their test suite for IPv6 hosts. Bugs 2.1 and 2.3 do need to be added to TAHI.
As for 2.1 and 2.3 may be related or may not - we don't have access to the source code of this host. Do note 2.1 and 2.3 are two distinct bugs in the host. 2.1 is host assuming on-link for a destination when host should have assumed off-link. This is the case when router sent the host an RA with no PIO. 2.3 is incorrect host behavior for adding a route based on host using an invented prefix (assuming a default prefix length) that is partially derived from the acquired DHCPv6 address. As for 2.4, when I explained to Erik in the hallway at IETF as to what an aggregation router behavior is, he explained to me that this router behavior maps to a point-to-point link. I agree with him. Such a link is well-known to the community. Anyhow, data behavior properties of an aggregation router are also discussed in our on-and-off-link draft. Our on-and-off-link draft explains the behavior in section 3.1 and 4. My IETF presentation also said subscribers behind modems in an aggregation router are always off-link (IPv4 or IPv6). These subscribers cannot talk directly to each other. So the aggregation router which is also the IPv6 default router is lying to any subscriber if this router sends Redirects to the subscriber because such subscribers cannot talk directly to each other. There is one exception to this case which is explained in following text snipped from section 4 of our draft(in square brackets): [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.] When I explained to Erik he understood this aggregation router behavior in a jiffy. Aggregation routers do not send Redirects - this behavior falls out from the fact that subscribers are off-link in an aggregation network. As a reminder, both 2.1 and 2.3 bugs are reproducible in an Ethernet LAN too. These bugs have nothing to do with an aggregation router although this router is an excellent device to test off-link for IPv6 with. A record of the problems makes sense because now there are IPv6 implementations being developed from scratch in consumer devices which have very limited memory to leverage a free BSD or Linux IPv6 stacks. Such stacks are being developed from scratch. I have already interoperated IPv6 with one such device in the past year. We need a strict set of rules for IPv6 data forwarding and on-and-off-link. Hemant -----Original Message----- From: Ralph Droms (rdroms) Sent: Wednesday, December 12, 2007 9:19 PM To: Hemant Singh (shemant) Cc: Ralph Droms (rdroms); Hesham Soliman; Erik Nordmark; IPV6 List Mailing; Suresh Krishnan Subject: Re: Off-link and on-link Hemant - I've reviewed this version of your draft as well as (as you know) earlier versions. I don't have a clear preference about whether or not to take this draft on as a WG work item. It would be helpful to have a record of these implementation problems. However, my understanding is that each of problems 2.1, 2.2 and 2.3 (and I think 2.1 and 2.3 are related) has been found once and has been or will be patched. Will the WG want to begin a collection of similar bugs found in other stacks? Is there text in an RFC that can be used as the basis for demonstrating 2.4 is an explicit bug? - Ralph On Dec 12, 2007, at Dec 12, 2007,3:17 PM, Hemant Singh (shemant) wrote: > Hesham, > > Since you said it's good to highlight such DHCPv6 facts to > implementations, see our 2nd draft. > > http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-pr > ob > lems-00.txt > > where we have highlighted such implementation issues. See section > 2.3 of > this draft. Further, bullet 2 in section 2 of our on-and-off-link > draft highlight this DHCPv6 client mistake in a rule. > > Could we get a rough consensus if the above draft should be a work > item of 6man? Folks have to read the draft first. So far only Jinmei > and Vlad have reviewed the implementation draft. > > We can debate the on-and-off-link draft separately. > > Thanks. > > Hemant > > -----Original Message----- > From: Hesham Soliman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 05, 2007 5:32 PM > To: Ralph Droms (rdroms); Hemant Singh (shemant) > Cc: 'Erik Nordmark'; 'IPV6 List Mailing'; 'Suresh Krishnan' > Subject: RE: Off-link and on-link > > >> To give a little more detail to that implementation bug, it > seems > the > host implementation inferred an on-link prefix from an address > > assigned through DHCPv6. We believe the implementation > carried > over >> IPv4 behavior, in which it's common to pass on-link prefix > > information > to a host as a side effect of address assignment to > interfaces. In > IPv6, of course, RAs provide an explicit path for > announcing prefix > information, so no prefix state should be > inferred from address > assignment. > > => Exactly. This makes sense, and it's good to highlight that to > implementations, I just don't think this behaviour is a result of > correct reading of the spec. > >> >> In my opinion, the "no PIO" case is adequately described in > RFC > 4861, > as the host has no information about on-link status of a > prefix if > there is no PIO for that prefix. Therefore, the host > should > send any > outbound traffic to an address from a prefix for > which the host has > not received a PIO to the default router. > > => Agreed. That's the default behaviour. > > Hesham > >> >> - Ralph >> >> >> On Dec 5, 2007, at Dec 5, 2007,4:05 PM, Hemant Singh (shemant) wrote: >> >>> Erik, >>> >>> As I said in the presentation, let's forget the > aggregation > router. >>> The >>> host implementation bug we found is reproduced in an Ethernet LAN >>> network too. An RA from the router was sent where RA was > NOT > signaling > > on-link and the host still behaved as on-link for > traffic >> forwarding. >>> The RA we used was an RA that did not send any PIO (Prefix > > Information > > Option). BTW, such a case (RA with no PIO) is not > even >> covered by the > > definition of on- and off-link in section 2.1 of > RFC 4861, > especially > > since section 2.1 goes to so much copious > details to > describe on-link. >>> >>> I was looking for a Turing machine to signal off-link. >>> >>> Hemant >>> >>> -----Original Message----- >>> From: Erik Nordmark [mailto:[EMAIL PROTECTED] > > Sent: > Wednesday, December 05, 2007 12:29 PM > > To: Hemant Singh > (shemant) > >> Cc: Suresh Krishnan; [email protected] > > Subject: Re: Off-link and > on-link > > > > Hemant Singh (shemant) wrote: >>>> Suresh, >>>> >>>> At least our drafts do not ask for a new off-link flag. >> Without a new >>>> off-link flag your scenario will have to go with (a). But do note, >>>> aggregation routers do not send Redirects. So the scenario below > >>> cannot be even supported on aggregation routers. >>> >>> Which RFC defines an "aggregation router"? >>> >>> Erik >>> >>>> >>>> Hemant >>>> >>>> -----Original Message----- >>>> From: Suresh Krishnan [mailto:[EMAIL PROTECTED] >>>> Sent: Wednesday, December 05, 2007 11:01 AM > >> To: > [email protected] > >> Subject: Off-link and on-link > >> > >> Hi > Hesham/Dave/Erik, > >> I am not taking a stand on whether an > explicit off-link flag is > >> necessary/useful or not, but I have > encountered a >> scenario where the > >> existing algorithm specified in RFC4861 does > not work very well. >>>> Let's >>> >>>> say a router wants to signal to the clients that > > 2001:dead:beef::/48 > >> is on-link except for > 2001:dead:beef:abcd::/64 > that is > off-link. How > >> would it go about describing this? I > see two ways > >> > >> a) Advertise the /48 with L=0 and send > redirects for all > addresses > >> not > > > >> on the /64 > >> > b) Advertise > the /48 with L=1 and the /64 with Q(the new off-link > >> flag)=0 > > >> >>>> I see b) as being more efficient than a) > >> > >> P.S: I do not > think that this scenario is very likely, > just possible. >>>> >>>> Cheers >>>> Suresh >>>> >>>> >> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list > >> [email protected] > >> > Administrative Requests: >> https://www1.ietf.org/mailman/listinfo/ipv6 >>>> >> -------------------------------------------------------------------- >>>> >>>> >> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list > >> [email protected] > >> > Administrative Requests: >> https://www1.ietf.org/mailman/listinfo/ipv6 >>>> >> -------------------------------------------------------------------- >>> >>> >> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list > > [email protected] > > > Administrative Requests: >> https://www1.ietf.org/mailman/listinfo/ipv6 >>> >> -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
