Subject: RE: Here is the reference to 6.3.4 text that is ambigious text

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jan 2008 10:29:31 -0500

Thomas,

Sorry, it took us a while to get back to editing the -00 draft to -01
stage. The -01 version is now available at

http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d
etermination-01.txt

I have snipped the new section from -01 draft below.

4.  Redirect Clarifications

   Redirects to indicate destinations are on-link 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 (TLLAO)
   included in the Redirect, the host should not issue an NS to resolve
   the destination unless the entry has been garbage collected.  In the
   absence of any TLLAO 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.  A host may inspect
   the L2 header to avoid sending an NS to resolve the destination.  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 will 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 needs to 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 will issue an NS to resolve a non-link-local destination if the
   host does not already have this information in its neighbor cache.

Singh & Beebee            Expires July 21, 2008                 [Page 8]

Internet-Draft          ND On-link Determination            January 2008

   Once the destination host responds to the NS, the source host will
   thereafter send packets directly to the destination host.

Hemant 

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Friday, December 14, 2007 12:16 PM
To: Thomas Narten
Cc: [email-masked]; Erik Nordmark; IETF IPv6 Mailing List; Suresh
Krishnan; Josh Littlefield (joshl)
Subject: RE: Here is the reference to 6.3.4 text that is ambigious text

Thomas,

Thanks for this email. First, here is a running list of why we think our
on-and-off-link draft should exist.

1. We presented to the IPv6 community that RFC 4861 does not include in
section 8.3, a case for when Redirect does not include Target Link-layer
address option (TLLAO). Such a Redirect is common to be encountered in
an IPv6 network. Therefore either a 4861bis discusses it or our draft
does.

2. Since Redirect can suggest a better first-hop that could be on- or
off-link, our intent is to dissect Redirect more carefully because we
have found
   show stopper issues with on- vs. off-link determination in an
aggregation routed network. We think we do provide ample evidence in
line below for our case of confusion related to on- vs. off-link in the
ND RFC.

3. We see hosts are confused between the boundary of what should DHCPv6
handle and dole out vs. what should ND handle and dole out. Can the
community show what text in RFC 3315 or RFC 4861 and 4862 defines such
boundaries or the justification for such boundaries - this is a
deployment that includes both a DHCPv6 server and an IPv6 default
router. Our draft is defining such boundaries, although that is not the
primary intent of our draft. An example of hosts being confused about
this boundary is shown in bug 2.3 of our ND implementation draft -
draft-wbeebee-nd-implementation-problems-00. 

Now, please see in line below for our responses included between <hs>
and </hs> or <wb> and </wb>.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Friday, December 14, 2007 8:54 AM
To: Hemant Singh (shemant)
Cc: Josh Littlefield (joshl); Erik Nordmark; IETF IPv6 Mailing List;
[email-masked]; Suresh Krishnan
Subject: Re: Here is the reference to 6.3.4 text that is ambigious text

"Hemant Singh (shemant)" <[email-masked]> writes:

> [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.=20

OK. 

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

No. A node MUST always be allowed to send out an NS if it has been told
a destination is on-link (whether by PIO or by a redirect). Sure, in
most cases after a redirect it shouldn't need to do so, but it must have
the option of doing so. What if garbage collections times-out the
associated link-layer address?

<hs>
Garbage collection will need to issue a unicast NS that is a Neighbor
Unreachability detection. Our text says MUST NOT issue an NS to resolve
the destination - this is a multicast NS. But if NUD fails, you are
totally correct that the node will have to send out an NS. This texts
need rewording in our draft.
</hs>

> In the absence of any Target link-layer address option included in the

> Redirect, host behavior depends upon the type of the target.=20

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

I do not believe ND has ever _required_ looking at the L2 header to
extract information. I.e, that is why we have Link-Layer Adress options
as part of ND, so that the ND processing can be media-idependent. 

<hs>
Makes sense to have ND processing be media-independent. However, we
should still have such text but preceded by comments like, "it's left to
the vendor if they would like to do any optimized processing of Redirect
along with L2 header when the router has all information for L2 media
type." Makes sense to have a router vendor have such flexibility.
</hs>

> 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 last sentence is not needed, as one always issues an NS to do
address resolution if one doesn't have the necessary information.. That
is pretty basic stuff.

<hs>
Sounds fine. We can remove such a statement.
</hs>

> 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.=20

I don't know why all this MUST NOT stuff is needed. The host doesn't
need to explicitly know that a destination is on or off-link. This all
just happens correctly as part of ND processing.

<wb>
The consequences of "correct ND processing" need to be ironed out
because:
1) hosts don't always implement ND in the same way,
2) routers need to know what behavior to expect from hosts, and
3) RFC 3756, section 4.2.5 (Bogus On-Link Prefix) states "If a sending
host thinks the prefix is on-link, it will never send a packet for that
prefix to the router."
<wb>
<hs>
4) If a host incorrectly assumed a packet destination to be on-link when
the host was supposed to treat the destination as off-link, the host can
issue an NS to resolve the destination. The router may not respond to
this NS and the host eventually times out sending the packet out. In an
Ethernet LAN, the router will respond, but in an aggregated routed
network, the aggregation router does not respond to any address
resolution for non-link-local address from any client on the router
upstream. The aggregated routed network for IETF folks is a point to
point link topology. An example of such a router is a cable router
terminating over 60,000 IPv6 cable modems with IPv6 hosts behind the
modems. We have explained the aggregation router in numerous emails to
IETF mailer.
</hs>

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

Again, I do not understand how the above text clarifies or otherwise
changes anything in ND.

<hs>
We have this paragraph to discuss the Redirect case when no TLLAO is
included in Redirect. 
We have to complete the no TLLAO text for the case when the Target was a
host vs. a router.
</hs>

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

Bottom line. I don't get why we continue to have this discussion. I
remain unconvinced that there is a real problem here that needs fixing.

The one thing that _might_ be worth putting in a document somewhere is a
statement to the effect:

   A node only considers destinations to be on-link, if it has
   received an explicit indication that the target address is on-link
   (via a redirect) or if the address is covered by a prefix on-link
   indication (per a PIO option). Packets for all other destinations
   are forwarded through a neighboring router.

<hs>
Hmm, the text above still does not cover the two cases for on-link as
specified in section 2.1 of the on-link definition.

- a Neighbor Advertisement message is received for
                      the (target) address, or

- any Neighbor Discovery message is received from
  the address.

For a third case, the on-link definition in section 2.1 of RFC 4861 does
not mention the fact that manual configuration in out of scope of the ND
RFC. Manual configuration is a can of worms that can mess up prefixes,
prefix length, on- and off-link determination, and can cause security
problems.
Do you know what do host vendors tell us when we complained to them that
their host was incorrectly adding a default route from a conjured up
prefix and prefix length based on what the host got for a DHCPv6
address? The incorrect behavior causes a Show Stopper data forwarding
problem in cable router for an IPv6 host. They tell us, gee, how do we
know you didn't configure the default router manually? Do you want to
deal with such comments. I would rather put some text in the RFC that
says manual configuration is out of scope. That is why we have bullet 2
in our on-and-off-link drafts that says:

[The on-link definition in section 2.1 of RFC 4861 (Narten, T.,
Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP
Version 6 (IPv6)," September 2007.) [ND] describes the only means for
on-link determination. DHCPv6 or any other configuration on the host
MUST NOT be used for on-link determination. Manual configuration of a
host introduces its own set of security considerations and is beyond the
scope of this document. Note that the on-link definition as specified by
RFC 4861 (Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP Version 6 (IPv6)," September 2007.) [ND] does
not include manual configuration.]

Further, Josh Littlefield from Cisco said something similar to your
suggested text last week. We have to have ND specify that the default
mode is off-link. See how even an author of the ND RFC can say one thing
in an email when the ND RFC says another thing. Hesham emailed the text
in double quotes below.

"Instead, clearing the L flag means that the host should not assume that
an address derived from this prefix is on-link."

But the RFC text says the following about the same issue shown below in
square brackets.  

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

We have to be careful when we say "not assume off-link" vs. "not assume
on-link" or both. I think such text in the ND RFC is confusing when one
could remove all this text about "not assuming on-link" and "not
assuming off-link" in the RFC and replace it by what Josh suggested
first- the default mode is off-link. Then reword some text around that.
I will re-send Josh's email to this mailer soon.
</hs> 

But that said, ND has been around for more than 10 years now, has been
implemented many times, and the vast majority of implementors have not
been confused on this point from what I can tell.

Even the implementation that triggered this discussion seems to concede
it is not following the spec.

Thus, I think the issue (to the degree that there might be one) is being
blown way out of proportion.

<hs>
I suspect for the past ten years ND has been tested in Ethernet LAN
networks (wired or wireless), or any cellular networks, and that too in
on-link mode. We started testing ND eight months back with off-link
since that is the only model for an aggregation router hosts. In our
off-link test, a host is sent an RA with no PIO, but the host did not
send all non-link-local traffic to the default router. Instead the host
assumed on-link and when the host was asked to forward a packet out, the
host issued an NS to resolve the destination. Since the aggregation
router does not reply to any address resolution for non-link-local
addresses from hosts on the router's upstream, the host keeps sending
NS's while holding the packet in a queue. Eventually the host timed out
and failed to send the packet out. The same problem exists when another
destination pings this host and when host has to send a ping reply, the
host tries again to issue NS and fails to send the reply. Incorrect on-
vs. off-link determination caused this Showstopper problem in an
aggregation router network. See bug 2.1 in
draft-wbeebee-nd-implementation-problems-00.txt that reports this
problem. Do NOTE this bug occurs in an Ethernet LAN too, but the effect
of the bug is less severe in Ethernet LAN because the router can respond
to the NS.

We want on-and-off-link iron clad in the RFC because if a slight mistake
is made, one can see a show stopper problem for data forwarding. First,
congratulations are due to the ND authors for designing ND well to work
in yet another network like the cable aggregated routed network. But
welcome to some minor demands from folks form such a network.
</hs>

I hope Alain Durand from Comcast is listening on this thread.

Hemant

Don't we have real work to do here?

Thomas

- Wes and Hemant

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------