FW: Sending traffic to default router when RA has no PIO

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Friday, July 06, 2007 2:21 PM
To: 'Vlad Yasevich'
Cc: ipv6@ietf.org
Subject: RE: Sending traffic to default router when RA has no PIO

Vlad,

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

-----Original Message-----
From: Vlad Yasevich [mailto:vladislav.yasevich@hp.com]
Sent: Thursday, July 05, 2007 2:39 PM
To: Hemant Singh (shemant)
Cc: ipv6@ietf.org
Subject: Re: Sending traffic to default router when RA has no PIO

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.

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

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?  

<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

   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>

<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>
You should really restrict this to other types for dynamic configuration
</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."
-----------------

   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>

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

   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>

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

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.

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

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>

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

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>

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

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>

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

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>

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

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.

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

 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>

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

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.

<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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------