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-prob 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; ipv6@ietf.org > > 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: ipv6@ietf.org > >> 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 > >> 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 > >> > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
