Folks,
Since Erik mentioned a new rephrased sentence in this email below where
his sentence included a Redirect, I'd like to focus the community on
Redirect in RFC 4261 vs. Redirect in our draft related to
on-and-off-link determination. This is another reason for our draft to
exist and argue for consideration to 6man WG as a work item.
Notice in our draft, we are defining rules that a host MUST NOT issue an
NS to resolve.... in cases discussing off-link. So now if one discusses
Redirect, Redirect becomes interesting when the Redirect does not
include the Target Link-Layer Address option (TLLAO). Section 8.3 of RFC
4861 does not even discuss this case. Section 8.3 of RFC 4861 discusses
only the case of Redirect when the Redirect DOES include the TLLAO. We
feel the case of Redirect with no TLLAO is worth discussing - we will
show you why with a new text from our -01 draft - read the text and see
why such text needs to be a part of any Redirect and on-and-off-link
discussion. We plan to release the -01 sometime early next week. Notice
we had released an early copy of the -01 draft to this mailer on
November 1st, 2007.
Jinmei commented on Redirect in our -00 draft saying that the "MUST NOT
issue NS to resolve" rule against Redirect was not correct when the
Redirect does not include TLLAO. He said without TLLAO the host MUST
issue an NS to resolve destination. Even that was not quite the correct
answer - in some cases without TLLAO, a NS to resolve is not needed
while is some cases it is. Anyhow, our -00 draft was only discussing
Redirect with TLLAO but we hadn't explicitly said so. So we added a very
comprehensive Redirect section in our draft that reads as follows - see
text within square brackets.
[4. Redirect Clarifications
Redirects are not sent by aggregation routers except when two hosts
behind the same bridge CPE, with no router between the host and the
aggregation router, communicate with each other. The aggregation router
sends a Redirect to a source host which communicates with a destination
host behind the same bridge CPE if the router can make a determination
that the two hosts lie behind the same bridge CPE.
The ICMP field of the Redirect message has a Target Address field. In
the presence of a Target link-layer address option included in the
Redirect, the host MUST NOT issue an NS to resolve the destination. In
the absence of any Target link-layer address option included in the
Redirect, host behavior depends upon the type of the target.
If the target is a router, that router's link-local address is the
Target Address. The source IP address of a Redirect is always a
link-local address. If the target link-local address matches the source
IP address, then the L2 header of the Redirect message tells the host
the link-layer address of the target. The purpose of such a Redirect
message is to tell a host that a destination which the host assumes to
be on-link is in fact off-link. If the target address does not match the
source IP address, then the Redirect target is another router than the
router that issued the Redirect. In this case, the host MUST issue an NS
to resolve the link-local address of the target if the host does not
already have this address in its neighbor cache. This Redirect indicates
that the destination is off-link, but the host MUST use a different
router than the one issuing the Redirect in order to reach the
destination. In summary, if the target of a Redirect is a router, then
the destination is off-link and the host MUST NOT issue an NS to resolve
a destination other than a link-local address.
If the target is a host, the target address is the same value as the
ICMP Destination address. On receiving this Redirect, the source host
MUST issue an NS to resolve a non-link-local destination if the host
does not already have this information in its neighbor cache. Once the
destination host responds to the NS, the source host will thereafter
send packets directly to the destination host. ]
Such new text belongs in RFC 4861 but we ain't writing a 4861bis just
yet. So where does such text go? It has been included in our
on-and-off-link draft!
Hemant
________________________________
From: Josh Littlefield (joshl)
Sent: Wednesday, December 05, 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
--------------------------------------------------------------------
