Ralph, Not quite. The bug was also seen when the host was asked to do SLAAC. Since neither, I, you, nor Erik have access to this host's source code, we can never tell for certain what caused the host to issue NS for address resolution when the router DID NOT signal on-link to the host. I do agree we found multiple bugs in the host's IPv6 implementation and that is what has caused us to some rules in section 2 of our on-and-off-link draft.
Hemant -----Original Message----- From: Ralph Droms (rdroms) Sent: Wednesday, December 05, 2007 4:27 PM To: 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. 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. - 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 --------------------------------------------------------------------
