Internet DRAFT - draft-wbeebee-nd-implementation-pitfalls

draft-wbeebee-nd-implementation-pitfalls






Network Working Group                                           H. Singh
Internet-Draft                                                 W. Beebee
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: January 21, 2008                                  July 20, 2007


       Data Forwarding and ND Resolution Implementation Pitfalls
              draft-wbeebee-nd-implementation-pitfalls-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   RFC 2461 [ND] describes host data forwarding and address resolution.
   However, nine years after the ND protocol became an RFC, IPv6 hosts
   still do not fully comply with RFC 2461 [ND].  In particular, hosts
   incorrectly implement on- vs. off-link data forwarding.  This
   document clarifies host behavior and associated router behavior to
   define explicitly address resolution and data forwarding models.  The
   set of new requirements beyond what has been specified in RFC 2461
   [ND] and RFC 2462 [ADDRCONF] is restricted to clarifications deemed



Singh & Beebee          Expires January 21, 2008                [Page 1]

Internet-Draft         ND Implementation Pitfalls              July 2007


   necessary to facilitate correct implementation.  The intention of
   this document is to incorporate normative changes into
   draft-ietf-ipv6-rfc2461bis-11 [NDbis] and
   draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis].  After this has been
   accomplished, this document will be on track to become an
   Informational RFC.  Following the same model as RFC 2525 [TCPProb], a
   section of this document collects known IPv6 ND implementation
   problems.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Host Models  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  RA Sets the M bit but does not Include the Prefix
           Information Option (PIO) . . . . . . . . . . . . . . . . .  6
     2.2.  RA Advertises a Prefix with the On-link(L) Bit Set . . . .  7
       2.2.1.  When the Valid Lifetime Expires  . . . . . . . . . . .  8
     2.3.  RA Advertises a Prefix with the On-link(L) Bit Clear . . .  8
   3.  Router Models  . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Aggregation Router Deployment Model  . . . . . . . . . . .  9
   4.  Redirect Clarifications  . . . . . . . . . . . . . . . . . . . 10
   5.  Changes to draft-ietf-ipv6-rfc2461bis-11 . . . . . . . . . . . 10
   6.  Changes to draft-ietf-ipv6-rfc2462bis-08 . . . . . . . . . . . 14
   7.  Known IPv6 ND Implementation Problems  . . . . . . . . . . . . 16
     7.1.  Incorrect host data forwarding behavior after
           receiving an RA with no PIO  . . . . . . . . . . . . . . . 16
     7.2.  A DHCPv6 host sending excessive NS(DAD)s . . . . . . . . . 20
     7.3.  Incorrect host behavior after automatic insertion of a
           directly connected route during address acquisition  . . . 22
     7.4.  Aggregation router sending Redirects when hosts
           communicate to each other from behind different modems . . 25
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     11.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  CHANGE HISTORY  . . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
   Intellectual Property and Copyright Statements . . . . . . . . . . 32










Singh & Beebee          Expires January 21, 2008                [Page 2]

Internet-Draft         ND Implementation Pitfalls              July 2007


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.

   These implications in RFC 2461 [ND] need to be made explicit.
   Failure of host implementations to comply can result in lack of IPv6
   connectivity.  One example, included in the Known IPv6 ND
   Implementation Problems section of this document, follows: 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 does not respond to the address
   resolution and the layer 2 driver of the host stops transmitting IPv6
   packets.

   Host address resolution has implications for router design and
   deployment.  First, host behavior is clarified in the Host Models
   section.  Second, a router deployment model is described in the
   Router Models section.  Third, Redirects are clarified for both
   routers and hosts in the Redirect Clarifications section.  Fourth,
   proposed changes to draft-ietf-ipv6-rfc2461bis-11 [NDbis] and
   draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] are presented.  Finally,
   known IPv6 ND implementation problems are described which motivate
   the Host and Router Models rules.

   Where behavior has not changed between RFC 2461 [ND] and
   draft-ietf-ipv6-2461bis-11 [NDbis] and behavior has not changed
   between RFC 2462 [ADDRCONF] and draft-ietf-ipv6-rfc2462bis-08
   [ADDRCONFbis], this document only refers to RFC 2461 [ND] and RFC
   2462 [ADDRCONF] respectively.  Where behavior has changed, this
   document refers to both the original and the new version.


2.  Host Models

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





Singh & Beebee          Expires January 21, 2008                [Page 3]

Internet-Draft         ND Implementation Pitfalls              July 2007


   1.  On-link determination and addresses acquired using DHCPv6 SHOULD
       NOT persist across IPv6 interface initializations.  Note that
       section 5.7 of draft-ietf-ipv6-rfc2462bis-08 [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 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 directly connected route to the prefix
       from an assigned address, independent of the information about
       the prefix received from the sources described in section 2.1 of
       draft-ietf-ipv6-2461bis-11 [NDbis].

   4.  In the absence of other sources of on-link information, including
       Redirects, if the RA advertises a prefix with the on-link(L) bit
       set and the Valid Lifetime expires, the host MUST then consider
       the prefix to be off-link, as suggested by the PIO paragraph of
       section 6.3.4 of draft-ietf-ipv6-2461bis-11 [NDbis].  However, if
       the RA advertises a prefix with the on-link bit set, the host MAY
       ignore the on-link indication from the RA and treat the prefix as
       off-link.  Subsections which follow describe this behavior in
       further detail.

   5.  Newer host implementations MUST issue NS(DAD)s for all of its
       acquired unicast addresses except when the host interface has
       DupAddrDetectTransmits variable set to zero.  Section 5.4 of RFC
       2462 [ADDRCONF] erroneously relaxes this requirement and suffers
       from a manual configuration problem as illustrated by the
       following example:

          Host1 uses EUI-64 to configure a Link Local Address (LLA)
          using MAC1 and manually configures a Global Unicast Address
          (GUA) that is equal to an address configured using EUI-64 and
          MAC2.  Host1 completes an NS(DAD) for both its LLA and GUA in
          compliance with RFC 2462 [ADDRCONF].  Then, Host2 uses EUI-64
          to configure both a LLA and a GUA using MAC2.  Host2 completes
          an NS(DAD) for the LLA and does not send an NS(DAD) for its
          GUA in compliance with RFC 2462 [ADDRCONF].  Now Host1 and



Singh & Beebee          Expires January 21, 2008                [Page 4]

Internet-Draft         ND Implementation Pitfalls              July 2007


          Host2 have the same GUA on the same link.

       Therefore, this exception in section 5.4 of RFC 2462 [ADDRCONF]
       SHOULD be ignored.  Note that draft-ietf-ipv6-rfc2462bis-08
       [ADDRCONFbis] refers to an extensibility concern with new
       implementations and states in section 5.4:

          "Whereas this document does not invalidate such
          implementations, this kind of 'optimization' is NOT
          RECOMMENDED, and new implementations MUST NOT do that
          optimization."

       The "Changes to draft-ietf-ipv6-rfc2462bis-08" section in this
       document describes the corresponding changes to
       draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis].

   6.  The host SHOULD issue only a single NS(DAD) for each address.
       The default value for DupAddrDetectTransmits variable is
       specified as one in section 5.1 of RFC 2462 [ADDRCONF].  Note,
       however, that link-specific documents can modify this default.
       For instance, PPP specifies DupAddrDetectTransmits to be zero in
       RFC 2472 [PPPv6].

   7.  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.  Since the host cannot assume the destination is on-link, and
           off-link traffic cannot be sent to the default router (since
           the Default Router List is empty), address resolution has
           failed.  As specified in the last paragraph of section 7.2.2
           of draft-ietf-ipv6-rfc2461bis-11 [NDbis], when address
           resolution fails, the host SHOULD send an ICMPv6 Destination
           Unreachable message.

       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



Singh & Beebee          Expires January 21, 2008                [Page 5]

Internet-Draft         ND Implementation Pitfalls              July 2007


       [I.D.ietf-v6ops-onlinkassumptions] provides justification for
       these rules.

   The type of RA received can further determine host behavior.

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

   Section 3.1 of RFC 2461 [ND] 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."

   An IPv6 router sends an RA with no prefix advertised and the M bit
   set, does not send any Redirects, nor any NA or ND messages for non-
   link local addresses.  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.  In this case, 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.

   In the presence of Redirects, only the on-link behavior of the
   destination addresses of the original packets for which the Redirects
   were sent change from what is specified in the rules above.  These
   destination addresses are considered to be on-link and the host MAY
   now send non-link-local traffic destined to the destination addresses
   directly without sending it first to the default router.  Since the
   Redirect contains all the information necessary to resolve the
   address of the destination host, the source host MUST NOT issue an NS
   to resolve a destination other than a link-local address.






Singh & Beebee          Expires January 21, 2008                [Page 6]

Internet-Draft         ND Implementation Pitfalls              July 2007


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

   Security consequences of RFC 2461 [ND] imply that hosts MAY send all
   traffic to the default router without performing address resolution
   first even when a PIO has been received advertising an on-link
   prefix, regardless of whether the host performs DHCPv6 and/or
   stateless autoconfiguration.

   Section 4.6.2 of RFC 2461 [ND] defines the Valid Lifetime in the PIO
   as:

      "The length of time in seconds (relative to the time the packet is
      sent) that the prefix is valid for the purpose of on-link
      determination."

   Section 11 of RFC 2461 [ND] mentions the following denial of service
   attack:

      "An example of denial of service attacks is that a node on the
      link that can send packets with an arbitrary IP source address can
      both advertise itself as a default router and also send 'forged'
      Router Advertisement messages that immediately time out all other
      default routers as well as all on-link prefixes."

   The same security risk is also described in section 5.5.3 of RFC 2462
   [ADDRCONF].  This section allows hosts to ignore the Valid Lifetime
   stored in an RA in order to prevent denial of service attacks.

   Section 6.3.4 of RFC 2461 [ND] mentions that hosts MAY send all
   traffic to the default router without performing address resolution
   first:

      "Stateless address autoconfiguration RFC 2462 [ADDRCONF] may in
      some circumstances increase the Valid Lifetime of a prefix or
      ignore it completely in order to prevent a particular denial of
      service attack.  However, since the effect of the same denial of
      service targeted at the on-link prefix list is not catastrophic
      (hosts would send packets to a default router and receive a
      Redirect rather than sending packets directly to a neighbor) the
      Neighbor Discovery protocol does not impose such a check on the
      prefix lifetime values."

   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.



Singh & Beebee          Expires January 21, 2008                [Page 7]

Internet-Draft         ND Implementation Pitfalls              July 2007


   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.

2.2.1.  When the Valid Lifetime Expires

   In the absence of other sources of on-link information, including
   Redirects, 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 with the
   on-link bit set and an expired Valid Lifetime:

   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.

   In the presence of Redirects, only the on-link behavior of the
   destination addresses of the original packets for which the Redirects
   were sent change from what is specified in the rules above.  These
   destination addresses are considered to be on-link and the host MAY
   now send non-link-local traffic destined to the destination addresses
   directly without sending it first to the default router.  Since the
   Redirect contains all the information necessary to resolve the
   address of the destination host, the source host MUST NOT issue an NS
   to resolve a destination other than a link-local address.

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




Singh & Beebee          Expires January 21, 2008                [Page 8]

Internet-Draft         ND Implementation Pitfalls              July 2007


3.  Router Models

   The Redirect Clarifications section clarifies RFC 2461 [ND] host and
   router behavior for an aggregation router deployment.

   The Aggregation Router Deployment Model section presents a possible
   aggregation router deployment model for IPv6 and discusses its
   properties with respect to ND.  Aggregation routers can service more
   than 100,000 subscribers.  Due to scaling considerations, any NS for
   global address resolution from any host to any other host should not
   reach the aggregation router.

3.1.  Aggregation Router Deployment Model

   A property of routed aggregation networks is that hosts cannot
   directly communicate with each other even if they are on the same
   link.  This design is motivated by scaling and security
   considerations.  If every host could receive all traffic from every
   other host, then the subscriber's privacy would be violated and the
   amount of bandwidth available for each subscriber would be very
   small.  That is why hosts communicate between each other through the
   aggregation router, which is also the IPv6 first-hop router.

   For scaling reasons, any NS to resolve any address other than that of
   the default router should not reach the aggregation router.


                           +-----+
                           |     |
                           |Aggre+----(Rtr CPE)----Host1
            Core----WAN----+gator|
                           | Rtr |
                           |     +----(Br CPE)----(Cust Rtr)----Host2
                           +-----+

                                 Figure 1.

   In the figure above, the customer premises equipment (CPE) is managed
   by the ISP and is deployed behind an aggregation router that is an
   IPv6 first-hop router and also a DHCPv6 relay agent.  IPv6 CPEs are
   either IPv6 routers (Rtr CPE) or IPv6 bridges (Br CPE).  If the
   customer premises uses a bridge CPE, then a router (Cust Rtr) is
   needed.  All hosts reside behind a router CPE or a customer router.

   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



Singh & Beebee          Expires January 21, 2008                [Page 9]

Internet-Draft         ND Implementation Pitfalls              July 2007


   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.


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.
   Since the Redirect contains all the information necessary to resolve
   the address of the destination host, the source host MUST NOT issue
   an NS to resolve the destination contained within the Redirect.


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

   Proposed changes to draft-ietf-ipv6-rfc2461bis-11 [NDbis] follow:

   o  The following paragraph from section 3.1 of
      draft-ietf-ipv6-rfc2461bis-11 [NDbis] describes intended behavior
      when a host receives an RA without an advertised prefix and needs
      to add a reference to section 6.3.4 where the case is described in
      more detail:

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

      to add the following sentence at the end of the paragraph:

         See Section 6.3.4 of this document for more details when no
         prefix is advertised in the Router Advertisement.

   o  Section 2.1 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should
      include the following sentence in the on-link definition:

         Manual configuration of a host introduces its own set of
         security considerations and is beyond the scope of this on-link
         definition.





Singh & Beebee          Expires January 21, 2008               [Page 10]

Internet-Draft         ND Implementation Pitfalls              July 2007


   o  Section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should
      include the following paragraph (after the first paragraph):

         The on-link definition in section 2.1 describes the only means
         for on-link determination.  DHCPv6 or any other configuration
         on the host MUST NOT be used for on-link determination.

   o  Section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should
      include the following paragraph (before the PIO on-link
      paragraph):

         Without advertised prefixes, manual configuration, Redirects,
         or on-link information from Neighbor Advertisements or other
         Neighbor Discovery Messages, 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.  Additional on-
         link information can only indicate that certain specific
         prefixes or addresses are on-link, and does not change this
         off-link default.

   o  At the end of the PIO on-link paragraph of section 6.3.4, the
      following text should be added:

         If the RA advertises a prefix with the on-link bit set, the
         host MAY ignore the on-link indication from the RA and treat
         the prefix as off-link.  If the host decides to send all
         traffic (including on-link traffic) to the default router, then
         the host MUST NOT issue an NS to resolve a destination other
         than a link-local address.

         In the absence of other sources of on-link information,
         including Redirects, 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 with the on-link bit set and an expired Valid
         Lifetime:

         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.

         In the presence of Redirects, only the on-link behavior of the
         destination addresses of the original packets for which the
         Redirects were sent change from what is specified in the rules
         above.  These destination addresses are considered to be on-



Singh & Beebee          Expires January 21, 2008               [Page 11]

Internet-Draft         ND Implementation Pitfalls              July 2007


         link and the host MAY now send non-link-local traffic destined
         to the destination addresses directly without sending it first
         to the default router.  Since the Redirect contains all the
         information necessary to resolve the address of the destination
         host, the source host MUST NOT issue an NS to resolve a
         destination other than a link-local address.

   o  Section 6.3.2 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should
      include the following variable at the end of section.  We have
      brought this variable from section 5.1 in
      draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] to
      draft-ietf-ipv6-rfc2461bis-11 [NDbis] so that implementers are
      aware that the default value of this variable is 1.

      DupAddrDetectTransmits  The number of consecutive Neighbor
              Solicitation messages sent while performing Duplicate
              Address Detection on a tentative address.  The default
              value of this variable is 1.

   o  Section 6.3.4 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should
      include the following paragraph (after the paragraph that begins
      with "For each Prefix Information option with the on-link flag
      set, a host does the following:"):

         The host MUST NOT add a directly connected route to the prefix
         from an assigned address, independent of the information about
         the prefix received from the sources described in section 2.1.
         This behavior can lead to incorrectly adding a prefix to the
         Prefix List and incorrect on-link determination by the host.

   o  Section 5.2 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should add
      the following paragraph (after the second paragraph):

         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.  Since the host cannot assume the destination is on-link,
             and off-link traffic cannot be sent to the default router



Singh & Beebee          Expires January 21, 2008               [Page 12]

Internet-Draft         ND Implementation Pitfalls              July 2007


             (since the Default Router List is empty), address
             resolution has failed.  As specified in the last paragraph
             of section 7.2.2 of draft-ietf-ipv6-rfc2461bis-11 [NDbis],
             when address resolution fails, the host SHOULD send an
             ICMPv6 Destination Unreachable message.

         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.

   o  Section 4.5 of draft-ietf-ipv6-rfc2461bis-11 [NDbis] should have
      the following text added (in the first paragraph after the
      sentence "Routers send Redirect packets to inform...":

         Since the Redirect contains all the information necessary to
         resolve the address of the destination host, the source host
         MUST NOT issue an NS to resolve the destination contained
         within the Redirect.

   o  A new section titled On-link and Off-link Decision Rules needs to
      be added to draft-ietf-ipv6-rfc2461bis-11 [NDbis] as an Appendix
      or as a section below section 6.3.4 of
      draft-ietf-ipv6-rfc2461bis-11 [NDbis].

         This section clarifies both on-link and off-link determination
         through providing a complete set of rules that decides in all
         cases whether an address is on or off-link.

         1.  In the absence of other sources of on-link information,
             including Redirects, if the RA advertises a prefix with the
             on-link(L) bit set and the Valid Lifetime expires, the host
             MUST then consider the prefix to be off-link.  However, if
             the RA advertises a prefix with the on-link bit set, the
             host MAY ignore the on-link indication from the RA and
             treat the prefix as off-link.

         2.  If an IPv6 router sends an RA with no prefix advertised and
             the M bit set and does not send any Redirects, the host
             assumes destinations with non-link-local traffic are off-
             link.

         3.  On-link determination and addresses acquired using DHCPv6
             SHOULD NOT persist across IPv6 interface initializations.
             Note that stable storage can be used for addresses acquired



Singh & Beebee          Expires January 21, 2008               [Page 13]

Internet-Draft         ND Implementation Pitfalls              July 2007


             with stateless address autoconfiguration.  However, the
             Preferred and Valid Lifetimes must be retained if this
             approach is used.

         4.  A prefix is on-link if it is covered by one of the link's
             prefixes, specified as the target of a Redirect message, or
             a Neighbor Advertisement or any Neighbor Discovery message
             is received for the address.  No other information can be
             used for on-link determination.  DHCPv6 or any other
             configuration on the host MUST NOT be used for off-link
             determination.  Manual configuration of a host introduces
             its own complications for on-link determination and is
             beyond the scope of this section.

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

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

                Since the host cannot assume the destination is on-link,
                and off-link traffic cannot be sent to the default
                router (since the Default Router List is empty), address
                resolution has failed.  When address resolution fails,
                the host SHOULD send an ICMPv6 Destination Unreachable
                message.

                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.


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

   Proposed changes to draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis]
   follow:

   o  The following paragraph from section 5.4 of
      draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] needs to change:

         "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



Singh & Beebee          Expires January 21, 2008               [Page 14]

Internet-Draft         ND Implementation Pitfalls              July 2007


         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 actually not 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].  Requiring to perform
         Duplicate Address Detection for all unicast addresses will make
         the algorithm robust for the current and future such special
         interface identifiers."

      to read as follows:

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

   o  Section 5.5.3 of draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] has
      the following paragraph:

         "Note that a future revision of the address architecture 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."




Singh & Beebee          Expires January 21, 2008               [Page 15]

Internet-Draft         ND Implementation Pitfalls              July 2007


      The "should not" should be replaced with "SHOULD NOT" and also the
      "should" should be replaced with "SHOULD".

   o  Section 5.7 of draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] should
      have the following sentence added (at the end of the first
      paragraph):

         On-link determination and addresses acquired using DHCPv6
         SHOULD NOT persist across IPv6 interface initializations.


7.  Known IPv6 ND Implementation Problems

   This section catalogs a number of known IPv6 ND implementation
   problems.  The goal in doing so is to enhance the quality of current
   IPv6 ND implementations, and motivate the models presented in
   previous sections of this document.  It is hoped that this will
   provide greater interoperability between IPv6 ND implementations.
   Each problem description is modelled after the problem description
   format from section 1 of RFC 2525 [TCPProb].

7.1.  Incorrect host data forwarding behavior after receiving an RA with
      no PIO

   Name of problem  Incorrect host data forwarding behavior after
           receiving an RA with no PIO.




   Classification  Potential network connectivity loss.




   Description  An IPv6 host has received an RA with M bit set and no
           PIO.  Since no on-link information was provided, the host has
           to assume all non-link-local destinations are off-link and
           send all non-link-local traffic to the default router and
           allow the router to issue any Redirects if necessary.  The
           host completes DHCPv6 and then, when the host is asked to
           ping an address, the host issues an NS to resolve the ping
           destination address instead of forwarding the ping packet to
           the default router.







Singh & Beebee          Expires January 21, 2008               [Page 16]

Internet-Draft         ND Implementation Pitfalls              July 2007





   Significance  An IPv6 default router for this source host and the
           destination host may not respond to the address resolution NS
           sent out by the source host when asked to ping a destination,
           and the source host may lose IPv6 network connectivity as a
           result.




   Implications  If the router and the destination host do not respond
           to the NS, the host layer 2 driver will hold the IPv6 packet,
           resulting in lack of IPv6 connectivity as per section 4.2.5
           of RFC 3756 [SEND].




   Relevant RFCs  draft-ietf-ipv6-2461bis-11 [NDbis] describes correct
           host behavior for this scenario.  RFC 3756 [SEND] describes
           host behavior during address resolution.




   Trace file demonstrating it  A packet capture showing RA with no PIO
           and NS from host.

No.     Time        Source                Destination
     19 11.614198   fe80::203:adff:fe47:f1c6 ff02::1
Protocol Info
ICMPv6   Router advertisement

Frame 19 (86 bytes on wire, 86 bytes captured)
    Arrival Time: May 11, 2007 12:09:03.400545000
    [Time delta from previous captured frame: 2.000110000 seconds]
    [Time delta from previous displayed frame: 2.000110000 seconds]
    [Time since reference or first frame: 11.614198000 seconds]
    Frame Number: 19
    Frame Length: 86 bytes
    Capture Length: 86 bytes
    [Frame is marked: True]
    [Protocols in frame: eth:ipv6:icmpv6]
    [Coloring Rule Name: Broadcast]
    [Coloring Rule String: eth[0] & 1]
Ethernet II, Src: EmersonE_47:f1:c6 (00:03:ad:47:f1:c6),



Singh & Beebee          Expires January 21, 2008               [Page 17]

Internet-Draft         ND Implementation Pitfalls              July 2007


            Dst: IPv6-Neighbor-Discovery_00:00:00:01 (33:33:00:00:00:01)
    Destination: IPv6-Neighbor-Discovery_00:00:00:01 (33:33:00:00:00:01)
        Address: IPv6-Neighbor-Discovery_00:00:00:01 (33:33:00:00:00:01)
        .... ...1 .... .... .... .... = IG bit: Group address
                                                (multicast/broadcast)
        .... ..1. .... .... .... .... = LG bit: Locally administered
                               address (this is NOT the factory default)
    Source: EmersonE_47:f1:c6 (00:03:ad:47:f1:c6)
        Address: EmersonE_47:f1:c6 (00:03:ad:47:f1:c6)
        .... ...0 .... .... .... .... = IG bit: Individual address
                                                (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
                                                (factory default)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6
    0110 .... = Version: 6
    .... 1110 0000 .... .... .... .... .... = Traffic class: 0x000000e0
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 32
    Next header: ICMPv6 (0x3a)
    Hop limit: 255
    Source: fe80::203:adff:fe47:f1c6 (fe80::203:adff:fe47:f1c6)
    Destination: ff02::1 (ff02::1)
Internet Control Message Protocol v6
    Type: 134 (Router advertisement)
    Code: 0
    Checksum: 0xe956 [correct]
    Cur hop limit: 64
    Flags: 0xc0
        1... .... = Managed
        .1.. .... = Other
        ..0. .... = Not Home Agent
        ...0 0... = Router preference: Medium
    Router lifetime: 1800
    Reachable time: 0
    Retrans timer: 0
    ICMPv6 Option (Source link-layer address)
        Type: Source link-layer address (1)
        Length: 8
        Link-layer address: 00:03:ad:47:f1:c6
    ICMPv6 Option (MTU)
        Type: MTU (5)
        Length: 8
        MTU: 1500

No.     Time        Source
     22 15.721935   2001:420:3800:809:a98b:2df5:f45b:1cc2
Destination           Protocol Info



Singh & Beebee          Expires January 21, 2008               [Page 18]

Internet-Draft         ND Implementation Pitfalls              July 2007


ff02::1:ff7f:d18d     ICMPv6   Neighbor solicitation

Frame 22 (86 bytes on wire, 86 bytes captured)
    Arrival Time: May 11, 2007 12:09:07.508282000
    [Time delta from previous captured frame: 0.107631000 seconds]
    [Time delta from previous displayed frame: 0.107631000 seconds]
    [Time since reference or first frame: 15.721935000 seconds]
    Frame Number: 22
    Frame Length: 86 bytes
    Capture Length: 86 bytes
    [Frame is marked: True]
    [Protocols in frame: eth:ipv6:icmpv6]
    [Coloring Rule Name: Broadcast]
    [Coloring Rule String: eth[0] & 1]
Ethernet II, Src: AmbitMic_b5:aa:3a (00:d0:59:b5:aa:3a),
            Dst: IPv6-Neighbor-Discovery_ff:7f:d1:8d (33:33:ff:7f:d1:8d)
    Destination: IPv6-Neighbor-Discovery_ff:7f:d1:8d (33:33:ff:7f:d1:8d)
        Address: IPv6-Neighbor-Discovery_ff:7f:d1:8d (33:33:ff:7f:d1:8d)
        .... ...1 .... .... .... .... = IG bit: Group address
                                                (multicast/broadcast)
        .... ..1. .... .... .... .... = LG bit: Locally administered
                               address (this is NOT the factory default)
    Source: AmbitMic_b5:aa:3a (00:d0:59:b5:aa:3a)
        Address: AmbitMic_b5:aa:3a (00:d0:59:b5:aa:3a)
        .... ...0 .... .... .... .... = IG bit: Individual
                                                address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique
                                               address (factory default)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 32
    Next header: ICMPv6 (0x3a)
    Hop limit: 255
    Source: 2001:420:3800:809:a98b:2df5:f45b:1cc2
            (2001:420:3800:809:a98b:2df5:f45b:1cc2)
    Destination: ff02::1:ff7f:d18d (ff02::1:ff7f:d18d)
Internet Control Message Protocol v6
    Type: 135 (Neighbor solicitation)
    Code: 0
    Checksum: 0xa900 [correct]
    Target: 2001:420:3800:809:4cb9:d617:547f:d18d
    ICMPv6 Option (Source link-layer address)
        Type: Source link-layer address (1)
        Length: 8
        Link-layer address: 00:d0:59:b5:aa:3a



Singh & Beebee          Expires January 21, 2008               [Page 19]

Internet-Draft         ND Implementation Pitfalls              July 2007


Followed by multiple NS's like frame 22, but no ICMPv6 echo from
the IPv6 host.

                                 Figure 2.




   How to detect  On the host, the ping may fail.  With a packet capture
           tool, one can observe the NS sent by the host where the
           target address in the NS matches the ping destination.  The
           packet capture also demonstrates that no ping packet has been
           sent from the host.




   How to fix  The host should assume all non-link-local destinations to
           be off-link, and send non-link-local traffic to the default
           router.

7.2.  A DHCPv6 host sending excessive NS(DAD)s

   Name of problem  A DHCPv6 host sending excessive NS(DAD)s.




   Classification  Congestion control.




   Description  An IPv6 host was asked by the aggregation router to
           perform DHCPv6 (through setting the M bit in the RA).  During
           the course of Link-local DAD and DHCPv6 DAD, the host sent 4
           DADs for its link-local address and five DADs for its DHCPv6
           acquired address.  In an aggregation router deployment,
           especially during an aggregation router reload, when more
           than 100,000 hosts can register with the aggregation router,
           sending nine DADs can congest the upstreams.  In some
           aggregator deployments where upstream bandwidth is much less
           than downstream bandwidth, sending nine DADs for every host
           during host registration would waste upstream bandwidth and
           decrease the registration rate.  This host behavior is
           compliant with the ND protocol and DAD, however, for an
           aggregator deployment with limited upstream bandwidth this
           behavior is not desirable.  Also, link-type specific



Singh & Beebee          Expires January 21, 2008               [Page 20]

Internet-Draft         ND Implementation Pitfalls              July 2007


           standards for aggregator networks should define the number of
           DADs to be sent by hosts serviced by the aggregation router.




   Significance  Performance of an aggregation router suffers when hosts
           register in a congested aggregator deployment where upstream
           bandwidth is limited.




   Implications  This behavior decreases the registration rate of all
           hosts on the aggregator.  VoIP could be deployed with such
           hosts and slower host registration can delay or prevent VoIP
           call recovery after an unexpected aggregation router reload.




   Relevant RFCs  The default value for DupAddrDetectTransmits variable
           is specified as one in section 5.1 of RFC 2462 [ADDRCONF].
           RFC 2462 [ADDRCONF] also mentions defining a different value
           of DupAddrDetectTransmits for a specific link-type.




   Trace file demonstrating it  ND message debugging should be enabled
           on the aggregation router.  This debug log shows the nine
           DAD's from a host during the time the host registers with the
           aggregation router.  Alternatively, a packet capture tool
           could have been used to capture DAD messages between the host
           and the aggregation router.
















Singh & Beebee          Expires January 21, 2008               [Page 21]

Internet-Draft         ND Implementation Pitfalls              July 2007


<rtr-prompt>show monitor event-trace ipv6 nd all | i FE80::211:E6FF:FEF4:3A5
Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on <router interface>
Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on <router interface>
Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on <router interface>
Rx NS from :: to FE80::211:E6FF:FEF4:3A5 on <router interface>
Entry FE80::211:E6FF:FEF4:3A5 <router interface> State DELETE -> INCMP
Tx NS to FE80::211:E6FF:FEF4:3A5 on <router interface>
Rx NA from FE80::211:E6FF:FEF4:3A5 to FE80::211:E6FF:FEF4:3A5 on
Entry FE80::211:E6FF:FEF4:3A5 <router interface> State INCMP -> REACH
Rx NS from FE80::211:E6FF:FEF4:3A5 to FE80::20F:86FF:FECF:B270 on
Rx NA from FE80::211:E6FF:FEF4:3A5 to 2001:420:3800:809:594C:3B39:
Entry FE80::211:E6FF:FEF4:3A5 <router interface> State REACH -> STALE
<rtr-prompt>
<rtr-prompt>trace ipv6 nd all | i 2001:420:3800:809:594C:3B39:A263:3BB5
Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Rx NS from :: to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Entry 2001:420:3800:809:594C:3B39:A263:3BB5 <router interface> State DELETE
Tx NS to 2001:420:3800:809:594C:3B39:A263:3BB5 on <router interface>
Entry 2001:420:3800:809:594C:3B39:A263:3BB5 <router interface> State INCMP
Entry 2001:420:3800:809:594C:3B39:A263:3BB5 <router interface> State REACH
<rtr-prompt>

                                 Figure 3.




   How to detect  Enable ND message debugging on the aggregation router
           and capture DADs from the host or use a packet capture tool
           between the aggregation router and the host to capture DAD
           messages.




   How to fix  A new link-type document for aggregator deployment should
           define a new value for DupAddrDetectTransmits.
           Alternatively, the default of one specified in section 5.1 of
           RFC 2462 [ADDRCONF] should be used.

7.3.  Incorrect host behavior after automatic insertion of a directly
      connected route during address acquisition






Singh & Beebee          Expires January 21, 2008               [Page 22]

Internet-Draft         ND Implementation Pitfalls              July 2007


   Name of problem  Incorrect host behavior after automatic insertion of
           a directly connected route during address acquisition.




   Classification  Reliability.




   Description  The router sends an RA with M bit set, and no PIO.
           After address acquisition, a host incorrectly adds a directly
           connected route to the host's forwarding tables using an
           invented prefix (assuming a default prefix length) that is
           partially derived from the acquired address.  This host
           behavior does not follow on-link determination rules, and is
           independent of possible on-link information sent in the RA.
           This behavior causes the host to add an entry to the Prefix
           List of the host inappropriately.  The host MUST NOT add a
           directly connected route to the prefix from an assigned
           address, independent of the information about the prefix
           received from the sources described in section 2.1 of
           draft-ietf-ipv6-2461bis-11 [NDbis].




   Significance  Host may not be able to send IPv6 traffic.




   Implications  After a host inappropriately adds a prefix to the
           Prefix List, when the host attempts to send a data packet
           with a destination which matches the Prefix List entry, the
           host will incorrectly assume the destination is on-link and
           it will issue an NS to resolve the destination.  A router and
           the destination host may not respond to this NS and the host
           may not send the data packet.




   Relevant RFCs  This document describes correct host behavior for this
           scenario.





Singh & Beebee          Expires January 21, 2008               [Page 23]

Internet-Draft         ND Implementation Pitfalls              July 2007





   Host data forwarding table shows problem  A CLI that is available on
           the host to lookup the data routing/forwarding table
           demonstrates that the host added the route.

<prompt><interface configuration command>

Client IP Configuration


Ethernet adapter Local Area Connection:

   IPv6 Address. . . . . . . . . . . :
                                    2001:420:3800:809:38d5:bb15:291c:1e4a
   Link-local IPv6 Address . . . . . : fe80::5cc5:6c11:1f71:5ecd%9
   Default Gateway . . . . . . . . . : fe80::203:afff:fed3:52c6%9

<prompt><print routing table command>

IPv6 Route Table
=========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  9    286 ::/0                     fe80::203:afff:fed3:52c6
  1    306 ::1/128                  On-link
  9    286 2001:420:3800:809::/64   On-link <---- Automatically added /64
  9    286 2001:420:3800:809:38d5:bb15:291c:1e4a/128
                                    On-link
  9    286 fe80::/64                On-link
  9    286 fe80::5cc5:6c11:1f71:5ecd/128
                                    On-link
  1    306 ff00::/8                 On-link
  9    286 ff00::/8                 On-link
=========================================================================
Persistent Routes:
  None

<prompt>

                                 Figure 4.









Singh & Beebee          Expires January 21, 2008               [Page 24]

Internet-Draft         ND Implementation Pitfalls              July 2007


   How to detect  Inspect the host's routing/forwarding tables after
           host address acquistion completes.




   How to fix  The host MUST follow the rules defined in this document.

7.4.  Aggregation router sending Redirects when hosts communicate to
      each other from behind different modems

   Name of problem  Aggregation router sending Redirects when hosts
           communicate to each other from behind different modems.




   Classification  Reliability.




   Description  Due to scability and security concerns, hosts behind
           different modems in an aggregation network cannot communicate
           directly with each other.  If this aggregation router issues
           a Redirect to any pair of hosts behind different modems that
           are on the same link of this router, the aggregation router
           falsely indicates to the hosts that they can talk directly to
           each other.  In this aggregation network, a pair of hosts
           behind different modems on the same link can only communicate
           with each other by sending their traffic to the aggregation
           router.




   Significance  The aggregation router is providing incorrect
           information to the host that the host can communicate
           directly to another host when the pair of hosts can only
           communicate with each other via the aggregation router.




   Implications  There are two hosts behind different modems on the same
           link of an aggregation router.  If a ping is issued from one
           host to the other and the aggregation router sends a Redirect
           to one of the hosts, the host receiving the Redirect may



Singh & Beebee          Expires January 21, 2008               [Page 25]

Internet-Draft         ND Implementation Pitfalls              July 2007


           attempt direct communication with the other host, and fail.




   Relevant RFCs  This document describes correct host behavior for this
           scenario.




   Trace file demonstrating it  A packet capture tool can demonstrate
           that Redirects are being issued by the router.
           Alternatively, debug commands on the aggregation router can
           demonstrate that the router is sending Redirects, as shown
           below.

ICMPv6: Sending REDIRECT for 2001:420:3800:809:4EF:E3B1:1569:27B5,
        target 2001:420:3800:809:4EF:E3B1:1569:27B5 on <router interface>
ICMPv6: Sending REDIRECT for 2001:420:3800:809:65E8:C4A9:8828:F5BC,
        target 2001:420:3800:809:65E8:C4A9:8828:F5BC on <router interface>

                                 Figure 5.




   How to detect  During the ping, one can use a network capture of
           Redirects being issued by the router, or debug output on the
           router.




   How to fix  The aggregation router MUST block sending any Redirects
           to hosts behind different modems.


8.  Security Considerations

   The Host Models section of this document describes valid host
   behavior in response to a security threat where a rogue node can send
   RAs with a Valid Lifetime of zero.  Host Models also describes a
   problem with section 5.4 of RFC 2462 [ADDRCONF] that can allow two
   hosts with the same address to avoid DAD and come online on the same
   link.





Singh & Beebee          Expires January 21, 2008               [Page 26]

Internet-Draft         ND Implementation Pitfalls              July 2007


9.  IANA Considerations

   None.


10.  Acknowledgements

   Thanks (in alphabetical order) to Adeel Ahmed, Ralph Droms, Alun
   Evans, Dave Forster, Prashanth Krishnamurthy, Josh Littlefield, Madhu
   Sudan, Bernie Volz, and Vlad Yasevich for their consistent input,
   ideas and review during the production of this document.


11.  References

11.1.  Normative References

   [ADDRCONF]
              Thomson, S. and T. Narten, "IPv6 Address autoconfiguration
              (IPv6)", RFC 2462, December 1998.

   [ND]       Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [PPPv6]    Haskin, D. and E. Allen, "IP Version 6 over PPP",
              RFC 2472, December 1998.

11.2.  Informative References

   [ADDRCONFbis]
              Thomson, S., Narten, T., and T. Jinmei, "IPv6 Address
              autoconfiguration (IPv6)",
              draft-ietf-ipv6-rfc2462bis-08 (Work In Progress),
              May 2005.

   [I.D.ietf-v6ops-onlinkassumptions]
              Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor
              Discovery On-Link Assumption Considered Harmful (IPv6)",
              draft-ietf-v6ops-onlinkassumption-04 (Work In Progress),
              January 2007.

   [NDbis]    Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP Version 6 (IPv6)",
              draft-ietf-ipv6-2461bis-11 (Work In Progress), March 2007.

   [SEND]     Nikander, Ed., P., Kempf, J., and E. Nordmark, "IPv6
              Neighbor Discovery (ND) Trust Models and Threats",



Singh & Beebee          Expires January 21, 2008               [Page 27]

Internet-Draft         ND Implementation Pitfalls              July 2007


              RFC 3756, May 2004.

   [TCPProb]  Paxon, V., Allman, M., Dawson, S., Fenner, W., Griner, J.,
              Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known TCP
              Implementation Problems (IPv6)", RFC 2525, March 1999.


Appendix A.  CHANGE HISTORY

   [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION UPON PUBLICATION.]

   Changes in draft-wbeebee-nd-implementation-pitfalls-01.txt since
   -00.txt are:

   o  Removed the word "corrections" from the abstract when referring to
      the proposed changes for the two drafts.

   o  Added to the abstract declaration of intent for this document.

   o  Corrected the introduction to say "the host must send all non-
      link-local data to the default router" instead of the incorrect
      "the host must send all data to the router", which is implied by
      the specification, but not explicitly stated.

   o  Added the proposed changes to 2461bis section and appropriate
      reference in the introduction.

   o  Changed "the host MUST issue NS(DAD)s" to "newer host
      implementations MUST issue NS(DAD)s" to match the current state of
      2462bis.

   o  Changed "security problem" to "manual configuration problem" to
      emphasize that manual configuration of a compliant host combined
      with the NS(DAD) optimization of a compliant host can cause
      problems.

   o  Changed recommendation that the exception in section of 5.4 MUST
      be ignored to SHOULD be ignored.

   o  Removed sentence which invalidates existing implementations.

   o  Changed "the host MUST send all traffic to the default router" to
      "the host MUST send all non-link-local traffic to the default
      router".

   o  Changed "the host MUST NOT issue an NS to resolve a destination
      other than the Link-Local address of the default router" to "the
      host MUST NOT issue an NS to resolve a destination other than a



Singh & Beebee          Expires January 21, 2008               [Page 28]

Internet-Draft         ND Implementation Pitfalls              July 2007


      link-local address".

   o  Removed MUST NOT and MAY language with respect to Redirects used
      in the aggregation router model, as these are properties of a
      correct implementation rather than normative requirements.  Note
      that a clause was added that states that a router can send a
      Redirect "if the router can make a determination that the two
      hosts lie behind the same bridge CPE".

   o  Changed the 2462bis changes section to reflect that existing
      implementations are not required to change, but may suffer from
      the manual configuration problem described in this draft.

   o  Added Josh Littlefield to the Acknowledgements section to
      recognize his extremely insightful and useful comments on this
      draft.

   Changes in draft-wbeebee-nd-implementation-pitfalls-02.txt since
   -01.txt are:

   o  Added a new sentence to the abstract and changed the third
      paragraph of the Introduction to include references to the new
      Known IPv6 ND Implementation Problems section.

   o  Reworded second paragraph of Introduction.

   o  The requirement listed in the first bullet in Host Models section
      changed from MUST NOT to sHOULD NOT.  To clarify this change, some
      more text related to DHCPv6 and Valid LifeTimes has been added to
      this bullet.

   o  Bullet 2 of Host Models section includes a stricter definition of
      on-link.  Also new text was added to the bullet relating to manual
      configuration, which is not mentioned in the on-link definition in
      the Terminology section of RFC 2461 [ND].

   o  The new bullet 4 was inserted in the Host Models section, which
      relates to off-link determination.

   o  The new bullet 6 has added details.

   o  The new bullet 7 was revamped with stricter terminology.

   o  The second paragraph of section 2.1 has stricter terminology.

   o  A new paragraph was added to the end of section 2.1 relating to
      Redirects and the problem described in this section.




Singh & Beebee          Expires January 21, 2008               [Page 29]

Internet-Draft         ND Implementation Pitfalls              July 2007


   o  A new section, 2.2.1, was added to the document to describe rules
      for off-link determination.

   o  Section 2.3 was changed to fix mistakes in the earlier version of
      this section.

   o  SHOULD NOT in the second paragraph of Section 3 was changed to
      lower case to avoid normative language.

   o  SHOULD NOT in the second paragraph of Section 3.1 was changed to
      lower case to avoid normative language.

   o  In section 4 the word "need" was replaced by "necessary".

   o  Section 5 is now complete.  In the previous version of this
      document, the locations in draft-ietf-ipv6-2461bis-11 [NDbis]
      where text was to be modified or added were not yet identified.

   o  Section 6 has minor changes.  We reduced the number of changes to
      draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis] described in the
      paragraph.  Two new proposed changes have also been added to this
      section.

   o  Sections 5 and 6 now have improved formatting.

   o  A new section 7 titled "Know IPv6 ND Implementation Problems" was
      added to the document.  This section is modeled after RFC 2525
      [TCPProb].  Four known bugs were described in sub-sections of this
      section.

   o  Added Vlad Yasevich to the Acknowledgements section to recognize
      his extremely insightful and useful comments on this draft.  We
      also changed the list of names to be alphabetically listed via
      last names instead of first names.


Authors' Addresses

   Hemant Singh
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

   Phone: +1 978 936 1622
   Email: shemant@cisco.com
   URI:   http://www.cisco.com/




Singh & Beebee          Expires January 21, 2008               [Page 30]

Internet-Draft         ND Implementation Pitfalls              July 2007


   Wes Beebee
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

   Phone: +1 978 936 2030
   Email: wbeebee@cisco.com
   URI:   http://www.cisco.com/










































Singh & Beebee          Expires January 21, 2008               [Page 31]

Internet-Draft         ND Implementation Pitfalls              July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Singh & Beebee          Expires January 21, 2008               [Page 32]