Subject: Question on IPv6 jumbograms

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 3 Dec 2007 16:17:00 -0500

Perhaps this was covered in the RH0 deprecation discussions and I missed
it. How will jumbograms be coded in the IPv6 header if RH0 is rejected,
at some point? Since both a length of 0 bytes and RH0 are expected in
the IPv6 header, to indicate jumbogram (RFC 2675).

Bert

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

---

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 4 Dec 2007 02:57:23 -0500

Hi Bert,
  The jumbogram length is specified in a hop by hop option along with the length of 0 in the IPv6 datagram. RH0 is not required in any way for jumbograms to work.

Thanks
Suresh

(ccing [email-masked] that is the mailing list for ipv6 maintenance)

-----Original Message-----
From: Manfredi, Albert E [mailto:[email-masked]]
Sent: Mon 3/12/2007 4:17 PM
To: IETF IPv6 Mailing List
Subject: Question on IPv6 jumbograms

Bert

---

From: Bob Hinden <[email-masked]>
Date: Tue, 4 Dec 2007 11:27:08 -0800

> (ccing [email-masked] that is the mailing list for ipv6 maintenance)

There isn't (or shouldn't be) a [email-masked] mailing list.  The 6man  
working uses [email-masked].  See the charter page at:

   http://ietf.org/html.charters/6man-charter.html

Bob

---

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 4 Dec 2007 14:29:18 -0500

mea culpa. Too late in the night + lack of coffee in the coffee breaks.

Cheers
Suresh

-----Original Message-----
From: Bob Hinden [mailto:[email-masked]]
Sent: Tue 4/12/2007 2:27 PM
To: IETF IPv6 Mailing List
Subject: 6man mailing list

Bob

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 5 Dec 2007 08:33:54 +0530

Hi Bert,

Thanks for pointing this out. I could not find any reference to the
RH0 header either.

Thanks again,
Vishwas

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 04 Dec 2007 02:49:39 +0000

Hi.

If I understand what you are asking correctly, I think you have misread 
RFC 2675/2460.  The jumbogram option lives in the hop-by-by-hop 
extension header (Header Type (Next header value) 0, option type code C2 
hex).  The routing header is a a different extension header (Header Type 
43).  Jumbograms are therefore not affected by the deprecation of RH0 
(Header Type 43, Routing Type 0).

Regards,
Elwyn

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 13:49:33 -0500

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

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 05 Dec 2007 14:08:25 -0500

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

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 5 Dec 2007 14:18:04 -0500

Hi,
  My understanding of the document is the same as that of Josh, except for this thing that was left out

if L=1 and Lifetime=0 remove the prefix from the prefix list (switch from talking directly to talking through the router)

Cheers
Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 14:19:59 -0500

Thanks Josh. That is the point of our drafts is to clarify that default
behavior is off-link because that mode maps to sending data to the
default router. The ND RFC is also loose by saying send data to the
router when the RFC should say send all non-link-local traffic to the
default router. 
 
In hind sight, it made sense for us to have blocked RFC 4861 in AUTH48
state when we were commenting on 2461bis-11 and 24628.
 
Hemant

________________________________

From: Josh Littlefield (joshl) 
Sent: Wednesday, December 05, 2007 11:08 AM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; [email-masked]; 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:

	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
	[email-masked]
	Administrative Requests:
https://www1.ietf.org/mailman/listinfo/ipv6

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 14:27:42 -0500

Suresh,

Your case below is described in section 2.2.1 of our draft. 

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

No, we have loose text in ND RFC and not a bug in a host stack. We are
after changing loose text as is evident from our examples. That is why,
please do read the updates draft and compare the clear text in this
draft vs. the text being replaced in ND RFC.

Hemant 

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 11:18 AM
To: Josh Littlefield (joshl); Hemant Singh (shemant)
Cc: [email-masked]; IETF IPv6 Mailing List
Subject: RE: Here is the reference to 6.3.4 text that is ambigious text

Hi,
  My understanding of the document is the same as that of Josh, except
for this thing that was left out

if L=1 and Lifetime=0 remove the prefix from the prefix list (switch
from talking directly to talking through the router)

Cheers
Suresh

-----Original Message-----
From: Josh Littlefield [mailto:[email-masked]]
Sent: Wed 5/12/2007 2:08 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; [email-masked]; IETF IPv6 Mailing List
Subject: Re: Here is the reference to 6.3.4 text that is ambigious text

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.

option

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 05 Dec 2007 12:19:55 -0800

> text in red signals off-link behavior. Why is this paragraph not

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 5 Dec 2007 15:41:23 -0500

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-masked]] 
Sent: Wednesday, December 05, 2007 12:20 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; [email-masked]; IETF IPv6 Mailing List
Subject: Re: Here is the reference to 6.3.4 text that is ambigious text

    Erik

option

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 5 Dec 2007 15:44:01 -0500

Hemant:
 
The on-link/off-link indication is for *ALL* of the addresses in the
prefix. That is what the "default behavior" is in reference to.
 
If the node has other information (such as from an ICMPv6 Redirect), it
would then NOT use the default behavior.
 
There is a MAJOR difference between saying that all destinations on a
prefix are OFF-LINK vs NOT ON-LINK. Not on-link means you don't know and
ABSENT ANY OTHER INFORMATION (ie, the default behavior) you send the
traffic to the default router. 
 
- Bernie

From: Hemant Singh (shemant) 
Sent: Wednesday, December 05, 2007 1:50 PM
To: Suresh Krishnan; [email-masked]; IETF IPv6 Mailing List
Subject: Here is the reference to 6.3.4 text that is ambigious text

Hemant

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 05 Dec 2007 13:27:50 -0800

> addresses covered by the prefix are off-link."]

So far we are talking about the semantics of a single prefix information 
option.

> forward the packet to a default router;]

And this talks about a particular destination address, looking at all of 
the prefix list.

Thus you could rephrase the above sentence as
  When sending a packet to a destination and there is no matching prefix 
list entry, and no matching redirect entry, the packet is sent to a 
default router.

> "sending data to default router" as signaling off-link behavior.

They are not in conflict, since the first is about a particular prefix 
information option, and the second is about the system as a whole.

> don't want to bring RFC 4775 into the discussion just yet.

I was merely trying to explain the motivation for L=0 being a no-op.

    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 12 Dec 2007 13:23:02 -0500

Erik,

What you explained below is not very obvious from reading the paragraph.
Since none of the authors of RFC 4861 commented on our drafts since June
2007 and counting, I decided to ping the Chairs and AD with the same
paragraph. In that private email exchange, one person also did not
understand this paragraph as you have explained. Further the new
rephrased sentence that you propose is already along the lines of what
we have said in tighter text in our on-and-off-link draft - for example
see the last paragraph of section 2.1 of our on-and-off-link draft.

In 4861, in a lot of places there is text that says, "send all traffic
to default router" when the text should say "send all non-link-local
traffic to default router". If folks read our on-and-off-link draft,
there are a lot of fixes like this over 4861 that we had done. 

Further, DHCPv6 in RFC 3315, and ND RFCs in 4861 and 4862 are
collectively very lengthy documents. There is no document that defines
how are DHCPv6 and ND in a IPv6 router and DHCPv6 server environment are
supposed to behave or what is the boundary between DHCPv6 and the IPv6
router sending RA. We have summarized how DHCPv6 and ND interface with
each other in our drafts. Such IPv6 info is useful to developers coming
from an IPv4 world. 

On a separate note, folks also need to reply to the mailer if our ND
implementation drafts can be accepted as a work item in 6man.

Thanks.

Hemant

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 4:28 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; [email-masked]; IETF IPv6 Mailing List
Subject: Re: Here is the reference to 6.3.4 text that is ambigious text

Hemant Singh (shemant) wrote:
> [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."]

> address for which no information is known about the on-link status of 
> the address is to forward the packet to a default router;]

    Erik

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 13 Dec 2007 14:36:59 -0500

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

Sent: Wednesday, December 05, 2007 2:08 PM

	Hemant

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Dec 2007 08:53:51 -0500

> that the two hosts lie behind the same bridge CPE.=20

OK. 

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

> In the absence of any Target link-layer address option included in
> the Redirect, host behavior depends upon the type of the target.=20

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

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

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

> send packets directly to the destination host. ]

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

> yet. So where does such text go? It has been included in our

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.

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.

Don't we have real work to do here?

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Dec 2007 12:15:48 -0500

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

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

> 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

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

> 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

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

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

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:

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

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

Thomas

- Wes and Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Dec 2007 12:31:01 -0500

Since Thomas suggested some similar text, could folks please reply to
this email from Josh.
 
Thanks.
 
Hemant

	Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 15 Dec 2007 11:31:35 -0500

Thomas,

Sorry, there was a typo in a statement I made in which "router" should
be "host". The erroneous statement is snipped below.

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

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,

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

OK. 

<hs>

<hs>

<hs>

<wb>

<hs>

<hs>

<hs>

Hemant

Thomas

- Wes and Hemant