Suresh, Your case below is described in section 2.2.1 of our draft.
http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d etermination-00.txt No, we have loose text in ND RFC and not a bug in a host stack. We are after changing loose text as is evident from our examples. That is why, please do read the updates draft and compare the clear text in this draft vs. the text being replaced in ND RFC. Hemant -----Original Message----- From: Suresh Krishnan [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 05, 2007 11:18 AM To: Josh Littlefield (joshl); Hemant Singh (shemant) Cc: [EMAIL PROTECTED]; IETF IPv6 Mailing List Subject: RE: Here is the reference to 6.3.4 text that is ambigious text Hi, My understanding of the document is the same as that of Josh, except for this thing that was left out if L=1 and Lifetime=0 remove the prefix from the prefix list (switch from talking directly to talking through the router) Cheers Suresh -----Original Message----- From: Josh Littlefield [mailto:[EMAIL PROTECTED] Sent: Wed 5/12/2007 2:08 PM To: Hemant Singh (shemant) Cc: Suresh Krishnan; [EMAIL PROTECTED]; IETF IPv6 Mailing List Subject: Re: Here is the reference to 6.3.4 text that is ambigious text It is not crystal clear, but my impression is that this paragraph is saying: Default sending behavior is send to default router. Reception of L=1 signals on-link (can use ND to send directly) Reception of L=0 is no-op. Because L=0 is no-op, if one considered the prefix on-link due to prior L=1, then prefix is still on-link. If one did not consider the prefix on-linke due to prior L=1, then retain default behavior. It might be clearer to have said that default assumption is that all prefixes are off-link, and this means send to default router. Only reception of L=1 can change that for any specific prefix. A prefix with L=0 does not change off-link, or on-link status of prefix, and is the same as omitting the prefix entirely from the RA, from the point of view of on-link determination. Hemant Singh (shemant) wrote: > > The summary from this section snipped from 6.3.4 of RFC 4861 is saying > no on-ink information does not mean off-link. So why is the text is > red where is says, send traffic to default router being said because > the text in red signals off-link behavior. Why is this paragraph not > ambiguous? > > > Prefix Information options that have the "on-link" (L) flag set > indicate a prefix identifying a range of addresses that should be > considered on-link. 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. The only way to cancel > a previous on-link indication is to advertise that prefix with the > L-bit set and the Lifetime set to zero. The default behavior (see > Section 5.2) when sending a packet to an address for which no > information is known about the on-link status of the address is to > forward the packet to a default router; the reception of a Prefix > Information option with the "on-link" (L) flag set to zero does not > change this behavior. The reasons for an address being treated as > on-link is specified in the definition of "on-link" in Section 2.1. > Prefixes with the on-link flag set to zero would normally have the > autonomous flag set and be used by [ADDRCONF]. > > Hemant > > ---------------------------------------------------------------------- > -- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- ===================================================================== Josh Littlefield Cisco Systems, Inc. [EMAIL PROTECTED] 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
