* 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 at 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:Hesham at elevatemobile.com]
Sent: Wednesday, December 05, 2007 8:21 PM
To: Hemant Singh (shemant); 'Erik Nordmark'
Cc: ipv6 at 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:erik.nordmark at sun.com] > Sent:
Wednesday, December 05, 2007 1:46 PM > To: Hemant Singh (shemant) >
Cc: Suresh Krishnan; ipv6 at 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 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
