Erik,

I appreciate the quick reply. OK, here is an explanation with
non-colored text. The text snipped below for 6.3.4 is as follows to
please note first the text in double quotes:

[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."]

After the above text in the para the para says the following a little
later:

[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;]

I am saying the para immediately above contradicts the text in quotes
because the quoted text says off link MUST NOT be interpreted but then
later the same section says "send data to default router". I interpret
"sending data to default router" as signaling off-link behavior.

As for the R bit, what if the router has implemented ONLY RFC 4861. I
don't want to bring RFC 4775 into the discussion just yet.

Thanks.

Hemant
 

-----Original Message-----
From: Erik Nordmark [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 05, 2007 12:20 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

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?

For security reasons I don't do anything fancy in my mail reader, hence
I don't see the colors your refer to.

Anyhow, what it is saying is that the L=0 is a no-op.
Elsewhere in the document it explains how the prefix list is maintained
and used, which basically means that all the prefixes with L=1 are
considered (within their lifetime).

The reason things are done this was is that there might be a reason to
send a prefix option with some bit other than L set, and that can't
interfere with the prefix list.
A concrete example would be a router sending a prefix information option
with only R set (see RFC 3775) and the fact that L=0 in such an option
shouldn't delete anything from the prefix list maintained by the host.

    Erik

>  
> 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
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to