Subject: RE: Sending traffic to default router when RA has no PIO

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 3 Jul 2007 09:28:39 -0400

Vlad,

If you say "this language should already be in the 2461bis" where is it
? Show us the exact paragraph and section.
Please note that both an implementer of a popular IPv6 host and an IPv6
certification agency missed this behavior.

Hemant & Wes 

-----Original Message-----
From: Vlad Yasevich [mailto:[email-masked]] 
Sent: Saturday, June 30, 2007 11:38 AM
To: Wes Beebee (wbeebee)
Cc: [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

Wes Beebee (wbeebee) wrote:
> Section 3.1 of RFC 2461 describes intended behavior when a host 
> receives an RA without an advertised prefix:
> 
>       "Multiple prefixes can be associated with the same link.  By
>       default, hosts learn all on-link prefixes from Router
>       Advertisements.  However, routers may be configured to omit some
>       or all prefixes from Router Advertisements.  In such cases hosts
>       assume that destinations are off-link and send traffic to
routers.
>       A router can then issue redirects as appropriate."
> 
> As described in our draft, this language should be strengthened to 
> state
> 
> that without advertised prefixes, without manual configuration, and 
> without redirects, hosts MUST send all non-link-local traffic to the 
> default router and MUST NOT issue an NS to resolve any destination 
> other than a link-local address.
> 

This language should already be in the 2461bis, just not in the section
you want it in.  May be this paragraph can instead be made more generic
and do not go into to much operation detail since this is a "Comparison
with IPv4" section.

-vlad

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 03 Jul 2007 14:48:59 +0100

> certification agency missed this behavior.

"5.2.  Conceptual Sending Algorithm" explains how a host should behave
in this case.

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 3 Jul 2007 10:01:44 -0400

Ole,

Let's talk specifics, not generics. Of course, we know about section 5.2
of 2461bis.

Snipped is following text from Introduction section of our I-D as to
what we think about section 5.2 of 2461bis:

   Sections 5.2 and 7.2.2 imply that the host performs
   address resolution before transmitting a packet if the destination of
   the packet is on the same link as the host.  Some current host
   implementations perform address resolution in all cases even when the
   destination is not clearly on-link.  However, RFC 2461 [ND] section
   6.3.4 implies that hosts must clearly determine that a destination is
   on-link before performing address resolution. 

Section 5.2 says "if the destination is on-link, then next-hop address
is the same as the packet's destination address. Otherwise, the sender
selects a router from the default router list." Implementers are not
putting two-and-two together. As described in section 2.1 of our I-D, if
a host has not been sent any PIO in RA, and the host performed DHCPv6,
the host has no way to determine what's on-link for the host. Section
5.2 just says "if the destination in on-link...". Well, discussion first
has to be made as to how can a host determine what's on-link for it.
These are the clarifications we have made in our I-D.

Proof is also in the pudding. We also say in Abstract of our I-D, if ND
RFC's are almost 10 years old, why are popular hosts still making
mistakes with on-link determination or totally not heeding L bits of RA
? ND has to be clarified as we have done so in our I-D.

Hemant & Wes

-----Original Message-----
From: Ole Troan (otroan) 
Sent: Tuesday, July 03, 2007 9:49 AM
To: Hemant Singh (shemant)
Cc: Vlad Yasevich; Wes Beebee (wbeebee); [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

> If you say "this language should already be in the 2461bis" where is 
> it ? Show us the exact paragraph and section.
> Please note that both an implementer of a popular IPv6 host and an 
> IPv6 certification agency missed this behavior.

/ot

> This language should already be in the 2461bis, just not in the 
> section you want it in.  May be this paragraph can instead be made 
> more generic and do not go into to much operation detail since this is

> a "Comparison with IPv4" section.
>
> -vlad
>
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 03 Jul 2007 15:27:10 +0100

> These are the clarifications we have made in our I-D.

isn't that clear from section 6.3.4 on prefix discovery?

   For each Prefix Information option with the on-link flag set, a host
   does the following:

      - If the prefix is the link-local prefix, silently ignore the
        Prefix Information option.

      - If the prefix is not already present in the Prefix List, and the
        Prefix Information option's Valid Lifetime field is non-zero,
        create a new entry for the prefix and initialize its
        invalidation timer to the Valid Lifetime value in the Prefix
        Information option.

      - If the prefix is already present in the host's Prefix List as
        the result of a previously-received advertisement, reset its
        invalidation timer to the Valid Lifetime value in the Prefix
        Information option.  If the new Lifetime value is zero, time-out
        the prefix immediately (see Section 6.3.5).

      - If the Prefix Information option's Valid Lifetime field is zero,
        and the prefix is not present in the host's Prefix List,
        silently ignore the option.

next-hop determination does not use any prefix not in the prefix
list. if you have an RA without PIOs or without the on-link flag set you
don't add anything to the prefix list. therefore you'll pick one of the
routers from the default router list.

perhaps if any of the implementors getting this wrong could speak up. as
to me this seems pretty clear.

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 3 Jul 2007 10:56:32 -0400

Ole,

You said:

"next-hop determination does not use any prefix not in the prefix list."

Well, this is exactly the problem with host implementations we are
concerned with. The prefix list is being populated with a prefix when
the list should not be populated.

In this regard, bullets 2 and 3 in Section 2 of our I-D show the issue
hosts have when hosts incorrectly always add a directly connected route
to the /64 prefix from an address assigned to an interface, even if the
prefix is advertised as "not on link" or is not advertised at all. That
incorrectly added route causes the host to try to use direct delivery
(without sending traffic to the default router) and, therefore, use
NS/NA to resolve addresses from the same prefix. 

We are prepared in this discussion that no host implementers will reply
to our thread. We judge host implementations by lack of
interoperability.  Remember we said even an IPv6 certification agency
missed this behavior. We have also said in the past that our I-D
contains a clear, concise set of rules for common host pitfalls and the
I-D also clarifies text in 2461bis and 2462bis.  If one very carefully
reads between the lines of 2461bis and 2462bis, and reads every part of
the specification and thinks about it very carefully, it is conceivable
that one might be able to implement a completely compliant host.
Unfortunately, even after a decade, we have non-compliant hosts
behavior, which indicates that specifications could have been written
more clearly.

- Hemant & Wes

-----Original Message-----
From: Ole Troan (otroan) 
Sent: Tuesday, July 03, 2007 10:27 AM
To: Hemant Singh (shemant)
Cc: Vlad Yasevich; Wes Beebee (wbeebee); [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

> Let's talk specifics, not generics. Of course, we know about section 
> 5.2 of 2461bis.
>

> putting two-and-two together. As described in section 2.1 of our I-D, 
> if a host has not been sent any PIO in RA, and the host performed 
> DHCPv6, the host has no way to determine what's on-link for the host. 
> Section
> 5.2 just says "if the destination in on-link...". Well, discussion 
> first has to be made as to how can a host determine what's on-link for
it.

next-hop determination does not use any prefix not in the prefix list.
if you have an RA without PIOs or without the on-link flag set you don't
add anything to the prefix list. therefore you'll pick one of the
routers from the default router list.

/ot

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 03 Jul 2007 11:41:50 -0400

>    on-link before performing address resolution. 

Yes.  RFC 2461 allowed you to do that with it's "default on-link" assumption.
The assumption was that if you did not have an on-link and default routes,
they you assumed that the destination was on-link.

This assumption has been removed from 2461bis.  However, we can't force
all existing implementations to change.  All we can do is update the spec.
Existing implementations can still claim conformance to 2461, but not 2461bis.

> These are the clarifications we have made in our I-D.

Hm...  Searching for "on-link determination" in the text for 2461bis yields
7 instances that describe how it's done and what information is used.

> ? ND has to be clarified as we have done so in our I-D.

That may be...  however some of the text in you draft goes too far.  I haven't
read the last version, but I was in the middle of preparing comments
on the last one.

I'll re-read the new version and send comments.

-vlad

---

From: Markku Savela <[email-masked]>
Date: Tue, 3 Jul 2007 18:42:56 +0300

> the list should not be populated.

As an implementor IPv6 stack, I say that I had no problem
understanding the L & A bits in prefix announcements.

Just have to verify... You are aware about the "onlink assumption when
no routers present" rule? Early RFC had some wording about that host
must assume any address is onlink, when no routers are present (or was
it "when no route for the destination is found, then try assuming it's
onlink").

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 3 Jul 2007 12:00:13 -0400

Hi Vlad,

Please see in line below against "<hs>". 

-----Original Message-----
From: Vlad Yasevich [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2007 11:42 AM
To: Hemant Singh (shemant)
Cc: Ole Troan (otroan); Wes Beebee (wbeebee); [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

>    on-link before performing address resolution. 

Yes.  RFC 2461 allowed you to do that with it's "default on-link"
assumption.
The assumption was that if you did not have an on-link and default
routes, they you assumed that the destination was on-link.

<hs> We are aware of this change from RFC 2461 to 2461bis due to Alain
Durand's I-D which is discussed in bullet 6, section 2 of our I-D.

This assumption has been removed from 2461bis.  However, we can't force
all existing implementations to change.  All we can do is update the
spec.
Existing implementations can still claim conformance to 2461, but not
2461bis.

<hs> If there were a old vs. new implementation issue we were concerned
about, we would have raised the issue. When you raise old vs. new as
above, you have not seen our point. Even for a new implementation, the
host will behave incorrectly because the host populates Prefix list when
the host should not. That is what we replied to in our earlier email on
the subject:

[The prefix list is being populated with a prefix when the list should
not be populated.

NS/NA to resolve addresses from the same prefix.]

it.
> These are the clarifications we have made in our I-D.

Hm...  Searching for "on-link determination" in the text for 2461bis
yields
7 instances that describe how it's done and what information is used.

<hs> And yet hosts still don't get it right!

> 
> Proof is also in the pudding. We also say in Abstract of our I-D, if 
> ND RFC's are almost 10 years old, why are popular hosts still making 
> mistakes with on-link determination or totally not heeding L bits of 
> RA ? ND has to be clarified as we have done so in our I-D.

That may be...  however some of the text in you draft goes too far.  I
haven't read the last version, but I was in the middle of preparing
comments on the last one.

<hs> Sounds fine. Thanks for the review of our I-D. Please let us know
what text in our I-D goes too far.

Thanks,

-Hemant & Wes.

-vlad

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 3 Jul 2007 12:17:43 -0400

Markku,

-----Original Message-----
From: Markku Savela [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2007 11:43 AM
To: [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

> the list should not be populated.

As an implementor IPv6 stack, I say that I had no problem understanding
the L & A bits in prefix announcements.

<hs> We are not saying a host implementer cannot get it right. We are
saying some don't. We have found a popular host implementation to be
blatantly ignoring off-link indication in RA. Further, hosts are most
confused for data forwarding and address resolution when no PIO is sent
in RA. That is what we focused on in section 2.1 of our I-D. 

<hs> Please refer to bullet 6, section 2 of our I-D where we discuss
this case. The case of a network in which no routers are present is
covered by text in the bullet. If no routers are present, the Default
Router List will be empty. Our text says "If the Default Router List is
empty, the host MUST NOT assume that all destinations are on-link..."
The corresponding text has changed from 2461 to 2461bis.  We are aware
that there are some implementations which may be compliant with 2461
that are not compliant with 2461bis.

Thanks,

- Hemant & Wes.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 05 Jul 2007 14:15:56 +0900

At Tue, 3 Jul 2007 10:56:32 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

> to our thread.

I already explained the BSD implementation correctly handles a prefix
advertised via an RA with the L bit being off.  Out of curiosity,
which host implementation are you specifically talking about?  You
have repeatedly stated something like "an implementer of a popular
IPv6 host [...] missed this behavior", but I don't think I've heard
which implementation it is.  Is there any reason for not being
specific?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 5 Jul 2007 12:49:21 -0400

Tatuya,

Have you tested BSD by sending it an RA  with no PIO and M and O bits
set so that BSD initiates DHCPv6 ? Once BSD host is online with DHCPv6
completed, issue a ping from BSD machine to another IPv6 machine on the
same link. BSD should send this ping to the default router and NOT issue
any NS to try and resolve the ping destination. Since RA did not
advertise any PIO, BSD host  has no means to make an on-link
determination and thus not issue any NS because issuing an NS just told
us BSD assumed the ping destination in on-link - that is wrong behavior.

Do also test the converse thing. A host could be incorrectly implemented
by always sending all traffic to default router and not issuing any NS.
Send an RA with PIO to BSD DHCPv6 host advertising a prefix as on-link.
Then issue a ping to another host on the same link for which the prefix
was advertised as on-link. If BSD sent the ping to default router that
is wrong. BSD has to issue an NS to resolve the destination of the ping.

Thanks.

Hemant

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 1:16 AM
To: Hemant Singh (shemant)
Cc: Ole Troan (otroan); Vlad Yasevich; [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

> hosts have when hosts incorrectly always add a directly connected 
> route to the /64 prefix from an address assigned to an interface, even

> if the prefix is advertised as "not on link" or is not advertised at 
> all. That incorrectly added route causes the host to try to use direct

> delivery (without sending traffic to the default router) and, 
> therefore, use NS/NA to resolve addresses from the same prefix.
> 
> We are prepared in this discussion that no host implementers will 
> reply to our thread.

I already explained the BSD implementation correctly handles a prefix
advertised via an RA with the L bit being off.  Out of curiosity, which
host implementation are you specifically talking about?  You have
repeatedly stated something like "an implementer of a popular
IPv6 host [...] missed this behavior", but I don't think I've heard
which implementation it is.  Is there any reason for not being specific?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba
Corp.
					[email-masked]

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 5 Jul 2007 14:38:57 -0400

Hi Hemant

Here is my review of your draft.  Comments are inside the <vy> </vy>
blocks.  

-vlad

1.  Introduction

   IPv6 host data forwarding and address resolution is complex.  For
   example, RFC 2461 [ND] (section 3.1) implies that if the RA received
   by the host does not advertise any prefix, then the host must send
   all non-link-local data to the default router.  This section of the
   RFC also implies that no address resolution is to be performed in
   this case.  Sections 5.2 and 7.2.2 imply that the host performs
   address resolution before transmitting a packet if the destination of
   the packet is on the same link as the host.  Some current host
   implementations perform address resolution in all cases even when the
   destination is not clearly on-link.  However, RFC 2461 [ND] section
   6.3.4 implies that hosts must clearly determine that a destination is
   on-link before performing address resolution.

<vy>
I believe that you are reading too much into section 3.1.  That section
simply does a comparison to IPv4.  It does not mandate anything and
doesn't not specify any specific beavhior.  That is saved for later.

One could argue that this section might have a touch more technical
information there then strictly need, but it is still not meant to
specify any requiremens.
</vy>

   These implications in RFC 2461 [ND] need to be made explicit.
   Failure of host implementations to comply can result in lack of IPv6
   connectivity.  For example, a host receives an RA with no prefix
   advertised and incorrectly decides to perform address resolution when
   the host should have sent all traffic to the default router.  The
   router may not respond to the address resolution and the layer 2
   driver of the host stops transmitting IPv6 packets.

<vy>
Are these meant to describe 2 different scenarios or just one?  If only
one, both implementations violate multiple aspects of the protocol.
</vy>

2.  Host Models

   A correctly implemented IPv6 host MUST adhere to the following rules:

   1.  On-link determination and address information MUST NOT persist
       across IPv6 interface initializations.

<vy>
Either you are not clear enough here, or this requirement is overly
strict.  There is nothing with having configured address information
persist acrsoss across full system or interface initializations.

I agree that on-link determination information SHOULD NOT persist,
but clever people can do some very clever things.  I think SHOULD NOT
is strong enough.
</vy>

   2.  The RA and Redirects from the default router are the only sources
       of information for on-link determination.  DHCPv6 or any other
       configuration on the host MUST NOT be used for on-link
       determination.

<vy>
You should really restrict this to other types for dynamic configuration
</vy>

   3.  The host MUST NOT add a direct delivery route to the prefix from
       an assigned address, independent of the information about the
       prefix received from the RA or Redirects.
<vy>
Can you please explain what exactly you mean here.  I am having
difficulty properly understanding this sentence.
</vy>

   5.  The host SHOULD issue only a single NS(DAD) for each address.
       The default value for DupAddrDetectTransmits variable is
       specified as 1 in section 5.1 of RFC 2462 [ADDRCONF].

<vy>
What exactly are you trying to address with this text?  When I read
it, my first impulse is to assume that you want to limit the number
of DAD Soliciations to 1 per address, which is not really correct
and is _probably_ not what you mean.  Can you explain a little more.
</vy>

   6.  If the Default Router List is empty, the host MUST NOT assume
       that all destinations are on-link.  The host MUST NOT perform
       address resolution for non-link-local addresses.  The host SHOULD
       send an ICMPv6 Destination Unreachable message instead.
<vy>
No that's not correct.  The host can perform address resolution if he
has on-link prefexis.  It it permissable to have on-link prefixes without
specifying a default router (I have a private isolated network).
</vy>

2.1.  RA Sets M and O Bits but does not Include the Prefix Information
      Option (PIO)

[... draft text snipped ...]

   An IPv6 router sends an RA with no prefix advertised and the M and O
   bits set and does not send any Redirects.  On receipt of the RA, the
   host uses DHCPv6 to acquire an IPv6 address.  After completing IPv6
   address acquisition, the host MUST obey RFC 2461 [ND], section 3.1.
   Since the RA is the only authority to a host for on-link
   determination and this RA does not advertise any prefix, the host
   cannot determine that a destination is on-link.  Therefore, the host
   MUST adhere to the following rules:

   1.  The host MUST NOT assume any default prefix length.

   2.  The host MUST send all non-link-local traffic to the default
       router.

   3.  The host MUST NOT issue an NS to resolve a destination other than
       a link-local address.

<vy>
One can argue that a host/DHCP client that inferes a prefix length
from a leased address is prone to other failures as well.  In this
case, it's the DHCP client that is most likely a problem, unless
the host implementation mistakenly alwasy assumes /64 length.  I think
this is actually warned against in the Address Architure document.

2461bis clearly states that a set 'L' flag is the only determination
of on-link.  Anything else you can report to your vendor as "Bug".

The above actually would be a very good test to add to the TAHI conformance
test suite.
</vy>

2.2.  RA Advertises a Prefix with the On-link(L) Bit Set

[... draft text sniped ...]

   Consider the following scenario with one rogue node and two other
   hosts on the same link.  The rogue sends a malicious RA with an on-
   link prefix with a Valid Lifetime of zero.  Host1 correctly
   implements section 5.5.3 of RFC 2462 [ADDRCONF] and resets its
   StoredLifetime (or RemainingLifetime in draft-ietf-ipv6-rfc2462bis-08
   [ADDRCONFbis]) to two hours and avoids the denial of service attack.
   Host1 tries to send traffic to Host2, but cannot trust its own two
   hour StoredLifetime.  For instance, a legitimate operator may have
   tried to time out the prefix due to an impending renumbering.  Host1
   decides to send all of its traffic to the on-link authority, the
   default router, even though the destination prefix is on-link.

   IF the host decides to send all traffic (including on-link traffic)
   to the default router, then the host MUST follow the following rule:

   1.  The host MUST NOT issue an NS to resolve a destination other than
       a link-local address.

<vy>
This is kind of reduntant.  The host can either determine that the
destination is on-link (i.e it trusts its prefix list), or it sends it
to the default router.  The only time it would preform NS would be for
on-link determination which means that it trust the prefix list.
I don't see any further need to call out this particular scenario.
</vy>

2.3.  RA Advertises a Prefix with the On-link(L) Bit Clear

   Regardless of whether the host performs DHCPv6 and/or stateless
   autoconfiguration, the host MUST adhere to the following rules for
   addresses contained within the advertised prefix:

   1.  The host MUST NOT issue an NS to resolve a destination other than
       a link-local address.

   2.  The host MUST send all non-link-local traffic to the default
       router.

<vy>
No.  If the host already had a on-link prefix in the list that matches
the the one with 'L' bit clear, it should not change the on-link assumption
and continue using address resolution.

If this is a new prefix with the 'L' bit clear, then 2461bis already
addresses this issue appropriatly.
</vy>

3.1.  Aggregation Router Deployment Model

   No NS to resolve any address other that that of the default router
   will reach the aggregation router from any device on the customer
   side of the aggregator.  CPEs do not communicate with each other in
   this deployment model since a CPE does not run any applications that
   need to communicate with other CPEs.  Hosts do communicate with each
   other, but every host is off-link to any other host on the
   aggregation router.

<vy>
Yes, they are off-link.  So why would they thing their are on-link?
Each CPE Rtr or Cust Rtr whould have it's own prefix that would
be advertized to the CPE hosts.  Therese prefixes would aggregate
at the Agregator.   Why would NSs from the CPE hosts escape?
</vy>

5.  Changes to draft-ietf-ipv6-rfc2461bis-11

[... old text snipped ...]

      "Multiple prefixes can be associated with the same link.  By
      default, hosts learn all on-link prefixes from Router
      Advertisements.  However, routers may be configured to omit some
      or all prefixes from Router Advertisements.  In such cases hosts
      assume that destinations are off-link and send traffic to routers.
      A router can then issue redirects as appropriate.  Without
      advertised prefixes, without manual configuration, and without
      redirects, hosts MUST NOT assume a default prefix length, MUST
      send all non-link-local traffic to the default router and MUST NOT
      issue an NS to resolve any destination other than a link-local
      address.

<vy>
No, this is the wrong section to include such requirements since the section
currenlty doesn't place any specific requirements on the implementation.
</vy>

6.  Changes to draft-ietf-ipv6-rfc2462bis-08

[... old text snipped ...]

   to read as follows:

      Each individual unicast address SHOULD be tested for uniqueness.
      Note that some deployed implementations perform Duplicate Address
      Detection (DAD) only for the link-local address and skip the test
      for the global address using the same interface identifier.
      Whereas this document does not invalidate such implementations,
      this kind of 'optimization' is NOT RECOMMENDED, and new
      implementations MUST NOT do that optimization.  This optimization
      came from the assumption that all of an interface's addresses are
      generated from the same interface identifier (see RFC 2462
      [ADDRCONF]).  However, even with this assumption, skipping DAD for
      non-link-local addresses with manual configuration creates an
      additional problem.  This optimization allows an interface to
      claim a duplicate address in a way that would not be detected.
      For a more detailed description of this problem, see the Host
      Models section of
      draft-wbeebee-nd-implementation-pitfalls-01.  Further, new
      types of addresses have been introduced where the interface
      identifiers are not necessarily the same for all unicast addresses
      on a single interface [RFC3041] [RFC3972].  Requiring an interface
      to perform DAD for all unicast addresses will make the algorithm
      more robust.

<vy>
Two issues:
 1. This text is not any stronger then the existing text in 2461bis and
    doesn't add anything significant.

 2. It creates a normative reference to a personal draft at a very late
    stage in the life of 2461bis.

I don't see a reason to add this text
</vy>

My conlcusion:

After re-reading 2461bis and 2462bis multiple times as result of reviewing
this draft, I can see some small value in creating an "On-Link Determination"
section in draft 2461bis.

Alternatively, this draft should crate such section and, with references
to text in 2461bis, should clarify the on-link determination behavior.
It could then be issued as an update.

-vlad

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 06 Jul 2007 11:25:28 +0900

At Thu, 5 Jul 2007 12:49:21 -0400,

> is wrong. BSD has to issue an NS to resolve the destination of the ping.

I previously tested these scenarios.  I've not done that recently, but
I'm pretty sure that BSDs would still show the conforming behavior in
both of the test cases (i.e., send the packet to the default router in
the first scenario; send NS in the second scenario).

					JINMEI, Tatuya

---

From: Julien Laganier <[email-masked]>
Date: Fri, 6 Jul 2007 16:09:42 +0200

On Friday 06 July 2007 04:25, JINMEI Tatuya / ???? 
wrote:
> > Have you tested BSD by sending it an RA  with no
> > PIO and M and O bits set so that BSD initiates
> > DHCPv6 ? Once BSD host is online with DHCPv6
> > completed, issue a ping from BSD machine to
> > another IPv6 machine on the same link. BSD should
> > send this ping to the default router and NOT issue
> > any NS to try and resolve the ping destination.
> > Since RA did not advertise any PIO, BSD host  has
> > no means to make an on-link determination and thus
> > not issue any NS because issuing an NS just told
> > Do also test the converse thing. A host could be
> > incorrectly implemented by always sending all
> > traffic to default router and not issuing any NS.
> > Send an RA with PIO to BSD DHCPv6 host advertising
> > a prefix as on-link. Then issue a ping to another
> > host on the same link for which the prefix was
> > advertised as on-link. If BSD sent the ping to
> > default router that is wrong. BSD has to issue an
> > NS to resolve the destination of the ping.
>
> I previously tested these scenarios.  I've not done
> that recently, but I'm pretty sure that BSDs would
> still show the conforming behavior in both of the
> test cases (i.e., send the packet to the default
> router in the first scenario; send NS in the second
> scenario).

FWIW, tested both of these 3 months ago for NETLMM 
related work and it did work fine!

-- julien

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 6 Jul 2007 14:21:03 -0400

Vlad,

Thanks very much for the review. Please see our responses in line below
against "<hs>". 

-----Original Message-----
From: Vlad Yasevich [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 2:39 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

Hi Hemant

-vlad

1.  Introduction

<vy>

<hs> Totally agree with you. We want to just add a new line or two to
the relevant para in section 3.1 where the new lines say "go to a
section further down in the document for concrete details."  Note that
we simply state that this should be made explicit - but in our
introduction, we do not specify exactly how.  For more information on
how we wish to be more explicit, see the changes to 2461bis and 2462bis
sections.

<vy>
Are these meant to describe 2 different scenarios or just one?  

<hs> Just one scenario. A router may not respond to the NS issued by
host to resolve the packet destination. That causes the host's L2 driver
to just sit there. The net result is no packets get out of the host.

If only one, both implementations violate multiple aspects of the
protocol.
</vy>

2.  Host Models

<vy>

I agree that on-link determination information SHOULD NOT persist, but
clever people can do some very clever things.  I think SHOULD NOT is
strong enough.
</vy>

<hs> OK, we will change MUST NOT to SHOULD NOT to allow for clever
implementations. One thought we had was that DHCPv6 clients can
certainly change address across IPv6 interface initializations - that is
what prompted us to this rule having enforced it for SLAAC clients as
well. The new bullet text follows:

"1. On-link determination SHOULD NOT persist across IPv6 interface
initializations. Note that section 5.7 of draft-ietf-ipv6-rfc2462bis-08
(Thomson, S., Narten, T., and T. Jinmei, "IPv6 Address autoconfiguration
(IPv6)," May 2005.) [ADDRCONFbis] describes the use of stable storage
for addresses acquired with stateless address autoconfiguration with a
note that the Preferred and Valid Lifetimes must be retained if this
approach is used." 

   "2.  The RA and Redirects from the default router are the only
sources
        of information for on-link determination.  DHCPv6 or any other
        configuration on the host MUST NOT be used for on-link
        determination."

<vy>

<hs> We noticed this one too and have made a change to this bullet.
Please see if the new text below for this bullet makes sense to you.

---------------
   "2. The on-link definition in section 2.1 of
       draft-ietf-ipv6-2461bis-11 [NDbis] 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
       draft-ietf-ipv6-2461bis-11 [NDbis] does not include manual
       configuration."
-----------------

<hs> In this regard, we describe the issue hosts have when hosts
incorrectly add a directly connected route to a /64 prefix from an
address assigned to an interface, even if the prefix is advertised as
"not on-link" or not advertised at all. The host incorrectly assumed a
/64 prefix length.
After assuming the prefix length, the host added a directly connected
route entry for such a prefix to the host forwarding tables. The
incorrectly added route causes the host to try to use direct delivery
(without sending traffic to the default router) and, therefore, use
NS/NA to resolve addresses from the same prefix.

<vy>
What exactly are you trying to address with this text?  When I read it,
my first impulse is to assume that you want to limit the number of DAD
Soliciations to 1 per address, which is not really correct and is
_probably_ not what you mean.  Can you explain a little more.
</vy>

<hs> Not quite. This bullet hasn't changed in our I-D from the
definition of DupAddrDetectTransmits in 2462bis. Section 5.1 of 2462bis
clearly says default value of this variable is 1. Then the section goes
on to say the value can be overriden by a linktype specific value. That
is why we say in our I-D, the host SHOULD issue only single NS(DAD)
because the default is 1. The SHOULD also caters to any other value
being used. We found an interesting behavior in an IPv6 cable modem host
stack. The modem was sending 4 NS(DAD)'s for Link-local address and 5
NS(DAD)'s for DHCPv6 address. In the cable broadband deployment,
upstream bandwidth (direction from modem to aggregator router) is very
limited and if every modem is issuing 9 NS(DAD)'s before the modem gets
online, a lot of bandwidth is being wasted in the network. The
aggregator supports 60,000-100,000 modems and if each modem sends 9
NS(DAD)'s, it's a lot of data for the aggregator, especially during
reload of the aggregator when all the modems will try to get online
concurrently.

   6.  If the Default Router List is empty, the host MUST NOT assume
       that all destinations are on-link.  The host MUST NOT perform
       address resolution for non-link-local addresses.  The host SHOULD
       send an ICMPv6 Destination Unreachable message instead.
<vy>
No that's not correct.  The host can perform address resolution if he
has on-link prefexis.  It it permissable to have on-link prefixes
without specifying a default router (I have a private isolated network).
</vy>

<hs> Agreed. We have to make rules tighter here. Please see the new
bullet below:

----------------
    "6. Newer implementations, which are compliant with
       draft-ietf-ipv6-rfc2461bis-11 [NDbis] MUST adhere to the
       following rules.  Older implementations, which are compliant with
       RFC 2461 [ND] but not draft-ietf-ipv6-rfc2461bis-11 [NDbis] may
       remain as is.  If the Default Router List is empty and there is
       no other source of on-link information about any address or
       prefix:

       1.  The host MUST NOT assume that all destinations are on-link.

       2.  The host MUST NOT perform address resolution for non-link-
           local addresses.

       3.  The host SHOULD send an ICMPv6 Destination Unreachable
           message instead.

       On-link information concerning particular addresses and prefixes
       can make those specific addresses and prefixes on-link, but does
       not change the default behavior mentioned above for addresses and
       prefixes not specified.  draft-ietf-v6ops-onlinkassumption-04
       [I.D.ietf-v6ops-onlinkassumptions] provides justification for
       these rules."
-----------------------

<vy>
One can argue that a host/DHCP client that inferes a prefix length from
a leased address is prone to other failures as well.  In this case, it's
the DHCP client that is most likely a problem, unless the host
implementation mistakenly alwasy assumes /64 length.  I think this is
actually warned against in the Address Architure document.

<hs> The host implementation has assumed a /64 length in the tests we
did. 

2461bis clearly states that a set 'L' flag is the only determination of
on-link.  Anything else you can report to your vendor as "Bug".

The above actually would be a very good test to add to the TAHI
conformance test suite.
</vy>

<hs> I contacted TAHI on May 16th, 2007 to add such a test case to the
IPv6 conformance test suite. On June 19th, 2007, someone replied. I have
to work with them to make sure this test is added to their test suite.

<vy>

<hs> Before we added these rules, one reviewer complained that we had
rules in all the other sections, but not this one.  Therefore, we added
the rules to satisfy the reviewer.  As for the scenario, this scenario
allows a host to send all traffic to the default router even for a
prefix advertised as on-link.  This is very important if we want to
describe ALL the behavior possible with respect to on-link
determination.

<vy>
No.  If the host already had a on-link prefix in the list that matches
the the one with 'L' bit clear, it should not change the on-link
assumption and continue using address resolution.

<hs> You are correct. We changed our I-D for this section - see changed
text below:

"2.3.  RA Advertises a Prefix with the On-link(L) Bit Clear
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]." 
"

<vy>
Yes, they are off-link.  So why would they thing their are on-link?
Each CPE Rtr or Cust Rtr whould have it's own prefix that would be
advertized to the CPE hosts.  Therese prefixes would aggregate
at the Agregator.   Why would NSs from the CPE hosts escape?
</vy>

<hs. True the NS's from CPE hosts would not escape. We are just
highlighting a deployment design such that the aggregator in the
deployment will not have to support ND Proxy.

<vy>
No, this is the wrong section to include such requirements since the
section currenlty doesn't place any specific requirements on the
implementation.
</vy>

<hs> Agreed. We will put the strict text elsewhere in 2461bis and just
add a reference in this para to that stricter text.

   to read as follows:

<vy>
Two issues:

<hs> Yes it is. We have been told by a number of people that whether to
skip DAD or not was discussed at length in the IETF IPv6 WG and mailer.
If so much discussion happened and RFC 2462 changed in 2462bis I-D to
remove the skipping DAD requirement for newer hosts, we'd like to see
the reasons for the change. The only reason we found in 2462bis for the
change was:

      "new types of addresses have been introduced where the
      interface identifiers are not necessarily the same for all unicast
      addresses on a single interface [RFC3041] [RFC3972]."

Well, we provided an example scenario in our I-D (section 2, bullet 4)
that highlights that fact the skipping DAD combined with manual
configuration can result in duplicate addresses on the same link which
are not detected. Our new example provides an important NEW reason that
shows that even when an interface uses the same identifier for
Link-local Address and a Globally Unique Address, skipping DAD caused
failure to detect a duplicate address.  If DAD was not skipped, the
duplicate address would be detected.  That is why we wanted our new text
to be added to 2462bis.

<hs> Because our I-D came in very late, when 2462bis was in AUTH48
state, we can remove the reference from the modified paragraph above.
However, we would still like our new sentences to be added.  If more
explanation is needed (to compensate for the removed reference), we can
certainly write one.

My conlcusion:

After re-reading 2461bis and 2462bis multiple times as result of
reviewing this draft, I can see some small value in creating an "On-Link
Determination"
section in draft 2461bis.

<hs> We are preparing text with regards to additional changes to 2461bis
to add to Section 5 of our I-D.  We're glad that you agree that on-link
determination as described by the current specifications can be
confusing.

Regards.

- Hemant & Wes

-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 06 Jul 2007 15:32:39 -0400

Hi Hemant

> how we wish to be more explicit, see the changes to 2461bis and 2462bis

OK.

> to just sit there. The net result is no packets get out of the host.

As I said bellow, both implementation violate the specs.  At this point,
not sure if clarifying the spec by placing additional restrictions is
useful.  Submitting bugs against the implementation is probably better.

> "1. On-link determination SHOULD NOT persist across IPv6 interface
"On-link determination state SHOULD NOT persist..."

Makes it a little more clear what you are saying.  Otherwise, looks fine
to me.

> Please see if the new text below for this bullet makes sense to you.

OK.

> NS/NA to resolve addresses from the same prefix.

So, here the implementor completely disregarded either the section about
the L-bit being 0 doesn't mean off-link, or the section at the top of page
19 of 2462bis to not expect all IIDs to be 64 bit and thus assume a 64 bit
prefix.

I guess a final "On-Link Determination" section might help.

However, these types of errors are typical of the manual configuration
and there is not much we can do here.

> NS(DAD)'s for DHCPv6 address.

REALLY???  Unless the mode was explicitly configured to do this, I don't see
how the text you recommend would fix this glaring error...  In fact,
I could claim that this behavior would still be within spec if the manufacturer
or operator determines that they want this behavior.

So the new text you are introducing would be completely nullified.

> <hs> Agreed. We have to make rules tighter here. Please see the new

Ok, the text is clearer, but it reads like an over-specification to me.

So many of the issues that you've found have to do with improper implementation
of on-link determination that I am really starting to thing that a single
section on clarifying it would be useful in your daft.

> <hs> The host implementation has assumed a /64 length in the tests we

Yes, and 2462bis weasel words around this issue at the top of page 19.
Maybe a "should" there needs to be changed to a "SHOULD"?

> to work with them to make sure this test is added to their test suite.

OK.  That would be good.

> describe ALL the behavior possible with respect to on-link

OK.

> flag set and be used by [ADDRCONF]." 

OK.

> deployment will not have to support ND Proxy.

OK.  But you are going about it by using keyword language (use of SHOULD in
that section).  It just felt odd.  I had to re-read the section a few
times and just couldn't understand the point.  It seemed obvious.

> add a reference in this para to that stricter text.

Yes, this is the same as the first issue.  References are always better. :)

> are not detected. 

The example you provide has been documented in the Neighbor Discover Threats
spec (rfc 3756).  So that's documented fairly well.  The Security Consideration
section also references it and points out issues with DAD.

The only thing that _might_ be missing is a reference to such threats from
withing the DAD section, as additional rational for not skipping DAD, but that's
fairly weak.

> determination as described by the current specifications can be

One thing I've noted is that you have the _same_rules_ in almost every section.
What I am proposing is that you restructure the text a little.

In each section describe some inconsistencies or behaviors that you've seen
as non-compliant.  Don't add rules to each section.  Instead have one
section where you clarify the behavior using requirement keywords.  Since
most issues are centered around on-link determination, that should be
fairly easy.

-vlad

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 9 Jul 2007 10:09:43 -0400

Vlad,

Please see in line below with "<hs>". 

-----Original Message-----
From: Vlad Yasevich [mailto:[email-masked]] 
Sent: Friday, July 06, 2007 3:33 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

Hi Hemant

Hemant Singh (shemant) wrote:
> Vlad,
> 
> <vy>
> I believe that you are reading too much into section 3.1.  That 
> section simply does a comparison to IPv4.  It does not mandate 
> anything and doesn't not specify any specific beavhior.  That is saved
for later.

> how we wish to be more explicit, see the changes to 2461bis and 
> 2462bis sections.

OK.

> host to resolve the packet destination. That causes the host's L2 
> driver to just sit there. The net result is no packets get out of the
host.

<hs> At least in the Introduction section of our I-D, we are just giving
a flavor of the serious nature of IPv6 ND problems. Before we wrote our
I-D, we submitted bugs against the implementation. We have to clarify
2461bis in the areas of data forwarding and address resolution because
some suble behavior can cause major problems in the network. We have
already discussed one serious problem in this mailer. If a host assumed
a /64 prefix length when the host wasn't supposed to assume any prefix
length and added the prefix to the Prefix List, the host would perform
address resolution when instead the host could have considered the
prefix to be off-link and sent data to the default router. As we said
before, the router may not respond to the NS and such a host can loose
IPv6 connectivity. See how a simple assumption caused a serious problem.
That is why we have to make 2461bis more strict in such areas. Our goal
is also to not add any additional requirement over 2461bis. 

> certainly change address across IPv6 interface initializations - that 
> is what prompted us to this rule having enforced it for SLAAC clients 
> as well. The new bullet text follows:
> 

OK.

So, here the implementor completely disregarded either the section about
the L-bit being 0 doesn't mean off-link, or the section at the top of
page
19 of 2462bis to not expect all IIDs to be 64 bit and thus assume a 64
bit prefix.

<hs> We are working on details on how to incorporate clarifications from
our I-D into 2461bis. We are open right now for a new section.

<hs> No, in our testing, we did NOT use manual configuration and still
the host behaved in a non-compliant fashion.  We recognize that manual
configuration can introduce additional problems.  We have already
identified manual configuration in our I-D as potentially introducing
problems -
see the last sentence of bullet 2 of section 2 in our I-D.

> it, my first impulse is to assume that you want to limit the number of

> DAD Soliciations to 1 per address, which is not really correct and is 
> definition of DupAddrDetectTransmits in 2462bis. Section 5.1 of 
> 2462bis clearly says default value of this variable is 1. Then the 
> section goes on to say the value can be overriden by a linktype 
> specific value. That is why we say in our I-D, the host SHOULD issue 
> only single NS(DAD) because the default is 1. The SHOULD also caters 
> to any other value being used. We found an interesting behavior in an 
> IPv6 cable modem host stack. The modem was sending 4 NS(DAD)'s for 
> Link-local address and 5 NS(DAD)'s for DHCPv6 address.

REALLY???  Unless the modem was explicitly configured to do this, I
don't see how the text you recommend would fix this glaring error...  In
fact, I could claim that this behavior would still be within spec if the
manufacturer or operator determines that they want this behavior.

<hs> We also told the modem vendor their behavior is compliant with ND
RFC but since bandwidth is limited in a broadband deployment in the
upsteam direction (modem to the aggregation router), having each modem
issue 9 DAD's before the modem got online was a waste of valuable
bandwidth resource. As 2462bis says, it's up to a link-type document to
modify this value. Aggregation router standards will have to take care
of specifying such a value for broadband deployments IF they choose to
use a different value than the default value of 1.

<hs> True. Our aim with this bullet is to only raise an awareness that
default value is 1. Many new IPv6 host developers just read 2461bis and
miss the default value of this variable that is not specified in
2461bis, but is specified in 2462bis.

<hs> We don't think it's over specification. If a host misses first rule
and assumes destinations are on-link, the data delivery break-down can
happen with the host. Bullets 1 and 3 are as is from
draft-ietf-v6ops-onlinkassumption-04.

So many of the issues that you've found have to do with improper
implementation of on-link determination that I am really starting to
thing that a single section on clarifying it would be useful in your
daft.

<hs> Yes, we are putting together such a section.

> case, it's the DHCP client that is most likely a problem, unless the 
> host implementation mistakenly alwasy assumes /64 length.  I think 

<hs> Which words are you talking about? Quick look at 2462bis and even
2461bis on page 19 did not show us any relevant words.

> IPv6 conformance test suite. On June 19th, 2007, someone replied. I 
> have to work with them to make sure this test is added to their test
suite.

OK.  That would be good.

> rules in all the other sections, but not this one.  Therefore, we 
> added the rules to satisfy the reviewer.  As for the scenario, this 
> scenario allows a host to send all traffic to the default router even 
> for a prefix advertised as on-link.  This is very important if we want

> to describe ALL the behavior possible with respect to on-link 
> determination.

OK.

> <hs> You are correct. We changed our I-D for this section - see 
> changed text below:
> 
> "2.3.  RA Advertises a Prefix with the On-link(L) Bit Clear 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]."
> "

OK.

> deployment will not have to support ND Proxy.

OK.  But you are going about it by using keyword language (use of SHOULD
in that section).  It just felt odd.  I had to re-read the section a few
times and just couldn't understand the point.  It seemed obvious.

<hs> Our intent for this section is to describe properties of an
aggregation network and not specify any normative changes. We will
change the "SHOULD NOT" to "should not".

> add a reference in this para to that stricter text.

Yes, this is the same as the first issue.  References are always better.
:)

> <hs> Yes it is. We have been told by a number of people that whether 
> to skip DAD or not was discussed at length in the IETF IPv6 WG and
mailer.
> the reasons for the change. The only reason we found in 2462bis for 
> the change was:
> 

> are not detected.

The example you provide has been documented in the Neighbor Discover
Threats spec (rfc 3756).  So that's documented fairly well.  The
Security Consideration section also references it and points out issues
with DAD.

<hs> No, we disagree that the problem we have highlighted in bullet 4 of
our I-D is mentioned anywhere in RFC 3756 - you will have to point it
out to us.  Our problem is saying mixing "skipping DAD" and manual
configuration is a bad idea and also shows that even if Link-local
address and Global Unique Address (GUA) of the host are created from the
same identifier (Host2 in our example), one will have duplicate
addresses on the link that would not be detectable. Further, this
problem is detectable if DAD is not skipped for the GUA by Host2. The
duplicate will be detected because even Host1 is a compliant host in our
model, not a rogue host. Please see an earlier email discussion between
ourselves and Tataya on this one.

The only thing that _might_ be missing is a reference to such threats
from withing the DAD section, as additional rational for not skipping
DAD, but that's fairly weak.

> reviewing this draft, I can see some small value in creating an 
> "On-Link Determination"
> Alternatively, this draft should crate such section and, with 
> references to text in 2461bis, should clarify the on-link
determination behavior.
> <hs> We are preparing text with regards to additional changes to 
> 2461bis to add to Section 5 of our I-D.  We're glad that you agree 
> that on-link determination as described by the current specifications 
> can be confusing.
> 

One thing I've noted is that you have the _same_rules_ in almost every
section.
What I am proposing is that you restructure the text a little.

In each section describe some inconsistencies or behaviors that you've
seen as non-compliant.  Don't add rules to each section.  Instead have
one section where you clarify the behavior using requirement keywords.
Since most issues are centered around on-link determination, that should
be fairly easy.

<hs> We'll think about it and get back to you.

Thanks.

- Hemant & Wes.

-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 09 Jul 2007 10:45:27 -0400

Hi Hemnat

> 2461bis, but is specified in 2462bis.

IMO this is already fairly well spelled out in 2461bis.  There was talk
earlier on the list of adding something along the list of:
    This document RECOMMENDS that implementations use default values specified
    here.

I don't remember what happened to that, but that should do what you want.
> <hs> Yes, we are putting together such a section.

OK. I'll wait for the new text.

> 2461bis on page 19 did not show us any relevant words.

      Note that a future revision of the address architecture [RFC3513]
      and a future link-type specific document, which will still be
      consistent with each other, could potentially allow for an
      interface identifier of length other than the value defined in the
      current documents.  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers.

I suggest the 'should' in the last sentence be replaced by SHOULD.

> ourselves and Tataya on this one.

You are right.  I just re-read 3756 and this item is not there.  I would
agree to adding the rationale for why skipping DAD is not recommended.
Any additional text can be safely removed.

Something like:
   -  Each individual unicast address SHOULD be tested for uniqueness.
      Note that there are implementations deployed that only perform
      Duplicate Address Detection for the link-local address and skip
      the test for the global address using the same interface
      identifier as that of the link-local address.  Whereas this
      document does not invalidate such implementations, this kind of
      "optimization" is NOT RECOMMENDED, and new implementations MUST
      NOT do that optimization.  This optimization came from the
      assumption that all of an interface's addresses are generated from
      the same identifier.  However, the assumption does not actually
      stand; new types of addresses have been introduced where the
      interface identifiers are not necessarily the same for all unicast
      addresses on a single interface [RFC3041] [RFC3972].  Additionally,
      hosts that implement the "optimization" may end up configuring
      duplicate addresses and causing network disruptions.  Requiring to
      perform Duplicate Address Detection for all unicast addresses will
      make the algorithm robust for the current and future such special
      interface identifiers.

-vlad

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 9 Jul 2007 11:22:16 -0400

Vlad & Tatuya,

Tatuya, please note another proposed change by Vlad to 2462bis and also
Vlad agrees that a change regarding skipping DAD should be made to
2462bis as per this statement from Vlad: "I would agree to adding the
rationale for why skipping DAD is not recommended."

-----Original Message-----
From: Vlad Yasevich [mailto:[email-masked]] 
Sent: Monday, July 09, 2007 10:45 AM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

Hi Hemnat

> bandwidth resource. As 2462bis says, it's up to a link-type document 
> to modify this value. Aggregation router standards will have to take 
> care of specifying such a value for broadband deployments IF they 
> choose to use a different value than the default value of 1.
> 

> default value is 1. Many new IPv6 host developers just read 2461bis 
> and miss the default value of this variable that is not specified in 

IMO this is already fairly well spelled out in 2461bis.  There was talk
earlier on the list of adding something along the list of:
    This document RECOMMENDS that implementations use default values
specified
    here.

<hs> Since we are working on how to fold in text from our I-D as changes
to 2461bis, this bullet 5 from section 2 of our I-D will also fall into
that work of where to specify this recommendation in 2461bis.

I don't remember what happened to that, but that should do what you
want.

<hs> Ah, this is text on page 17 of 2462bis -08. Good catch. We agree
that the "should" be replaced with SHOULD. So does Tatuya want to make
such a change to 2462bis before sending it off?

> Security Consideration section also references it and points out 
> issues with DAD.
> 
> <hs> No, we disagree that the problem we have highlighted in bullet 4 
> of our I-D is mentioned anywhere in RFC 3756 - you will have to point 
> it out to us.  Our problem is saying mixing "skipping DAD" and manual 
> address and Global Unique Address (GUA) of the host are created from 
> the same identifier (Host2 in our example), one will have duplicate 
> duplicate will be detected because even Host1 is a compliant host in 
> our model, not a rogue host. Please see an earlier email discussion 
> between ourselves and Tataya on this one.

<hs> OK, so we have reached consensus between us for changing the text
of 2462bis. We like our original paragraph because it clearly mentions
manual configuration, which is not mentioned in your suggested
paragraph.

Thanks.

- Hemant & Wes

Something like:
      addresses on a single interface [RFC3041] [RFC3972].
Additionally,

-vlad

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 09 Jul 2007 12:01:35 -0400

> that work of where to specify this recommendation in 2461bis.

That single sentence will do instead and take care of all the other defaults
as well.  I'll to see what happened to that thread, but something like that
would be useful for both 2461bis and 2462bis.
> such a change to 2462bis before sending it off?

Well, looking at 08 draft, it shows up in Section 5.5.3 at the top of
page 19, but I don't really care were the text is as long as it right...

> manual configuration, which is not mentioned in your suggested

Well, we reached agreement, not quire consensus....  In this particular
case, manual configuration is just an example.  There may be other means
of forming the same address.  Regardless of how the address was assigned,
the issue is that skipping DAD is bad.  You wanted to document a rationale,
and for why, and that is what we should do.  The final recommendation
stays the same.

-vlad

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 10 Jul 2007 02:09:13 +0900

At Mon, 9 Jul 2007 11:22:16 -0400,

> rationale for why skipping DAD is not recommended."

As (probably) indicated by Vlad, I don't think we have formed a clear
"consensus" in the "wg as a whole" that warrants a further change to
2462bis at this late stage.  At least I'm not convinced about making
the change to 2462bis at this timing, although I'd support the
stricter requirement of DAD in a separate document (maybe an
implementation guidance as Suresh suggested?) if we agree on it after
discussions in the wg.

I strongly believe 2462bis is pretty good in its current form, and
even though further discussions and resulting possible changes to the
document based on a wg consensus may make it 120% perfect, I don't
think the benefit isn't worth the publication delay.

My current plan is to submit the current version to the RFC editor
in 12 hours or so, unless I see a clear wg consensus on the change by
then.  (For that matter, I'd disagree on introducing this change to
this document at this stage)

					JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 9 Jul 2007 13:21:24 -0400

Tatuya,

If it's too late, it's fine.  On a different note, did you catch the
fact from Vlad who wanted  "should" changed to "SHOULD" in a paragraph
on page 18 of 2462bis? Further, we are also adding that a "should not"
in the same paragraph be changed to "SHOULD NOT". Do you or anyone else
think such a change can be made before the 12 hours expire? This is the
relevant paragraph:

Thanks.

- Hemant & Wes

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Monday, July 09, 2007 1:09 PM
To: Hemant Singh (shemant)
Cc: Vlad Yasevich; [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

At Mon, 9 Jul 2007 11:22:16 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

> Tatuya, please note another proposed change by Vlad to 2462bis and 
> also Vlad agrees that a change regarding skipping DAD should be made 
> to 2462bis as per this statement from Vlad: "I would agree to adding 
> the rationale for why skipping DAD is not recommended."

As (probably) indicated by Vlad, I don't think we have formed a clear
"consensus" in the "wg as a whole" that warrants a further change to
2462bis at this late stage.  At least I'm not convinced about making the
change to 2462bis at this timing, although I'd support the stricter
requirement of DAD in a separate document (maybe an implementation
guidance as Suresh suggested?) if we agree on it after discussions in
the wg.

I strongly believe 2462bis is pretty good in its current form, and even
though further discussions and resulting possible changes to the
document based on a wg consensus may make it 120% perfect, I don't think
the benefit isn't worth the publication delay.

My current plan is to submit the current version to the RFC editor in 12
hours or so, unless I see a clear wg consensus on the change by then.
(For that matter, I'd disagree on introducing this change to this
document at this stage)

					JINMEI, Tatuya

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 09 Jul 2007 13:36:57 -0400

>       particular constant.  Rather, it should expect any lengths of

I am perfectly fine with waiting to clarify this in a implementors guide
style document.  This was trying to address the issue that some implementations
assume a 64 bit prefix when no such guidance have been given (i.e DHCP address lease).

The problem with adding this language now is that there should be consensus from
the working group since even though it looks like an editorial change, it really is not.

-vlad

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 9 Jul 2007 13:45:25 -0400

OK, if this needs consensus for a should to change to SHOULD in this
paragraph, then let's leave it.

Thanks.

Hemant 

-----Original Message-----
From: Vlad Yasevich [mailto:[email-masked]] 
Sent: Monday, July 09, 2007 1:37 PM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / ????; [email-masked]
Subject: Re: Sending traffic to default router when RA has no PIO

> in the same paragraph be changed to "SHOULD NOT". Do you or anyone 
> else think such a change can be made before the 12 hours expire? This 
> is the relevant paragraph:
> 

I am perfectly fine with waiting to clarify this in a implementors guide
style document.  This was trying to address the issue that some
implementations assume a 64 bit prefix when no such guidance have been
given (i.e DHCP address lease).

The problem with adding this language now is that there should be
consensus from the working group since even though it looks like an
editorial change, it really is not.

-vlad