* if the host has received an RA containing a PIO with L=0, it
adds that prefix to its prefix list; when sending a datagram to
I think you meant L=1 as the text in 6.3.4. Processing Received Router
Advertisements only gives explicit instructions to the host for PIOs
where L=1. It has NO instructions as to what the host does with a PIO
with L=0. So, one would assume that they are ignored (and thus fairly
useless to be sent by a router at least in terms of
on-link/not-on-link).
In section 5.2, the text is very clear as to what a host does:
Next-hop determination for a given unicast destination operates as
follows. The sender performs a longest prefix match against the
Prefix List to determine whether the packet's destination is on- or
off-link. If the destination is on-link, the next-hop address is the
same as the packet's destination address. Otherwise, the sender
selects a router from the Default Router List (following the rules
described in Section 6.3.6).
Here this "longest prefix match" means that the PIO w/L=0 would not be
on the Prefix List (per the 6.3.4 text which lacks any instructions
about doing anything with these PIOs) and hence if there wasn't another
match, the prefix would be assumed as being "off-link".
And, RFC 4861 also clearly defines that the "Prefix List" only contains
on-link prefixes:
Prefix List - A list of the prefixes that define a set of
addresses that are on-link. Prefix List entries
are created from information received in Router
Advertisements. ...
This is actually very interesting as it clearly implies that PIO w/L=0
are ignored (in terms of the Prefix List). And, if the PIO has L=0 and
A=0 (considering RFC 4861 & 4862), the router is just wasting network
bandwidth and host processing time by sending that PIO.
- Bernie
-----Original Message-----
From: Ralph Droms (rdroms)
Sent: Wednesday, December 12, 2007 9:30 PM
To: Hemant Singh (shemant)
Cc: Erik Nordmark; ipv6@ietf.org; Suresh Krishnan; Ralph Droms (rdroms)
Subject: Re: Off-link and on-link
Hemant - From RFC 4861, I interpret the definition of "prefix list"
and the text in section 5.2 to mean that:
* if the host has received an RA containing a PIO with L=0, it
adds that prefix to its prefix list; when sending a datagram to
an address from that prefix, the host finds the prefix in
its prefix list and delivers the datagram directly to the
destination
* otherwise, the host will not ever add the prefix to its
prefix list; when sending a datagram to an address from that
prefix, the host does not find the prefix in its prefix list
and delivers the datagram to its default router
Therefore, I interpret the decision to be "on-link, deliver direct;
otherwise, send to default router". The specs are not written to
include a rule for an explicit "off-link, send to default router"
decision.
- Ralph
On Dec 12, 2007, at Dec 12, 2007,1:12 PM, Hemant Singh (shemant) wrote:
> Hesham,
>
> This is what you have said below that I have put inside double quotes:
>
> "Instead, clearing the L flag means that the host should not assume
> that
> an address derived from this prefix is on-link."
>
> My response to this statement is below. I have snipped text from RFC
> 4861 below (within square brackets)
>
> [Note, however, that a Prefix Information option
>
>
>
> Narten, et al. Standards Track [Page
> 54]
>
> RFC 4861 Neighbor Discovery in IPv6 September
> 2007
>
>
> 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 text from RFC is saying the receiver of such an RA cannot assume
> addresses covered by the prefix are off-link while your statement
> above
> says cannot assume on-link.
>
> Now, if I go by this text in the RFC, I as a host WILL NOT send
> traffic
> to the default router because I cannot assume off-link.
>
> Hemant
>
>
> -----Original Message-----
> From: Hesham Soliman [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 05, 2007 8:21 PM
> To: Hemant Singh (shemant); 'Erik Nordmark'
> Cc: ipv6@ietf.org; 'Suresh Krishnan'
> Subject: RE: Off-link and on-link
>
>
>> I know how to configure off-link on a router. I was asking the >
> community. At least the people we pinged in the past in the
> community >
> didn't know how or didn't reply including Hesham.
>>
>> How off-link is configured is described in section 2.1, and > 2.2.1
> of our > draft. Your explanation below for the section 2.1 is fine.
> As
> for the > off-link suggestion you make below for AdvOnLinkFlag=False,
>> folks might > not agree with you on just setting L-bit in RA to be
> clear > and off-link > is signaled. Here is one reason why. Snipped
> below is text > from section > 2.3 on our draft.
>>
>> [An on-link bit of clear indicates nothing regarding on-link >
> determination. In section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11 >
> (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor >
> Discovery for IP Version 6 (IPv6)," March 2007.) [NDbis]":
>>
>> "...a Prefix Information Option with 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.... Prefixes > with the on-link flag set to zero would
> normally have the autonomous > flag set and be used by
> [ADDRCONF]."] >
>> Did we miss anything in the interpretation of the text above from RFC
>> 4861. This text is not clear.
>
> => I tried to explain it in the meeting and on the list but clearly my
> explanation is not getting through. Let me have another shot. There is
> no flag in 4861 that says that an entire prefix is off-link. Instead,
> clearing the L flag means that the host should not assume that an
> address derived from this prefix is on-link. So what's the consequence
> of this? The consequence is that the host should send all packets to
> the
> default router.
> The same consequence as if the flag says the prefix is off-link. So if
> all you want to do is make sure that a host avoids address resolution
> and sends packets straight to the default router then make sure the L
> flag is clear.
> In the absence of the PIO, the default behaviour is to send packets to
> the default router.
>
> If none of this is clear please read Bernie's earlier response. I
> don't
> know how to make it any clearer.
>
> Hesham
>
>>
>> Thanks.
>>
>> Hemant
>>
>> -----Original Message-----
>> From: Erik Nordmark [mailto:[EMAIL PROTECTED] > Sent:
> Wednesday, December 05, 2007 1:46 PM > To: Hemant Singh (shemant) >
> Cc: Suresh Krishnan; ipv6@ietf.org > Subject: Re: Off-link and on-
> link
>>> Hemant Singh (shemant) wrote:
>>> Good question, Erik. To the best of my knowledge such an > RFC
> does not > > exist - at least describing total details of an >
> aggregation router - > > like unicast, mcast, and anycast data
> forwarding rules etc. The > > closest I have found in IETF is what
> IETF calls as > multi-link router.
>>
>> FWIW I don't find "multi-link router" in any RFC. My point was that
>> using this undefined term doesn't help clarify things. It would have
>> been better to talk about a router which has been configured to never
>> send any redirects.
>>
>>> Now the question I asked in my presentation. I have to > configure
> this > > aggregation router to signal off-link. How do I do that?
>>
>> By not to configuring it to enable the L flag for any prefix that the
>> router advertized. Abstractly (per RFC 4861) this is done by setting
>> AdvOnLinkFlag=False.
>>
>> If you have a question on how to do that for a particular product you
>> should ask the vendor of that product. If you are using OpenSolaris I
>> can help.
>>
>>> 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.
>>
>> That is clearly a bug in the host implementation.
>> Have you contacted the host vendor?
>>
>>> 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.
>>
>> It does cover it. If no information is know about an address >
> (which is > this case - no prefix options with L=1 and no
> redirects) >
> then the host > will send to a default router.
>>
>> Erik
>>
>> --------------------------------------------------------------------
>> 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
--------------------------------------------------------------------
