Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery
draft-smith-6man-mitigate-nd-cache-dos-slnd-04

Internet Engineering Task Force                                 M. Smith
Internet-Draft                                                      IMOT
Updates: 4861 (if approved)                                      O. Ddin
Intended status: Standards Track            ZeroLag Communications, Inc.
Expires: April 21, 2013                                 October 18, 2012

   Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor
                               Discovery
             draft-smith-6man-mitigate-nd-cache-dos-slnd-04

Abstract

   The IPv6 neighbor discovery cache is vulnerable to a Denial of
   Service attack that purposely exhausts the state used during the
   neighbor discovery address resolution process described in RFC 4861.
   This attack can be very disruptive when the target is a router.  This
   memo updates RFC 4861 with a stateless form of neighbor discovery; it
   does not require any changes to hosts.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 16, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
 

Smith, Ddin              Expires April 21, 2013                 [Page 1]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1. Requirements Language . . . . . . . . . . . . . . . . . . .  3
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3. Stateless Neighbor Discovery  . . . . . . . . . . . . . . . . .  4
     3.1. SLND Variables  . . . . . . . . . . . . . . . . . . . . . .  4
     3.2. SLND Process  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3. Unhashed SLND . . . . . . . . . . . . . . . . . . . . . . .  6
     3.4. Hashed SLND . . . . . . . . . . . . . . . . . . . . . . . .  7
   4. Consequences of Stateless Neighbor Discovery  . . . . . . . . .  8
     4.1. Neighbor Advertisement Validation . . . . . . . . . . . . .  9
     4.2. Optimization Functions  . . . . . . . . . . . . . . . . . .  9
   5. Trusted/Untrusted Discriminator . . . . . . . . . . . . . . . . 10
     5.1. Configured Trusted and Untrusted Prefixes . . . . . . . . . 10
     5.2. Routing Information . . . . . . . . . . . . . . . . . . . . 10
     5.3. Default to Untrusted  . . . . . . . . . . . . . . . . . . . 11
     5.4. Neighbor Origin Flag (NOF) in relation to the TUD . . . . . 11
   6. Baseline Implementation . . . . . . . . . . . . . . . . . . . . 11
   7. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 12
   8. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
   9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
   10. Change Log [RFC Editor please remove]  . . . . . . . . . . . . 12
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

 

Smith, Ddin              Expires April 21, 2013                 [Page 2]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

1. Introduction

   The IPv6 neighbor discovery cache [RFC4861] is vulnerable to a Denial
   of Service attack that purposely exhausts the state used during the
   neighbor discovery address resolution process [RFC3756].

   When a router is the target of this attack, an off-link attacker
   sends traffic towards many non-existent addresses within a prefix
   attached to the router.  This causes the router to create neighbor
   cache state for neighbor solicitations for these non-existent
   addresses.  The denial of service occurs when the router's neighbor
   cache state capacity is exhausted due to too many outstanding
   neighbor solicitations.

   Sizing a prefix proportional to the number of attached hosts, rather
   than using the standard /64 prefix size [RFC4291], would mitigate
   this attack.  However, operational conveniences and benefits such as
   universal fixed length prefixes and interface identifiers, Stateless
   Address Auto configuration (SLAAC) [RFC4862] and privacy addresses
   [RFC4941], and never having to resize the prefix or add secondary
   prefixes to attach more hosts to the link would be lost.

   This memo proposes a stateless form of neighbor discovery to prevent
   this type of DoS attack on a router.  It does not require any changes
   to the operation of neighbor discovery on hosts. It optionally takes
   advantage of hosts' ability to recover from packet loss in the
   network, necessary due to IPv6's best effort nature.  This method can
   be used for unknown or untrusted packet sources, when the router's
   neighbor cache capacity reaches a medium to high threshold of use,
   suggesting a neighbor cache DoS attack is occurring.  Trusted packets
   would continue to be provided with traditional stateful neighbor
   discovery.

1.1. Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2. Terminology

   Stateful Neighbor Discovery (SFND): Traditional neighbor discovery,
   as specified in [RFC4861].  This form of neighbor discovery maintains
   per packet destination state for all unresolved destinations during
   the neighbor discovery process.  The neighbor cache's state capacity
   is intentionally exhausted to cause the neighbor cache Denial of
   Service attack.
 

Smith, Ddin              Expires April 21, 2013                 [Page 3]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

   Stateless Neighbor Discovery (SLND): The form of neighbor discovery
   described in this memo.  This form of neighbor discovery does not
   maintain state for unresolved destinations during the neighbor
   discovery process. SLND has two modes of operation: hashed and
   unhashed. Hashing refers to any computational function which digests
   input into a fixed-length, unique value.

3. Stateless Neighbor Discovery

3.1. SLND Variables

   To perform stateless neighbor discovery, the following variables are
   maintained:

   SLND Flag - This REQUIRED flag indicates whether or not the interface
   will perform SLND if necessary.

   SLND Activate Threshold - This REQUIRED variable specifies the
   threshold when stateless neighbor discovery is activated.  The
   threshold specifies a neighbor cache utilization level.  It is
   expressed as a percentage, with a RECOMMENDED default value of 80%. 
   It may be either a per-interface or router global variable depending
   on whether the router implementation has per-interface neighbor
   caches or a global neighbor cache used by all interfaces.

   SLND Active Flag - This REQUIRED flag indicates whether or not the
   interface is performing SLND for untrusted packet sources. It is
   maintained for each interface on the router. If Hashed SLND is
   implemented, it indicates the type of SLND in use.

   Trusted/Untrusted Discriminator (TUD) - This RECOMMENDED variable
   specifies an arbitrary discriminator that determines whether a
   datagram is considered trusted or untrusted for the purposes of
   neighbor discovery. a TUD implementation MUST provide for at least
   per-source and per-interface discrimination although this MAY be
   controlled externally such as by a packet mark/tag being the basis of
   the TUD and separate processes of the router providing the
   infrastructure to set the value; for example, a packet examination
   ruleset setting a particular mark/tag bit upon a match or lack
   thereof.

   SLND Neighbor Solicitation Rate Limit ("SLND NS Rate Limit") - This
   REQUIRED variable specifies a threshold for multicast Neighbor
   Solicitations when the interface is performing SLND, specified in
   packets per second. This limit MUST be configurable on a per-
   interface basis but a router MAY provide for configuring a default or
   global rate for convenience. OPTIONAL granular rate limiting may be
   achieved by maintaining a table of sources, grouped on a large
 

Smith, Ddin              Expires April 21, 2013                 [Page 4]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

   boundary (/48 or bigger) in order to achieve weighted rate limiting
   that has a bigger impact on an attacking subnet. If such granular
   rate limiting is implemented, a router MUST NOT exceed the total
   interface rate threshold.

   SLND Hash Salt (NDHS) - If implementing Hashed SLND, This is a
   REQUIRED value that SHOULD be at least 8 octets in length, known only
   to the router and MUST change periodically to mitigate replay
   attacks. This value SHOULD NOT change more often than the typical
   time taken for successful resolution and it is RECOMMENDED that this
   value change approximately as often as the configured ND timeout.

   Neighbor Origin Flag (NOF) - This RECOMMENDED value indicates whether
   the neighbor was learned through stateful or stateless discovery. a
   router MAY also indicate whether the stateless discovery was hashed
   or unhashed. Thus this flag may have values of STATEFUL, STATELESS
   and optionally HSTATELESS.

3.2. SLND Process

   The stateless neighbor discovery process may occur once a router has
   determined the outgoing interface for a packet, and that the packet's
   destination is on-link.

   If the packet's destination address is present in the neighbor cache,
   and the link-layer address has been resolved, the packet is forwarded
   to it's destination.

   If the packet's destination address is not present in the neighbor
   cache, and the SLND Flag is off, traditional stateful neighbor
   discovery is performed for the packet's destination.

   If the packet's destination address is not present in the neighbor
   cache, and the SLND Flag is on, the TUD is referred to in order to
   ascertain whether the packet is trusted or not.

   If the packet is determined to be trusted or a non-REACHABLE neighbor
   entry exists with an origin of STATEFUL, traditional stateful
   neighbor discovery is performed.

   If the packet is determined to be untrusted, stateless neighbor
   discovery is performed.

   A router MUST implement unhashed SLND and MAY also implement hashed
   SLND. Where both SLND modes are implemented, a router MUST allow mode
   selection on a per-interface basis. For on-link prefixes of size /64
   or more, defaulting to hashed SLND is RECOMMENDED.

 

Smith, Ddin              Expires April 21, 2013                 [Page 5]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

3.3. Unhashed SLND

   The unhashed stateless neighbor discovery process is as follows:

   1.  The router determines if sending a multicast neighbor
       solicitation would exceed the SLND NS Rate Limit for the outgoing
       interface.  If the SLND NS Rate Limit would be exceeded, drop the
       packet and do not proceed any further.

   2.  A multicast neighbor solicitation is sent by the router for the
       destination address in the packet. The packet MAY then be
       dropped. If the packet is instead requeued, any subsequent
       dequeue of the same packet MUST NOT result in the transmission of
       another solicitation whilst in SLND mode. the packet SHOULD NOT
       be queued indefinitely. if the packet expires, the router MAY
       send an ICMPv6 error to the source but given the likely scenario
       for the activation of SLND, this is not recommended.

   3.  As some later point in time, the router may receive a unicast
       neighbor advertisement, for a previously sent neighbor
       solicitation.

   4.  If the SLND Active Flag is off and there is no stateful entry
       regarding the advertisement, the router ignores the neighbor
       advertisement.

   5.  If the SLND Active Flag is on, the router creates an entry in
       it's neighbor cache using the information received in the unicast
       neighbor advertisement with an origin of STATELESS. Stateless
       neighbor discovery is now complete.

 

Smith, Ddin              Expires April 21, 2013                 [Page 6]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

3.4. Hashed SLND

   The hashed stateless neighbor discovery process is as follows:

   1.  The router determines if sending a multicast neighbor
       solicitation would exceed the SLND NS Rate Limit for the outgoing
       interface.  If the SLND NS Rate Limit would be exceeded, drop the
       packet and do not proceed any further.

   2.  The router performs hash function H(x) where x is the
       concatenation of the IPv6 address to solicit and the NDHS, known
       only to the router. the hash function SHOULD result in a value of
       at least 8 octets in length and subsequently be used to replace
       the lower 8 octets (host portion) of the IPv6 address that would
       have been the source of the solicitation. When applicable to the
       link medium, a router MUST include the ICMPv6 option detailed in
       Section 4.6.1 of RFC 4861 indicating the data-link layer source
       as part of the solicitation message.

   3.  As some later point in time, the router may receive a unicast
       neighbor advertisement, for a previously sent neighbor
       solicitation.

   4.  If the SLND Active Flag is off and there is no stateful entry
       regarding the advertisement, the router ignores the neighbor
       advertisement.

   5.  If the SLND Active Flag is on and a matching REACHABLE entry does
       not exist, the router performs hash function H(y) where y is the
       concatenation of the advertised IPv6 address and the NDHS. The
       result of H(x) is then compared to the lower 8 octets (host
       portion) of the IPv6 destination address in the advertisement. If
       the result does not match, the advertisement is discarded;
       otherwise the information in the advertisement is used to update
       the neighbor cache and assigned an origin of HSTATELESS.

   The utilization of the neighbor cache has to be measured to determine
   if it crosses the SLND Activate Threshold.  If the utilization
   increases above the SLND Activate Threshold, the SLND Active Flag is
   set, and if it decreases below the SLND Activate Threshold, the SLND
   Active Flag is unset.  Neighbor cache utilization should be measured
   and compared to the SLND Activate Threshold when:

   o  entries are added to the neighbor cache, during either stateful or
      stateless neighbor discovery.

   o  entries are removed from the neighbor cache when NUD discovers the
      neighbor has become unreachable or timed out.
 

Smith, Ddin              Expires April 21, 2013                 [Page 7]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

4. Consequences of Stateless Neighbor Discovery

   During traditional stateful neighbor discovery, state is used to
   perform the following:

   o  ensure a received neighbor advertisement corresponds to a
      previously sent neighbor solicitation

   o  to retransmit a limited number of neighbor solicitations if
      previous solicitations remain unanswered

   o  to store a small number of packets that triggered the neighbor
      discovery process, so that they can be transmitted if neighbor
      discovery completes successfully

   o  to generate an ICMPv6 destination unreachable, address unreachable
      messages back to the packet source, should the neighbor discovery
      process fail

   Unhashed stateless neighbor discovery sacrifices these functions and
   the related state to mitigate the neighbor cache DoS attack.

   Hashed stateless neighbor discovery retains much of the robustness of
   stateful ND at a cost of computation time for hash calculation,
   comparison and the minor risk of replay attacks although this is
   largely mitigated by appropriate tuning of the frequency by which the
   NDHS changes. However, per the behavior clarified in Section 3. of
   RFC 5942, the calculated source address will trigger a solicited host
   to create a neighbor entry for the source address, or in the unlikely
   event of the address already existing in the cache; cause the link-
   layer address to be updated. In either case, the entry will have an
   immediate state of STALE - thus not posing a problem in the unlikely
   event that the calculated IPv6 source is a duplicate address since
   the affected host will solicit the stale entry to determine its
   reachability.

   Routers implementing the NOF SHOULD evict STATELESS and then
   HSTATELESS entries in situations where the cache is full and space is
   needed to add a STATEFUL entry. A router MAY evict STATELESS entries
   in favor of HSTATELESS. Providing an interface for the administrator
   to evict all entries of a particular origin, change an entry's origin
   and the ability to configure the eviction strategy is RECOMMENDED.

 

Smith, Ddin              Expires April 21, 2013                 [Page 8]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

4.1. Neighbor Advertisement Validation

   Ensuring received neighbor advertisements correspond to previously
   sent neighbor solicitations prevents on-link nodes from sending
   unsolicited neighbor advertisements to the router, and then having
   them added to the router's neighbor cache without validation.  This
   would allow on-link hosts to perform a neighbor cache DoS attack, as
   they could send many neighbor advertisements for non-existent
   addresses within the link assigned prefixes, exhausting the neighbor
   cache capacity.

   If neighbor advertisement validation occurs, then the router is
   vulnerable to an off-link sourced neighbor cache DoS attack, but is
   not vulnerable to an on-link sourced neighbor cache DoS attack.  If
   neighbor advertisement validation does not occur, then the router is
   vulnerable to an on-link sourced neighbor cache DoS attack, but is
   now not vulnerable to an off-link sourced neighbor cache DoS attack.

   For best-case performance, Hashed SLND should be performed to provide
   cache protection against both on-link and off-link attacks.

4.2. Optimization Functions

   The nature of IPv6 is best-effort, meaning that there is a
   possibility that packets may be lost as they transit the network. If
   an application residing on an IPv6 node requires reliable packet
   delivery, it should utilize locally implemented reliable upper layer
   protocols such as TCP and SCTP, or implement it's own reliability
   mechanisms.  These reliability mechanisms involve retransmitting
   packets.  Alternatively, the application needs to accept the
   possibility of packet loss.

   The remaining uses of stateful neighbor discovery state are not
   assured of success.  The limited number of neighbor solicitation
   retransmissions may not be enough, causing neighbor discovery to fail
   even though the target node exists.  There may be more packets sent
   that trigger neighbor discovery than are stored for transmission when
   neighbor discovery completes successfully, causing them to be
   dropped.  The ICMPv6 destination unreachable message may be dropped
   on the way back to the traffic originating node, perhaps
   intentionally by a network located firewall.

   This provides the opportunity to perform a stateless form of neighbor
   discovery if there is evidence that a neighbor cache DoS attack is
   occurring, mitigating the off-link sourced neighbor cache DoS attack.

 

Smith, Ddin              Expires April 21, 2013                 [Page 9]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

5. Trusted/Untrusted Discriminator

   As previously described, the Trusted/Untrusted Discriminator (TUD) is
   used to determine whether a packet is trusted or untrusted, with
   trusted datagrams continuing to trigger traditional stateful neighbor
   discovery services, and untrusted ones receiving stateless neighbor
   discovery services.

   For routers where it may not be operationally convenient or possible
   to implement comprehensive trusted and untrusted datagram selection,
   such as on low-end or embedded devices, it would be acceptable to
   consider all datagram sources untrusted when stateless neighbor
   discovery is active.

   For routers that can support more comprehensive trusted and untrusted
   datagram discrimination, the following information sources are
   suggested for the purposes of configuring a default set of
   discriminators.

5.1. Configured Trusted and Untrusted Prefixes

   The first suggested TUD source is an operator configured list of
   prefixes and their lengths, each with a flag indicating whether
   traffic with source addresses that falls within the specified prefix
   is from a trusted or untrusted source, using the longest-match logic
   that is applied to IPv6 routing decisions.

   This list should have a default entry of the ULA prefix (fc00::/7)
   [RFC4193], flagged as a trusted source.  An implementation MUST allow
   this entry to be removed. An implementation SHOULD NOT have this
   default entry if reverse path filtering is not possible or where
   spoofing is considered trivial.

5.2. Routing Information

   The second suggested TUD source is the network's routing information.

   The network's routing information can be used to distinguish trusted
   and untrusted datagram sources.  An advantage of using routing
   information for this purpose is that it will typically be dynamically
   and automatically distributed to all routers within the network, when
   dynamic routing protocols are used.  This avoids individual routers
   in the network having to be manually reconfigured with trusted
   prefixes when subnets are added or removed from the network.

   The contents of a stub network's route table is typically all the
   internal routes for the network, and then a default route used to
   reach the Internet.  The list of internal routes can be used to
 

Smith, Ddin              Expires April 21, 2013                [Page 10]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

   distinguish between trusted and untrusted sources, with datagram
   sources matching internal routes being trusted, and all other
   datagram sources being untrusted.

   In more complex routing environments, such as those using one or more
   IGPs and an EGP such as BGP, there may be other methods available to
   distinguish between trusted and untrusted sources.  For example,
   routes carried in an IGP could be considered trusted, while routes
   carried in BGP are untrusted.  For a network using BGP to carry all
   reachability information, except network transit and loopback
   interface routes, routes may be tagged with one or more BGP
   communities which indicate internal and therefore trusted prefixes.

   A default route SHOULD NOT be used to define a trusted datagram
   source prefix.

5.3. Default to Untrusted

   Should the value of the discriminator not match the required one that
   has been configured according to the bitmask, the packet SHOULD be
   considered untrusted.

5.4. Neighbor Origin Flag (NOF) in relation to the TUD

   If a packet is trusted and a neighbor entry already exists with an
   origin of STATELESS or HSTATELESS, a router SHOULD update the NOF of
   the entry to STATEFUL.

   A neighbor entry with a STATEFUL origin MUST NOT have its origin
   changed except by administrative intervention.

6. Baseline Implementation

   A baseline implementation of this document MUST provide unhashed SLND
   with the means to configure the trigger threshold and disable SLND
   entirely.

   A router SHOULD NOT make exclusive use of SLND, however, the
   possibility of this due to hardware or other constraints is
   nonetheless acknowledged. Such a router MUST permit for exclusively
   operator configured neighbor entries.

   Non-router nodes MAY use SLND as a way to mitigate cache pressure
   caused by local applications or similar. Non-router notes using
   hashed SLND MUST NOT use a calculated source address known to belong
   to a router, in these (unlikely) instances, the NDHS SHOULD be
   immediately changed.

 

Smith, Ddin              Expires April 21, 2013                [Page 11]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

7. Acknowledgements

   Review and comments were provided by Ray Hunter and Matthew Moyle-
   Croft.

   This memo was prepared using the xml2rfc tool and nroff I-D editor.

8. Security Considerations

   This memo proposes a security mitigation for an off-link sourced
   neighbor cache Denial of Service attack, aimed at a router.

   As discussed in Section 4.1, the unhashed method proposed creates an
   opportunity for an on-link sourced neighbor cache DoS attack, when
   mitigating the off-link sourced neighbor cache DoS.  This is
   considered to be an acceptable security trade-off.

   The hashed method mitigates the above issue at the cost of creating
   some additional unnecessary ND traffic and potentially having a
   window of opportunity for a replay attack. The benefit of Hashed SLND
   is considered to outweigh these costs.

9. IANA Considerations

   This document has no actions for IANA.

10. Change Log [RFC Editor please remove]

   draft-smith-6man-mitigate-nd-cache-dos-slnd-00, initial version,
   2012-09-04

   draft-smith-6man-mitigate-nd-cache-dos-slnd-01, more clarity, 2012-
   10-13

   o  more comprehensive introduction (problem definition) text

   o  make it more obvious that hosts don't need to be changed

   o  low-end/embedded hosts can consider all datagram sources untrusted

   o  misc. minor text updates

   draft-smith-6man-mitigate-nd-cache-dos-slnd-02, major changes, 2012-
   10-16

   o  Add definition of Hashed SLND.

 

Smith, Ddin              Expires April 21, 2013                [Page 12]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

   o  Expand optional scope for flexibility of SLND

   o  Address potential security risks

   draft-smith-6man-mitigate-nd-cache-dos-slnd-03, major changes, 2012-
   10-18

   o  Clarify the behavior caused by calculated source addresses

   o  Add OPTIONAL Neighbor Origin Flag (NOF)

   o  Add section outlining baseline implementation requirements.

   o  Various other minor clarifications and fixups.

   draft-smith-6man-mitigate-nd-cache-dos-slnd-04, minor changes, 2012-
   10-18

   o  Cleaned up heading spacing.

   o  Adjusted abstract to explicitly state that it updates RFC 4861

11. References

11.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2. Informative References

   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
              Neighbor Discovery (ND) Trust Models and Threats",
              RFC 3756, May 2004.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

 

Smith, Ddin              Expires April 21, 2013                [Page 13]
Internet-Draft        Stateless Neighbor Discovery      October 18, 2012

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC5942]  Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
              Model: The Relationship between Links and Subnet
              Prefixes", RFC 5942, July 2010.

Author's Addresses

   Mark Smith
   In My Own Time
   PO BOX 521
   HEIDELBERG, VIC  3084
   AU

   Email: markzzzsmith@yahoo.com.au

   Oliver Ddin
   ZeroLag Communications
   289 S. Robertson Blvd #441
   Beverly Hills, CA 90211
   USA

   Email: oliver@zerolag.com

Smith, Ddin              Expires April 21, 2013                [Page 14]