Secure Neighbor Discovery Working                               J. Arkko
Group                                                           Ericsson
Internet-Draft                                                  J. Kempf
Expires: April 16, June 30, 2004                    DoCoMo Communications Labs USA
                                                           B. Sommerfeld
                                                        Sun Microsystems
                                                                 B. Zill
                                                               Microsoft
                                                             P. Nikander
                                                                Ericsson
                                                        October 17,
                                                       December 31, 2003

                    SEcure Neighbor Discovery (SEND)
                        draft-ietf-send-ndopt-00
                        draft-ietf-send-ndopt-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 April 16, June 30, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
   other nodes on the link, to determine each the link-layer addresses
   of the nodes on the link, to find routers, and to maintain
   reachability information about the paths to active neighbors.  If not
   secured, NDP is vulnerable to various attacks.  This document
   specifies security mechanisms for NDP.  Unlike to the original NDP
   specifications, these mechanisms do not make use of IPsec.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
          1.1   Specification of Requirements  . . . . . . . . . . . . 4
   2.    Terms  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.    Neighbor and Router Discovery Overview . . . . . . . . . . .  7
   4.    Secure Neighbor Discovery Overview . . . . . . . . . . . .  11 .  9
   5.    Neighbor Discovery Protocol Options  . . . . . . . . . . . . . . . .  12 11
          5.1    Ordering of the new options  . . . . . . . . . . . . . . .  12
   5.2   CGA Option . . . . . . . . . . . . . . . . . . . . . . . .  12
   5.2.1 .11
                 5.1.1 Processing Rules for Senders . . . . . . . . . . . . . . .  14
   5.2.2 12
                 5.1.2 Processing Rules for Receivers . . . . . . . . . . . . . .  15
   5.2.3 13
                 5.1.3 Configuration  . . . . . . . . . . . . . . . . . . . . . .  15
   5.3 14
          5.2   Signature Option . . . . . . . . . . . . . . . . . . . . .  15
   5.3.1 .14
                 5.2.1 Processing Rules for Senders . . . . . . . . . . . . . . .  18
   5.3.2 16
                 5.2.2 Processing Rules for Receivers . . . . . . . . 17
                 5.2.3 Configuration  . . . . . .  18
   5.3.3  Configuration  . . . . . . . . . . . . 18
                 5.2.4 Performance Considerations . . . . . . . . . . 19
   5.4
          5.3   Timestamp and Nonce options  . . . . . . . . . . . . . . .  20
   5.4.1 .19
                 5.3.1 Timestamp Option . . . . . . . . . . . . . . . 19
                 5.3.2 Nonce Option . . . . . .  20
   5.4.2  Nonce Option . . . . . . . . . . . . . . 20
                 5.3.3 Processing rules for senders . . . . . . . . . 21
   5.4.3
                 5.3.4 Processing rules for senders . . receivers . . . . . . . . 21
   6.    Authorization Delegation Discovery . . . . .  22
   5.4.4  Processing rules for receivers . . . . . . . . 24
          6.1   Certificate Format . . . . . .  22
   5.5    Proxy Neighbor Discovery . . . . . . . . . . . .24
                 6.1.1 Router Authorization Certificate Profile . . . 24
          6.2   Certificate Transport  . . .  24
   6.     Authorization Delegation Discovery . . . . . . . . . . . .  25
   6.1 .26
                 6.2.1 Delegation Chain Solicitation Message Format . . . . . . .  25
   6.2 27
                 6.2.2 Delegation Chain Advertisement Message Format  . . . . . .  27
   6.3  29
                 6.2.3 Trust Anchor Option  . . . . . . . . . . . . . . . . . . .  29
   6.4 31
                 6.2.4 Certificate Option . . . . . . . . . . . . . . 32
                 6.2.5 Processing Rules for Routers . . . . . .  30
   6.5    Router Authorization Certificate Format . . . 33
                 6.2.6 Processing Rules for Hosts . . . . . .  31
   6.5.1  Router Authorization Certificate Profile . . . . 34
   7.    Addressing . . . . .  31
   6.6    Processing Rules for Routers . . . . . . . . . . . . . . .  32
   6.7    Processing Rules for Hosts . . . . . 36
          7.1   CGA Addresses  . . . . . . . . . . .  34
   7.     Securing Neighbor Discovery with SEND . . . . . . . . .36
          7.2   Redirect Addresses . .  37
   7.1    Neighbor Solicitation Messages . . . . . . . . . . . . . .  37
   7.1.1  Sending Secure Neighbor Solicitations . .36
          7.3   Advertised Prefixes  . . . . . . . . .  37
   7.1.2  Receiving Secure Neighbor Solicitations . . . . . . . .36
          7.4   Limitations  . .  37
   7.2    Neighbor Advertisement Messages . . . . . . . . . . . . .  37
   7.2.1  Sending Secure Neighbor Advertisements . . . . . .37
   8.    Transition Issues  . . . . .  37
   7.2.2  Receiving Secure Neighbor Advertisements . . . . . . . . .  38
   7.3    Other Requirements . . . . . . . . . . . . . . . . . . . . 38
   8.     Securing Router Discovery with SEND  . . . . . . . .
   9.    Security Considerations  . . .  40
   8.1    Router Solicitation Messages . . . . . . . . . . . . . . . 40
   8.1.1  Sending Secure Router Solicitations  .
          9.1   Threats to the Local Link Not Covered by SEND  . . . .40
          9.2   How SEND Counters Threats to NDP . . . . . . .  40
   8.1.2  Receiving Secure Router Solicitations . . . .40
                 9.2.1 Neighbor Solicitation/Advertisement Spoofing . 41
                 9.2.2 Neighbor Unreachability Detection Failure  . . 41
                 9.2.3 Duplicate Address Detection DoS Attack . . . .  40
   8.2 41
                 9.2.4 Router Solicitation and Advertisement Messages  . . . . . . . . Attacks  42
                 9.2.5 Replay Attacks . . . . . .  41
   8.2.1  Sending Secure Router Advertisements . . . . . . . . . . 42
                 9.2.6 Neighbor Discovery DoS Attack  .  41
   8.2.2  Receiving Secure Router Advertisements . . . . . . . 43
          9.3   Attacks against SEND Itself  . . .  41
   8.3    Redirect Messages . . . . . . . . . .43
   10.   Protocol Constants . . . . . . . . . . .  41
   8.3.1  Sending Redirects . . . . . . . . . . 45
   11.   IANA Considerations  . . . . . . . . . .  41
   8.3.2  Receiving Redirects . . . . . . . . . . 46
         Normative References . . . . . . . . .  42
   8.4    Other Requirements . . . . . . . . . . . 47
         Informative References . . . . . . . . .  42
   9.     Co-Existence of SEND and non-SEND nodes . . . . . . . . .  43
   10.    Performance Considerations . 48
         Authors' Addresses . . . . . . . . . . . . . . .  45
   11.    Security Considerations . . . . . . 49
   A.    Contributors . . . . . . . . . . .  46
   11.1   Threats to the Local Link Not Covered by SEND . . . . . .  46
   11.2   How SEND Counters Threats to Neighbor Discovery . . . . .  47
   11.2.1 Neighbor Solicitation/Advertisement Spoofing . . 50
   B.    Acknowledgments  . . . . .  47
   11.2.2 Neighbor Unreachability Detection Failure . . . . . . . .  48
   11.2.3 Duplicate Address Detection DoS Attack . . . . . . . . . 51
   C.    Cache Management .  48
   11.2.4 Router Solicitation and Advertisement Attacks . . . . . .  49
   11.2.5 Replay Attacks . . . . . . . . . . . . . . . 52
         Intellectual Property and Copyright Statements . . . . . . .  49
   11.2.6 Neighbor Discovery DoS Attack  . . . . . . . . . . . . . .  49
   11.3   Attacks against SEND Itself  . . . . . . . . . . . . . . .  50
   12.    IANA Considerations  . . . . . . . . . . . . . . . . . . .  51
          Normative References . . . . . . . . . . . . . . . . . . .  52
          Informative References . . . . . . . . . . . . . . . . . .  54
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  55
   A.     Contributors . . . . . . . . . . . . . . . . . . . . . . .  57
   B.     IPR Considerations . . . . . . . . . . . . . . . . . . . .  58
   C.     Cache Management . . . . . . . . . . . . . . . . . . . . .  59
   D.     Comparison to AH-Based Approach  . . . . . . . . . . . . .  60
          Intellectual Property and Copyright Statements . . . . . .  63

1. Introduction

   IPv6 defines the 53

1. Introduction

   IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC RFCs 2461 [6]. [7]
   and 2462 [8].  Nodes on the same link use NDP to discover each
   other's presence, to determine each other's link-layer addresses, to
   find routers, and to maintain reachability information about the
   paths to active neighbors.  NDP is used both by hosts and routers.
   Its functions include Neighbor Discovery (ND), Router Discovery (RD),
   Address Autoconfiguration, Address Resolution, Neighbor
   Unreachability Detection (NUD), Duplicate Address Detection (DAD),
   and Redirection.

   RFC 2461

   Original NDP specifications called for the use of IPsec for
   protecting the NDP messages.  However, it does the RFCs do not specify give detailed
   instructions for using IPsec to secure NDP.  It turns out that in
   this particular application, IPsec can only be used with a manual
   configuration of security associations, due to chicken-and-egg
   problems in using IKE [22] [19]. [20, 15].  Furthermore, the number of such
   manually configured security associations needed for protecting NDP
   can be very large [23], [21], making that approach impractical for most
   purposes.

   This document is organized as follows.  Section 4 describes the
   overall approach to securing NDP.  This approach involves the use of
   new NDP options to carry public-key based signatures.  A
   zero-configuration mechanism is used for showing address ownership on
   individual nodes; routers are certified by a trust anchor [11]. [10].  The
   formats, procedures, and cryptographic mechanisms for the
   zero-configuration mechanism are described in a related specification
   [26].
   [12].

   The required new NDP options are discussed in Section 5.  Section 6
   describes the mechanism for distributing certificate chains to
   establish an authorization delegation chain to a common trust anchor.  The required new NDP options are discussed in Section 5.
   Section 7 and Section 8 show how to apply these components to
   securing Neighbor and Router Discovery.

   Finally, Section 9 8 discusses the co-existence of secure and
   non-secure Neighbor Discovery NDP on the same link, Section 10 discusses
   performance considerations, link and Section 11 9 discusses security
   considerations for Secure Neighbor Discovery.

2. Terms

   Authorization Delegation Discovery

1.1 Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and
   "MAY" in this document are to be interpreted as described in [2].

2. Terms

   Authorization Delegation Discovery (ADD)

      A process through which SEND nodes can acquire a certificate chain
      from a peer node to a trust anchor.

   Cryptographically Generated Addresses (CGAs) Address (CGA)

      A technique [26] [30] [12] where the IPv6 address of a node is
      cryptographically generated using a one-way hash function from the
      node's public key and some other parameters.

   Duplicate Address Detection (DAD)

      A mechanism defined in RFC 2462 [7] that assures that two IPv6 nodes on the same link are
      not using the same addresses.

   Internet Control Message Protocol version 6 (ICMPv6)

      The IPv6 control signaling protocol.  Neighbor Discovery Protocol
      is a part of ICMPv6.

   Neighbor Discovery Protocol (NDP)

      The IPv6 Neighbor Discovery Protocol [6]. [7, 8].

   Neighbor Discovery (ND)

      The Neighbor Discovery function of the Neighbor Discovery Protocol
      (NDP).  NDP contains also other functions but ND.

   Neighbor Unreachability Detection (NUD)

      This mechanism defined in RFC 2461 [6] is used for tracking the reachability of neighbors.

   Nonce

      A random number generated by a node and used exactly once, and
      never again. once.  In
      SEND, nonces are used to ensure that a particular advertisement is
      linked to the solicitation that triggered it.

   Router Authorization Certificate

      An X.509v3 [11] [10] PKC certificate using the profile specified in
      Section 6.5.1. 6.1.1.

   SEND node

      An IPv6 node that implements this specification.

   non-SEND node

      An IPv6 node that does not implement this specification but uses
      the legacy RFC 2461 and RFC 2462 mechanisms.

   Router Discovery (RD)

      The Router Discovery function of the Neighbor Discovery Protocol
      (NDP). Protocol.

3. Neighbor and Router Discovery Overview

   IPv6

   The Neighbor and Router Discovery have Protocol has several functions.  Many of these
   functions are overloaded on a few central message types, such as the
   ICMPv6 Neighbor Discovery Advertisement message.  In this section we review
   some of these tasks and their effects in order to understand better
   how the messages should be treated.  This section is not normative,
   and if this section and the original Neighbor Discovery RFCs are in
   conflict, the original RFCs take precedence.

   In IPv6, many

   The main functions of NDP are the tasks traditionally preformed at lower the
   layers, such as ARP, have been moved following.

   o  The Router Discovery function allows IPv6 hosts to discover the IP layer.  As a
   consequence, a set of unified mechanisms can be applied across link
   layers, any introduced security mechanisms or other extensions can be
   adopted more easily, and a clear separation
      local routers on an attached link.  Router Discovery is described
      in Section 6 of the roles between the
   IP and link layer has been achieved. RFC 2461 [7].  The main functions purpose of IPv6 Neighbor Router
      Discovery is to find neighboring routers that are willing to
      forward packets on behalf of hosts.  Prefix discovery involves
      determining which destinations are directly on a link; this
      information is necessary in order to know whether a packet should
      be sent to a router or to the following. destination node directly.

   o  Neighbor Unreachability Detection (NUD)  The Redirect function is used for tracking the
      reachability of neighboring nodes, both automatically redirecting a host
      to a better first-hop router, or to inform hosts and routers. NUD that a
      destination is
      defined in fact a neighbor (i.e., on-link).  Redirect is
      specified in Section 7.3 8 of RFC 2461 [6].  NUD is
      security-sensitive, because an attacker could falsely claim that
      reachability exists when it in fact does not. [7].

   o  Duplicate  Address Detection (DAD) Autoconfiguration is used for preventing address
      collisions [7].  A node automatically assigning
      addresses to a host [8].  This allows hosts to operate without
      explicit configuration related to IP connectivity.  The default
      autoconfiguration mechanism is stateless.  To create IP addresses,
      the hosts use any prefix information delivered to them during
      Router Discovery, and then test the newly formed addresses for
      uniqueness.  A stateful mechanism, DHCPv6 [23], provides
      additional autoconfiguration features.

   o  Duplicate Address Detection (DAD) is used for preventing address
      collisions [8], for instance during Address Autoconfiguration.  A
      node that intends to assign a new address to one of its interfaces
      first runs the DAD procedure to verify that there is no other node
      using the same address.  Since the rules forbid the use of an
      address until it has been found unique, no higher layer traffic is
      possible until this procedure has been completed.  Thus,
      preventing attacks against DAD can help ensure the availability of
      communications for the node in question.

   o  Address Resolution is similar to IPv4 ARP [18].  The Address Resolution function resolves a node's IPv6 address to
      the corresponding link-layer address for nodes on the link.
      Address Resolution is defined in Section 7.2 of RFC 2461 [6], [7], and
      it is used for hosts and routers alike.  Again, no higher level
      traffic can proceed until the sender knows the hardware address of
      the destination node or the next hop router.  Note that like its
      predecessor in ARP, IPv6 Neighbor Discovery does not check the source link
      layer address is not checked against the information learned
      through Address Resolution.  This allows for an easier addition of
      network elements such as bridges and proxies, and eases the stack
      implementation requirements as less information needs to be passed
      from layer to layer.

   o  Address Autoconfiguration  Neighbor Unreachability Detection (NUD) is used for automatically assigning
      addresses to a host [7]. This allows hosts to operate without
      explicit configuration related to IP connectivity.  The Address
      Autoconfiguration mechanism defined in [7] is stateless. To create
      IP addresses, tracking the
      reachability of neighboring nodes, both hosts use any prefix information delivered to
      them during Router Discovery, and then test the newly formed
      addresses for uniqueness using the DAD procedure.  A stateful
      mechanism, DHCPv6 [24], provides additional Autoconfiguration
      features.  Router and Prefix Discovery and Duplicate Address
      Detection have an effect on the Address Autoconfiguration tasks.

   o  The Redirect function is used for automatically redirecting hosts
      to an alternate router.  Redirect routers.  NUD is specified
      defined in Section 8 7.3 of RFC 2461 [6].  It [7].  NUD is similar to the ICMPv4 Redirect function [17].

   o  The Router Discovery function allows IPv6 hosts to discover the
      local routers on
      security-sensitive, because an attached link.  Router Discovery is described attacker could falsely claim that
      reachability exists when it in Section 6 of RFC 2461 [6]. fact does not.

   The main purpose of Router
      Discovery is to find neighboring routers that are willing to
      forward packets on behalf of hosts.  Prefix discovery involves
      determining which destinations are directly on a link; this
      information is necessary in order to know whether a packet should
      be sent to a router or to the destination node directly.
      Typically, address autoconfiguration and other tasks can not
      proceed until suitable routers and prefixes have been found.

   The Neighbor Discovery NDP messages follow the ICMPv6 message format.
   They have ICMPv6 types from 133 to 137.  The IPv6 Next Header value
   for ICMPv6 is 58. The actual  All NDP functions
   are realized using the Router Solicitation (RS), Router Advertisement
   (RA), Neighbor Discovery Solicitation (NS), Neighbor Advertisement (NA), and
   Redirect messages.  An actual NDP message includes an NDP message
   header, consisting of an ICMPv6 header and ND message-specific data,
   and zero or more NDP options.  The NDP message options are formatted
   in the Type-Length-Value format.

                         <------------NDP Message---------------->
     *-------------------------------------------------------------*
     | IPv6 Header      | ICMPv6   | ND message- | ND Message      |
     | Next Header = 58 | Header   | specific    | Options         |
     | (ICMPv6)         |          | data        |                 |
     *-------------------------------------------------------------*
                         <--NDP Message header-->

   The NDP message

4. Secure Neighbor Discovery Overview

   To secure the various functions, a set of new Neighbor Discovery
   options is introduced.  They are formatted used in the Type-Length-Value
   format.

   All IPv6 to protect NDP functions are realized using messages.
   This specification introduces these options, an authorization
   delegation discovery process, an address ownership proof mechanism,
   and requirements for the following ICMPv6
   messages:

            ICMPv6 Type      Message
            ------------------------------------
            133              Router Solicitation (RS)
            134              Router Advertisement (RA)
            135              Neighbor Solicitation (NS)
            136              Neighbor Advertisement (NA)
            137              Redirect use of these components in NDP.

   The various functions components of the solution specified in this document are realized using these messages as
   follows:

   o  Router Discovery uses  Certificate chains, anchored on trusted parties, are expected to
      certify the RS authority of routers.  A host and RA messages.

   o  Duplicate Address Detection uses a router must have
      at least one common trust anchor before the NS and NA messages.

   o  Address Autoconfiguration uses host can adopt the NS, NA, RS,
      router as its default router.  Delegation Chain Solicitation and RA messages.

   o  Address Resolution uses the NS and NA messages.

   o  Neighbor Unreachability Detection uses the NS and NA messages.

   o  Redirect uses the Redirect message.

   The NDP
      Advertisement messages are always meant to be used within to discover a link, and never
   intended certificate chain to leak outside of it.  The destination and source addresses
   used in these
      the trust anchor without requiring the actual Router Discovery
      messages are as follows:

   o  Neighbor Solicitation: to carry lengthy certificate chains.  The destination address receipt of a
      protected Router Advertisement message for which no certificate
      chain is either available triggers this process.

   o  Cryptographically Generated Addresses are used to assure that the
      Solicited-Node multicast address,
      sender of a unicast address, Neighbor or Router Advertisement is the "owner" of the
      claimed address.  A public-private key pair needs to be generated
      by all nodes before they can claim an anycast address.  The source address  A new NDP option,
      the CGA option, is either used to carry the unspecified address (in
      DAD) or a unicast address assigned public key and associated
      parameters.

      This specification also allows one to use non-CGA addresses and to
      use certificates to authorize their use.  However, the sending interface.  In a
      typical case, details of
      such use have been left for future work.

   o  A new NDP option, the source address Signature option, is equal used to protect all
      messages relating to Neighbor and Router discovery.

      Public key signatures are used to protect the source address integrity of the outgoing packet, locally triggering the need
      messages and to send authenticate the
      solicitation.

   o  Neighbor Advertisement: identity of their sender.  The destination address
      authority of a public key is established either a
      unicast address with the
      authorization delegation process, using certificates, or through
      the link-scoped All-Nodes multicast address
      [12].  The source address is a unicast address assigned to ownership proof mechanism, using CGAs, or both,
      depending on configuration and the
      sending interface. type of the message protected.

   o  In order to prevent replay attacks, two new Neighbor Discovery
      options, Timestamp and Nonce, are used.  Given that Neighbor and
      Router Solicitation: The destination address is typically the
      All-Routers Discovery messages are in some cases sent to multicast address [12].  The source address is either
      addresses, the unspecified address Timestamp option offers replay protection without
      any previously established state or a unicast address assigned to sequence numbers.  When the
      sending interface.  An unspecified source address does not have
      any special semantics; it is just an optimization for startup.

   o  Router Advertisement:
      messages are used in solicitation - advertisement pairs, they are
      protected using the Nonce option.

5. Neighbor Discovery Protocol Options

   The destination address can options described in this section MUST be either a
      unicast or the link-scoped All-Nodes multicast address [12]. supported by all SEND
   nodes.

5.1 CGA Option

   The
      source address is a link-local address assigned to the sending
      interface.

   o  Redirect: This message is always sent to CGA option allows the source address verification of the
      packet that triggered the Redirect.  Hosts verify that the IP
      source address sender's CGA.  The
   format of the Redirect is the same as the current
      first-hop router for the specified ICMP Destination Address.
      Rules in [12] dictate that anycast, or multicast addresses may not
      be used as source addresses.  If the source address is an
      unspecified address, it is impossible to send a Redirect, since
      the unspecified address CGA option is forbidden described as the destination address.
      Therefore, the destination address must always be a unicast
      address.

      The source address is a link-local address assigned to the sending
      interface.

4. Secure Neighbor Discovery Overview

   To secure the various functions, a set follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     | Collision Cnt |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                          Modifier                             |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Key Information                        .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                           Padding                             .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meaning of new Neighbor Discovery
   options introduced.  They are used in to protect Neighbor and Router
   Discovery messages.  This specification introduces these options, an
   authorization delegation discovery process, an address ownership
   proof mechanism, and requirements for the use of these components fields is described as follows.

   Type

      TBD <To be assigned by IANA> for
   Neighbor Discovery. CGA.

   Length

      The components length of the solution specified option, in this document are as
   follows:

   o  Certificate chains, anchored on trusted parties, are expected to
      certify the authority units of routers.  A host and a router must have
      at least one common trust anchor before the host 8 octets.

   Collision Cnt

      An 8-bit collision count, which can adopt the
      router as its default router.  Delegation Chain Solicitation get values 0, 1 and
      Advertisement messages 2.  Its
      semantics are used to discover a certificate chain defined in [12].

   Reserved

      An 8-bit field reserved for future use.  The value MUST be
      initialized to zero by the trust anchor without requiring the actual Router Discovery
      messages to carry lengthy certificate chains.

   o  Cryptographically Generated Addresses are used to assure that the
      sender of a Neighbor or Router Advertisement is the "owner" of the
      claimed address.  A public-private key pair needs to sender, and MUST be generated ignored by all nodes before they can claim an address.  A new Neighbor
      Discovery option, the CGA option, is
      receiver.

   Modifier

      A random 128-bit number used to carry in CGA generation.  Its semantics are
      defined in [12].

   Key Information

      A variable length field containing the public key
      and associated parameters. of the sender,
      represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as
      described in Section 4 of [12].

      This specification also allows one to use non-CGA addresses and to
      use certificates to authorized their use.  However, requires that if both the details of
      such use have been left for future work.

   o  A new Neighbor Discovery option, CGA option and the
      Signature option, is used to
      protect all messages relating to Neighbor and Router discovery.

      Public key signatures option are used to protect present, then the integrity of publicKey field in the
      messages and to authenticate
      former option MUST be the identity of their sender.  The
      authority of a public key is established either with referred by the
      authorization delegation process, using certificates, or through Key Hash
      field in the latter option.  Packets received with two different
      keys MUST be silently discarded.  Note that a future extension may
      provide a mechanism which allows the owner of an address ownership proof mechanism, using CGAs, or both,
      depending on configuration and the type
      signer to be different parties.

      The length of the message protected.

   o  In order to prevent replay attacks, two new Neighbor Discovery
      options, Timestamp and Nonce, are used.  Given that Neighbor and
      Router Discovery messages are in some cases sent to multicast
      addresses, Key Information field is determined by the ASN.1
      encoding.

   Padding

      A variable length field making the Timestamp option offers replay protection without
      any previously established state or sequence numbers.  When length a multiple of 8.
      It begins after the
      messages are used in solicitation - advertisement pairs, they
      protected using ASN.1 encoding of the Nonce option.

5. Neighbor Discovery Options

   The following new NDP options previous field has ends,
      and mechanisms are REQUIRED continues to be
   implemented the end of the option, as specified by all SEND nodes:

   o the Length
      field.

5.1.1 Processing Rules for Senders

   The CGA option MAY MUST be present in all Neighbor Discovery Solicitation and
   Advertisement messages, and SHOULD be present in most cases.

   o Router Solicitation messages not sent
   with the unspecified source address.  The Signature CGA option is REQUIRED MAY be present
   in all Neighbor Discovery other messages.

   o  The Nonce

   A node sending a message using the CGA option is REQUIRED in all Neighbor Discovery
      solicitations, MUST construct the
   message as follows.

   The Modifier, Collision Cnt, and Key Information fields in all solicited advertisements.

   o  The Timestamp the CGA
   option is REQUIRED are filled in all Neighbor Discovery
      advertisements according to the rules presented above and Redirects.

   o  Proxy Neighbor Discovery is not supported by this specification;
      it in
   [12].  The used public key is planned to taken from configuration; typically
   from a data structure associated with the source address.  The
   address MUST be constructed as specified in a future document.

5.1 Ordering Section 4 of [12].
   Depending on the new options

   The ordering type of the new options message, this address appears in
   different places:

   Redirect

      The address MUST obey be the following rules: source address of the message.

   Neighbor Solicitation

      The CGA option address MUST appear before be the Signature option.

      The Nonce option SHOULD appear before Target Address for solicitations sent for
      the Timestamp option. purpose of Duplicate Address Detection, and the source address
      of the message otherwise.

   Neighbor Advertisement

      The Signature option address MUST NOT be be followed CGA, Nonce, or
      Timestamp options.

      It is RECOMMENDED that the options appear in source address of the following order:
      CGA, Nonce, Timestamp, Signature.

5.2 CGA Option message.

   Router Solicitation

      The CGA option allows address MUST be the verification source address of the sender's CGA. The
   format of message.  Note that
      the CGA option is described as follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |            Modifier           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Collision Cnt |                  Reserved                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Key Information                        .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                           Padding                             .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meaning of not used when the fields source address is described as follows.

   Type

      TBD <To be assigned by IANA> for CGA.

   Length the
      unspecified address.

   Router Advertisement

      The length address MUST be the source address of the option, in units message.

5.1.2 Processing Rules for Receivers

   Neighbor Solicitation and Advertisement messages without the CGA
   option MUST be silently discarded.  Router Solicitation messages
   without the CGA option MUST be silently discarded, unless the source
   address of 8 octets.

   Modifier the message is the unspecified address.

   A random number used in message containing a CGA generation.  Its semantics are defined
      in [26].

   Collision Cnt

      An 8-bit collision count, which can get values 0, 1 and 2. Its
      semantics are defined in [26].

   Reserved

      A 24-bit field reserved for future use.  The value option MUST be
      initialized checked as follows:

      If the interface has been configured to zero by use CGA, the sender, and receiving
      node MUST be ignored by the
      receiver.

   Key Information

      A variable length field containing verify the public key source address of the sender,
      represented as an ASN.1 type SubjectPublicKeyInfo [11], encoded as packet using the
      algorithm described in Section 4 5 of [26].

      This specification requires that if both the CGA option and [12].  The inputs for the
      Signature option
      algorithm are present, then the publicKey field in the
      former option MUST be contents of the public key referred by Collision Cnt, Modifier, and the
      Key Hash
      field Information fields, the claimed address in the latter option.  Packets received with two different
      keys MUST be silently discarded.  Note that a future extension may
      provide a mechanism which allows packet (as
      discussed in the owner of an address previous section), and the
      signer to be different parties.

      The length of minimum acceptable Sec
      value.  If the Key Information field CGA verification is determined by the ASN.1
      encoding.

   Padding

      A variable length field making successful, the option length a multiple of 8.
      It begins after recipient
      proceeds with the ASN.1 encoding cryptographically more time consuming check of
      the previous field signature.

   Note that a receiver which does not support CGA or has ends,
      and continues to the end of the option, as not specified by the Length
      field.

5.2.1 Processing Rules
   its use for Senders

   A node sending a message given interface can still verify packets using the CGA option MUST construct the
   message as follows.

   The Modifier, Collision Cnt, and Key Information fields in the trust
   anchors, even if CGA
   option are filled in according to the rules presented above and in
   [26].  The had been used public key is taken from configuration; typically
   from on a data structure associated with the source address.

   An address MUST be constructed as specified in Section 4 of [26]. packet.  In
   the typical such a case, the address is constructed long before it is used.

   Depending on the type
   CGA property of the message, this address appears in
   different places:

   Redirect

      The address MUST be is simply left unverified.

5.1.3 Configuration

   All nodes that support the source address verification of the message.

   Neighbor Solicitation

      The address CGA option MUST be record
   the Target Address for solicitations sent following configuration information:

   minbits

      The minimum acceptable key length for the purpose of Duplicate Address Detection, and public keys used in the source address
      generation of the message otherwise.

   Neighbor Advertisement CGA address.  The address MUST default SHOULD be 1024 bits.
      Implementations MAY also set an upper limit in order to limit the source address
      amount of computation they need to perform when verifying packets
      that use these security associations.  Any implementation should
      follow prudent cryptographic practice in determining the message.

   Router Solicitation
      appropriate key lengths.

   minSec

      The address MUST be the source address of the message, unless the
      source address minimum acceptable Sec value, if CGA verification is required
      (see Section 2 in [12]).  This parameter is intended to facilitate
      future extensions and experimental work.  Currently, the unspecified address.

   Router Advertisement

      The address MUST minSec
      value SHOULD always be set to zero.

   All nodes that support the source address of the message.

5.2.2 Processing Rules for Receivers

   A message containing a CGA option MUST be checked as follows:

      If the interface has been configued to use CGA, it is REQUIRED
      that the receiving node verifies the source address of the packet
      using the algorithm described in Section 5 of [26].  The inputs
      for the algorithm are the contents of the Modifier, Collision Cnt,
      and the Key Information fields, the claimed address in the packet
      (as discussed in the previous section), and the minimum acceptable
      Sec value. If the CGA verification is successful, the recipient
      proceeds with the cryptographically more time consuming check of
      the signature.

   Note that a receiver which does not support CGA or has not specified
   its use for a given interface can still verify packets using trust
   anchors, even if CGA had been used on a packet.  In such a case, the
   CGA property of the address is simply left unverified.

5.2.3 Configuration

   All nodes that support the verification sending of the CGA option MUST record the
   following configuration information:

   minbits

      The minimum acceptable key length for the public keys used in the
      generation of the

   CGA address.  The default SHOULD be 1024 bits.
      Implementations MAY also set an upper limit in order parameters

      Any information required to limit construct CGAs, including the
      amount of computation they need to perform when verifying packets
      that use these security associations.  Any implementation should
      follow prudent cryptographic practise in determining used Sec
      and Modifier values, and the
      appropriate key lengths.

5.3 CGA address itself.

5.2 Signature Option

   The Signature option allows public-key based signatures to be
   attached to NDP messages.  Both trust anchor authentication and CGAs
   can be used.  The format of the Signature option is described in the
   following:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |  Pad Length   |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                          Key Hash                             |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                       Digital Signature                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                           Padding                             .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meaning of the fields is described below:

   Type

      TBD <To be assigned by IANA> for Signature.

   Length

      The length of the option, in units of 8 octets.

   Pad Length

      An 8-bit integer field, giving the length of the Pad field in
      units of an octet.

   Reserved

      An an 8-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Key Hash

      A 128-bit field contains the most significant (leftmost) 128-bits
      of a SHA1 hash of the public key used for the constructing the
      signature.  The SHA1 is taken over the presentation used in the
      Key Information field in the CGA option.  Its purpose is to
      associate the signature to a particular key known by the receiver.
      Such a key can be either stored in the certificate cache of the
      receiver, or be received in the CGA option in the same message.

   Digital Signature

      A variable length field contains the signature constructed using
      the sender's private key, over the the following sequence of
      octets:

      1.  The 128-bit CGA Type Tag [26] [12] value for SEND, 0xXXXX XXXX XXXX
          XXXX XXXX XXXX XXXX XXXX (To be generated 0x086F CA5E 10B2
          00C9 9C8C E001 6427 7C08 (generated randomly).

      2.  The 128-bit Source Address field from the IP header.

      3.  The 128-bit Destination Address field from the IP header.

      4.  The 32-bit ICMP header, i.e., the Type, Code, and Checksum
          fields. header.

      5.  The Neighbor Discovery NDP message header, i.e., the Reserved
          field in the Router Solicitation message, the Cur Hop Limit,
          M, O, Reserved, Router Lifetime, Reachable Time, and Retrans
          Timer fields in the Router Advertisement message, Reserved and
          Target Address fields in the Neighbor Solicitation message, R,
          S, O, Reserved, and Target Address fields in the Neighbor
          Advertisement message, and Reserved, Target Address, and
          Destination Address fields in the Redirect message. header.

      6.  All NDP options preceding the Signature option.

      The signature is constructed using the RSA algorithm and MUST be
      encoded as private key encryption in PKCS#1 format [15]. [13].  The
      signature value is computed with the RSASSA-PKCS1-v2_1 RSASSA-PKCS1-v1_5 algorithm
      and SHA-1 hash as defined in [15]. [13].

      This field starts after the Key Hash field.  The length of the
      Digital Signature field is determined by the length of the
      Signature option minus the length of the other fields (including
      the variable length Pad field).

      This variable length field contains padding, as many bytes as is
      given by the Pad Length Field.

5.3.1

5.2.1 Processing Rules for Senders

   Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
   and Redirect messages MUST contain the Signature option.  Router
   Solicitation messages not sent with the unspecified source address
   MUST contain the Signature option.

   A node sending a message using the Signature option MUST construct
   the message as follows:

   o  The message is constructed in its entirety. entirety, without the Signature
      option.

   o  The Signature option is added as the last option in the message.

   o  For the purpose of constructing a signature, the following data
      items are concatenated:

      *  The 128-bit CGA Type Tag.

      *  The source address of the message.

      *  The destination address of the message.

      *  The contents of the message, starting from the ICMPv6 header,
         up to but excluding the Signature option.

   o  The message, in the form defined above, is signed using the
      configured private key, and the resulting PKCS#1 signature is put
      to the Digital Signature field.

5.3.2

5.2.2 Processing Rules for Receivers

   Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
   and Redirect messages without the Signature option MUST be silently
   discarded.  Router Solicitation messages without the Signature option
   MUST be silently discarded, unless the source address of the message
   is the unspecified address.

   A message containing a Signature option MUST be checked as follows:

   o  The Signature option MUST appear as the last option.

   o  The Key Hash field MUST indicate the use of a known public key,
      either one learned from a preceeding preceding CGA option, or one known by
      other means.

   o  TheDigital  The Digital Signature field MUST have correct encoding, and do not
      exceed the length of the Signature option.

   o  The Digital Signature verification MUST show that the signature
      has been calculated as specified in the previous section.

   o  If the use of a trust anchor has been configured, a valid
      authorization delegation chain MUST be known between the
      receiver's trust anchor and the sender's public key.

      Note that the receiver may verify just the CGA property of a
      packet, even if, in addition to CGA, the sender has used a trust
      anchor.

   Messages that do not pass all the above tests MUST be silently
   discarded.  The receiver MAY silently drop discard packets also otherwise,
   e.g., as a response to an apparent CPU exhausting DoS attack.

5.3.3

5.2.3 Configuration

   All nodes that support the reception of the Signature options MUST
   record the following configuration information for each separate
   Neighbor Discovery Protocol NDP
   message type:

   authorization method

      This parameter determines the method through which the authority
      of the sender is determined.  It can have four values:

      trust anchor

         The authority of the sender is verified as described in Section
         6.5.
         6.1.  The sender may claim additional authorization through the
         use of CGAs, but that is neither required nor verified.

      CGA

         The CGA property of the sender's address is verified as
         described in [26]. [12].  The sender may claim additional authority
         through a trust anchor, but that is neither required nor
         verified.

      trust anchor and CGA

         Both the trust anchor and the CGA verification is required.

      trust anchor or CGA

         Either the trust anchor or the CGA verification is required.

   anchor

      The public keys and names of the allowed trust anchor(s), if
      authorization method is not set to CGA.

   minSec

      The minimum acceptable Sec value, if CGA verification is required
      (see Section 2 in [26]). This parameter is intended to facilitate
      future extensions and experimental work.  Currently, the minSec
      value SHOULD always be set to zero.

   All nodes that support the sending of Signature options MUST record
   the following configuration information:

   keypair

      A public-private key pair.  If authorization delegation is in use,
      there must exist a delegation chain from a trust anchor to this
      key pair.

   CGA flag

      A flag that indicates whether CGA is used or is not used.  This
      flag may be per interface or per node.

   CGA parameters

      Optionally any information required to construct CGAs, including
      the used Sec and Modifier values,

5.2.4 Performance Considerations

   The construction and verification of this option is computationally
   expensive.  In the CGA address itself.

5.4 Timestamp NDP context, however, the hosts typically have the
   need to perform only a few signature operations as they enter a link,
   and Nonce options

5.4.1 Timestamp Option

   The purpose a few operations as they find a new on-link peer with which to
   communicate.

   Routers are required to perform a larger number of operations,
   particularly when the Timestamp option frequency of router advertisements is high due
   to mobility requirements.  Still, the number of required signature
   operations is on the order of a few dozen ones per second, some of
   which can be precomputed as discussed below.  A large number of
   router solicitations may cause higher demand for performing
   asymmetric operations, although RFC 2461 limits the rate at which
   responses to solicitations can be sent.

   Signatures can be precomputed for unsolicited (multicast) Neighbor
   and Router Advertisements, if the timing of such future
   advertisements is known.  Typically, solicited advertisements are
   sent to the unicast address from which the solicitation was sent.
   Given that the IPv6 header is covered by the signature, it is not
   possible to precompute solicited-for advertisements.

5.3 Timestamp and Nonce options

5.3.1 Timestamp Option

   The purpose of the Timestamp option is to ensure that unsolicited
   advertisements and redirects have not been replayed.  The format of
   the Timestamp
   this option is described in the following:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                          Timestamp                            +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the fields are as follows:

   Type

      TBD <To be assigned by IANA> for Timestamp.

   Length

      The length of the option, in units of 8 octets, i.e., 2.

   Reserved

      A 48-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Timestamp

      A 64-bit unsigned integer field containing a timestamp.  The value
      indicates the number of seconds since January 1,, 1970 00:00 UTC,
      using a fixed point format.  In this format the integer number of
      seconds is contained in the first 48 bits of the field, and the
      remaining 16 bits indicate the number of 1/64K fractions of a
      second.

5.4.2

5.3.2 Nonce Option

   The purpose of the Nonce option is to ensure that an advertisement is
   a fresh response to a solicitation sent earlier by the receiving same
   node.  The format of the Nonce this option is as described in the following:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |  Nonce ...                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                                                               |
       .                                                               .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the fields are as follows:

   Type

      TBD <To be assigned by IANA> for Nonce.

   Length

      The length of the option, in units of 8 octets.

   Nonce

      A field containing a random number selected by the sender of the
      solicitation message.  The length of the random number MUST be at
      least 6 bytes.

5.4.3

5.3.3 Processing rules for senders

   All solicitation messages MUST include a Nonce.  All solicited-for
   announcements
   advertisements MUST include a Nonce, copying the nonce value from the
   received solicitation.  When sending a solication, solicitation, the sender MUST
   store the nonce internally so that it can recognize any replies
   containing that particular nonce.

   All NDP solicitation, advertisement, and redirect messages MUST include a
   Timestamp.  Senders SHOULD set the Timestamp field to the current
   time, according to their real time clock.

   If a message has both Nonce and Timestamp options, the Nonce option
   SHOULD precede the Timestamp option in order. The receiver MUST be
   prepared to receive them in any order, as per RFC 2461 [6] Section 9.

5.4.4

5.3.4 Processing rules for receivers

   The processing of the Nonce and Timestamp options depends on whether
   a packet is a solicited-for advertisement or not.  A system may
   implement the distinction in various means.  Section 5.4.4.1 5.3.4.1 defines
   the processing rules for solicited-for advertisements.  Section
   5.4.4.2
   5.3.4.2 defines the processing rules for all other messages.

   In addition, the following rules apply in any case:

   o  Messages received without the Timestamp option MUST be silently
      discarded.

   o  Solicitation messages received without the Nonce option MUST be
      silently discarded.

   o  Advertisements sent to a unicast destination address without a
      Nonce option MUST be silently discarded.

   o  An implementation may utilize some mechanism such as a timestamp
      cache to strengthen resistance to replay attacks.  When there is a
      very large number of nodes on the same link, or when a cache
      filling attack is in progress, it is possible that the cache
      holding the most recent timestamp per sender becomes full.  In
      this case the node MUST remove some entries from the cache or
      refuse some new requested entries.  The specific policy as to
      which entries are preferred over the others is left as an
      implementation decision.  However, typical policies may prefer
      existing entries over new ones, CGAs with a large Sec value over
      smaller Sec values, and so on.  The issue is briefly discussed in
      Appendix C.

5.4.4.1

   o  The receiver MUST be prepared to receive the Timestamp and Nonce
      options in any order, as per RFC 2461 [7] Section 9.

5.3.4.1 Processing solicited-for advertisements

   The receiver MUST verify that it has recently send sent a matching
   solicitation, and that the received advertisement does contain contains a copy of
   the Nonce sent in the solicitation.

   If the message contains a Nonce option, but the Nonce value is not
   recognized, the message MUST be silently discarded.

   Otherwise, if the message does not contain a Nonce option, it MAY be
   considered as a non-solicited-for announcement, advertisement, and processed
   according to Section 5.4.4.2.

   If the message does contain a Nonce option, but the Nonce value is
   not recognized, the message MUST be silently dropped. 5.3.4.2.

   If the message is accepted, the receiver SHOULD store the receive
   time of the message and the time stamp time in the message, as
   specified in Section 5.4.4.2

5.4.4.2 5.3.4.2

5.3.4.2 Processing all other messages

   Receivers SHOULD be configured with an allowed timestamp Delta value value,
   a "fuzz factor" for comparisons, and an allowed clock drift
   parameter.  The recommended default value for the allowed Delta is
   3,600 seconds (1 hour) hour), for fuzz factor 1 second, and for clock dritf drift
   1% (0.01).

   To facilitate timestamp checking, each node SHOULD store the
   following information per each peer:

      The receive time of the last received, acepted accepted SEND message.
      This is called RDlast.

      The time stamp in the last received, accepted SEND message.  This
      is called TSlast.

   Receivers SHOULD then check the Timestamp field as follows:

   o  When a message is received from a new peer, i.e., one that is not
      stored in the cache, the received timestamp, TSnew, is checked and
      the packet is accepted if the timestamp is recent enough with
      respect to the receival reception time of the packet, RDnew:

        -Delta < (RDnew - TSnew) < +Delta

       The RDnew and TSnew values SHOULD be stored into the cache as
      RDlast and TSlast.

   o  If the timestamp is NOT within the boundaries but the message is a
      Neighbor Solicitation message that should be responded to by the
      receiver, the receiver MAY respond to the message.  However, if it
      does respond to the message, it MUST NOT create a neighbor cache
      entry.  This allows nodes that have large difference in their
      clocks to still communicate with each other, by exchanging NS/NA
      pairs.

   o  When a message is received from a known peer, i.e., one that
      already has an entry in the cache, the time stamp is checked
      against the previously received SEND message:

        TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz

   o  If TSnew < TSlast, which is possible if packets arrive rapidly and
      out of order, TSlast MUST NOT be updated, i.e., the stored TSlast
      for a given node MUST NOT ever decrease.  Otherwise TSlast SHOULD
      be updated.  Independent on whether TSlast is updated or not,
      RDlast is updated in any case.

5.5 Proxy Neighbor Discovery

   The Target Address in Neighbor Advertisement is required to be equal
   to the source address of the packet, except in the case of proxy
   Neighbor Discovery.  Proxy Neighbor Discovery is not supported by
   this specification; it is planned to be specified in a future
   document.

6. Authorization Delegation Discovery

   Several protocols, including the IPv6 Neighbor Discovery Protocol, protocols (NDP included) allow a node to automatically
   configure itself based on information it learns shortly after
   connecting to a new link.  It is particularly easy to configure
   "rogue" routers on an unsecured link, and it is particularly
   difficult for a node to distinguish between valid and invalid sources
   of information, when the node needs this information before being
   able to communicate with nodes outside of the link.

   Since the newly-connected node cannot communicate off-link, it can
   not cannot
   be responsible for searching information to help validating the
   router(s); however, given a chain of appropriately signed
   certificates, it can check someone else's search results and conclude
   that a particular message comes from an authorized source.  In the
   typical case, a router, which is already connected to beyond the
   link, can (if necessary) communicate with off-link nodes and
   construct such a certificate chain.

   The Secure Neighbor Discovery Protocol mandates a certificate format
   and introduces two new ICMPv6 messages that are used between hosts
   and routers to allow the host to learn a certificate chain with the
   assistance of the router.  Where
   hosts themselves are certified by a trust anchor, these messages MAY
   also optionally be used between hosts to acquire the peer's

6.1 Certificate Format

   The certificate chain.  However, the details chain of such usage are left for
   future specification.

   The Delegation Chain Solicitation (DCS) message is sent by a host
   when it wishes router terminates in a Router
   Authorization Certificate that authorizes a specific IPv6 node to request act
   as a certificate chain between router.  Because authorization chains are not a router and common practice
   in the one of Internet at the host's trust anchors.  The Delegation Chain
   Advertisement (DCA) message time this specification is sent as an answer to the DCS message.
   It MAY be periodically sent to the link-scoped All-Nodes multicast
   address.  These messages are separate from being written, the rest
   chain MUST consist of Neighbor and
   Router Discovery, standard Public Key Certificates (PKC, in order to reduce the effect
   sense of the potentially
   voluminous [18]).  The certificate chain information on other messages.

   The Authorization Delegation Discovery (ADD) process does not exclude
   other forms MUST start from the identity
   of discovering certificate chains. For instance, during
   fast movements mobile nodes may learn information - including a trust anchor that is shared by the
   certificate chains - of host and the next router from a previous router.

6.1 Delegation Chain Solicitation Message Format

   Hosts send Delegation Chain Solicitations in order to prompt routers  This
   allows the host to generate Delegation Chain Advertisements quickly.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address

         An anchor trust for the router's public key in the
   trust anchor.  Note that there MAY be multiple certificates issued by
   a single trust anchor.

6.1.1 Router Authorization Certificate Profile

   Router Authorization Certificates be X.509v3 certificates, as defined
   in RFC 3280 [10], and MUST contain at least one instance of the X.509
   extension for IP address assigned to addresses, as defined in [11].  The parent
   certificates in the sending interface, certificate chain MUST contain one or the
         unspecified address if no more X.509
   IP address is assigned extensions, back up to a trusted party (such as the sending
         interface.

      Destination Address

         Typically user's
   ISP) that configured the All-Routers multicast address, original IP address space block for the Solicited-Node
         multicast address,
   router in question, or delegated the address of the host's default router.

      Hop Limit

         255

   ICMP Fields:

      Type

         TBD <To be assigned by IANA> right to do so for Delegation Chain Solicitation.

      Code

         0

      Checksum someone.  The ICMP checksum [8].

      Identifier

         A 16-bit unsigned integer field, acting as an identifier to
         help matching advertisements to solicitations.  The Identifier
         field
   certificates for intermediate delegating authorities MUST NOT be zero, and its value SHOULD be randomly
         generated.  (This randomness does not need to be
         cryptographically hard, though.  Its purpose contain
   X.509 IP address extension(s) for subdelegations.  The router's
   certificate is to avoid
         collisions.)
      Reserved

         An unused field.  It MUST be initialized to zero signed by the sender
         and MUST be ignored by delegating authority for the receiver.

   Valid Options:

      Trust Anchor

         One or more trust anchors that prefixes
   the client router is willing authorized to accept. to advertise.

   The first (or only) Trust Anchor option X.509 IP address extension MUST contain a DER
         Encoded X.501 Name; see Section 6.3.  If there are more than at least one Trust Anchor options,
   addressesOrRanges element.  This element MUST contain an
   addressPrefix element with an IPv6 address prefix for a prefix the options past
   router or the first one may
         contain intermediate entity is authorized to advertise.  If the
   entity is allowed to route any types of Trust Anchors.

      Future versions prefix, the used IPv6 address prefix
   is the null prefix, 0/0.  The addressFamily element of this protocol may define new option types.
      Receivers the containing
   IPAddrBlocks sequence element MUST silently ignore any options they do not recognize
      and continue processing contain the message.

6.2 Delegation Chain Advertisement Message Format

   Routers send out Delegation Chain Advertisement messages
   periodically, or IPv6 Address Family
   Identifier (0002), as specified in response to [11] for IPv6 prefixes.  Instead
   of an addressPrefix element, the addressesOrRange element MAY contain
   an addressRange element for a Delegation Chain Solicitation.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |           Component           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address

         MUST be a unicast address assigned to the interface from which
         this message is sent.

      Destination Address

         Either the Solicited-Node multicast address range of the receiver or
         the link-scoped All-Nodes multicast address.

      Hop Limit

         255

   ICMP Fields:

      Type

         TBD <To be assigned by IANA> for Delegation Chain
         Advertisement.

      Code

         0

      Checksum prefixes, if more than one
   prefix is authorized.  The ICMP checksum [8].

      Identifier

         A 16-bit unsigned integer field, acting X.509 IP address extension MAY contain
   additional IPv6 prefixes, expressed either as an identifier to
         help matching advertisements to solicitations.  The Identifier
         field addressPrefix or an
   addressRange.

   A SEND node receiving a Router Authorization Certificate MUST be zero for unsolicited advertisements and first
   check whether the certificate's signature was generated by the
   delegating authority.  Then the client MUST NOT
         be zero for solicited advertisements.

      Component

         A 16-bit unsigned integer field, used for informing check whether all the
         receiver which
   addressPrefix or addressRange entries in the router's certificate is being sent, and how many are
         still left to be sent in
   contained within the whole chain.

         A single advertisement MUST be broken into separately sent
         components if there is more than one Certificate option, address ranges in
         order to avoid excessive fragmentation at the IP layer.  Unlike the fragmentation at delegating authority's
   certificate, and whether the IP layer, individual components of addressPrefix entries match any
   addressPrefix entries in the delegating authority's certificate.  If
   an
         advertisement may be stored and used before all addressPrefix or addressRange is not contained within the components
         have arrived; this makes them slightly more reliable and less
         prone to Denial-of-Service attacks.

         The first message in a N-component advertisement has
   delegating authority's prefixes or ranges, the
         Component field set client MAY attempt to N-1,
   take an intersection of the second set to N-2, ranges/prefixes, and so on.
         Zero indicates use that there are no more components coming
   intersection.  If the addressPrefix in this
         advertisement.

         The components MUST the certificate is the null
   prefix, 0/0, such an intersection SHOULD be ordered so used.  (In that case the trust anchor end of
   intersection is the chain parent prefix or range.)  If the resulting
   intersection is empty, the one sent first.  Each certificate sent after
         it can be verified with client MUST NOT accept the previously sent certificates. certificate.

   The
         certificate above check SHOULD be done for all certificates in the chain.  If
   any of the sender comes last.

      Reserved

         An unused field.  It checks fail, the client MUST be initialized NOT accept the certificate.
   The client also needs to zero by perform validation of advertised prefixes as
   discussed in Section 7.3.

   Since it is possible that some PKC certificates used with SEND do not
   immediately contain the sender X.509 IP address extension element, an
   implementation MAY contain facilities that allow the prefix and MUST range
   checks to be ignored relaxed.  However, any such configuration options SHOULD
   be off by default.  That is, the receiver.

   Valid Options:

      Certificate

         One certificate is provided in each Certificate option, to
         establish a (part system SHOULD have a default
   configuration that requires rigorous prefix and range checks.

   The following is an example of a) certificate chain to a certificate chain.  Suppose that
   ispgroup.com is the trust anchor.

      Trust Anchor

         Zero or more Trust Anchor options may be included  The host has this certificate for
   it:

             Certificate 1:
               Issuer: isp_group.com
               Validity: Jan 1, 2004 through Dec 31, 2004
               Subject: isp_group.com
               Extensions:
                 IP address delegation extension:
                    Prefixes: P1, ..., Pk
                 ... possibly other extensions ...
               ... other certificate parameters ...

   When the host attaches then to help
         receivers decide which advertisements are useful a linked served by
   router_x.isp_foo.com, it receives the following certificate chain:

             Certificate 2:
               Issuer: isp_group.com
               Validity: Jan 1, 2004 through Dec 31, 2004
               Subject: isp_foo.com
               Extensions:
                 IP address delegation extension:
                   Prefixes: Q1, ..., Qk
                 ... possibly other extensions ...
               ... other certificate parameters ...

             Certificate 3:
               Issuer: isp_foo.com
               Validity: Jan 1, 2004 through Dec 31, 2004
               Subject: router_x.isp_foo.com
               Extensions:
                 IP address delegation extension:
                   Prefixes R1, ..., Rk
                 ... possibly other extensions ...
               ... other certificate parameters ...

   When processing the three certificates, the usual RFC 3280
   certificate path validation is performed, for them. If
         present, these options MUST appear instance by checking
   for revoked certificates.  In addition, the IP addresses in the first component of a
         multi-component advertisement.

      Future versions of
   delegation extension must be subsumed by the IP addresses in the
   delegation extension in the issuer's certificate.  So in this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
   example, R1, ..., Rs must be subsumed by Q1,...,Qr, and continue processing Q1,...,Qr
   must be subsumed by P1,...,Pk.  If the message.

6.3 Trust Anchor Option certificate chain is valid,
   then router_foo.isp_foo_example.com is authorized to route the
   prefixes R1,...,Rs.

6.2 Certificate Transport

   The format Delegation Chain Solicitation (DCS) message is sent by a host
   when it wishes to request a certificate chain between a router and
   the one of the Trust Anchor option host's trust anchors.  The Delegation Chain
   Advertisement (DCA) message is sent as described in an answer to the
   following: DCS message.
   These messages are separate from the rest of Neighbor and Router
   Discovery, in order to reduce the effect of the potentially
   voluminous certificate chain information on other messages.

   The Authorization Delegation Discovery (ADD) process does not exclude
   other forms of discovering certificate chains.  For instance, during
   fast movements mobile nodes may learn information - including the
   certificate chains - of the next router from a previous router.

   Where hosts themselves are certified by a trust anchor, these
   messages MAY also optionally be used between hosts to acquire the
   peer's certificate chain.  However, the details of such usage are
   left for future specification.

6.2.1 Delegation Chain Solicitation Message Format

   Hosts send Delegation Chain Solicitations in order to prompt routers
   to generate Delegation Chain Advertisements.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     Code      |  Name Type          Checksum             |  Pad  Length
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Name   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address

         A link-local unicast address assigned to the fields are as follows: sending interface,
         or the unspecified address if no address is assigned to the
         sending interface.

      Destination Address

         Typically the All-Routers multicast address, the Solicited-Node
         multicast address, or the address of the host's default router.

      Hop Limit

         255
   ICMP Fields:

      Type

         TBD <To be assigned by IANA> for Trust Anchor.

   Length Delegation Chain Solicitation.

      Code

         0

      Checksum

         The length of the option, (including the Type, Length, Name Type,
      Name Length, and Name fields,) in units of 8 octets.

   Name Type ICMP checksum [9].

      Identifier

         A 16-bit unsigned integer field, acting as an identifier to
         help matching advertisements to solicitations.  The type of the name included in the Name field. This
      specification defines only one legal value for this field:

               1        DER Encoded X.501 Name
               2        FQDN

   Pad Length

      The number of padding octets beyond the end of the Name Identifier
         field but
      within the length specified by the Length MUST NOT be zero, and its value SHOULD be randomly
         generated.  (This randomness does not need to be
         cryptographically hard, though.  Its purpose is to avoid
         collisions.)

      Reserved

         An unused field. Padding octets  It MUST be set initialized to zero by senders the sender
         and MUST be ignored by receivers.

   Name

      When the Name Type field is set to 1, the Name field contains a
      DER encoded X.501 certificate Name, represented and encoded
      exactly as in the matching X.509v3 receiver.

   Valid Options:

      Trust Anchor

         One or more trust anchor certificate.

      When anchors that the Name Type field client is set willing to 2, the Name field contains a
      Fully Qualified Domain Name of the trust anchor, for example,
      "trustanchor.example.com". accept.
         The name is stored as a string, in the
      "preferred name syntax" DNS format, as specified in RFC 1034 [1]
      Section 3.5.  Additionally, the restrictions discussed in RFC 3280
      [11] Section 4.2.1.7 apply.

      All systems first (or only) Trust Anchor option MUST implement support the contain a DER
         Encoded X.501 Name.
      Implementations MAY support Name; see Section 6.2.3.  If there is more than
         one Trust Anchor option, the FQDN name type.

6.4 Certificate Option

   The format of options past the certificate first one may
         contain any types of Trust Anchors.

      Future versions of this protocol may define new option is as described in types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the
   following:

      0                   1                   2                   3
      0 1 message.  All included options MUST
      have a length that is greater than zero.

      ICMP length (derived from the IP length) MUST be 8 or more octets.

6.2.2 Delegation Chain Advertisement Message Format

   Routers send out Delegation Chain Advertisement messages in response
   to a Delegation Chain Solicitation.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     Code      |  Cert Type           Checksum            |  Pad Length
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |           Component           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Certificate ...                            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address

         A link-local unicast address assigned to the fields are as follows: interface from
         which this message is sent.  Note that routers may use multiple
         addresses, and therefore this address not sufficient for the
         unique identification of routers.

      Destination Address

         Either the Solicited-Node multicast address of the receiver or
         the link-scoped All-Nodes multicast address.

      Hop Limit

         255

   ICMP Fields:

      Type

         TBD <To be assigned by IANA> for Certificate.

   Length

      The length of the option, (including the Type, Length, Cert Type,
      Pad Length, and Certificate fields,) in units of 8 octets.

   Cert Type Delegation Chain
         Advertisement.

      Code

         0
      Checksum

         The type of the certificate included in the Certificate field.
      This specification defines only one legal value for this field:

               1        X.509v3 Certificate, ICMP checksum [9].

      Identifier

         A 16-bit unsigned integer field, acting as specified below

   Pad Length an identifier to
         help matching advertisements to solicitations.  The number of padding octets beyond the end of the Certificate Identifier
         field but within the length specified by the Length field. Padding
      octets MUST be set to zero by senders and ignored by receivers.

   Certificate

      When the Cert Type field is set for advertisements sent to 1, the Certificate field
      contains an X.509v3 certificate [11], as described in Section
      6.5.1.

6.5 Router Authorization Certificate Format

   The All-Nodes
         multicast address and MUST NOT be zero for others.

      Component

         A 16-bit unsigned integer field, used for informing the
         receiver which certificate chain of a router terminates in a Router
   Authorization Certificate that authorizes a specific IPv6 node to act
   as a router.  Because authorization chains is being sent, and how many are not a common practice
         still left to be sent in the Internet whole chain.

         A single advertisement MUST be broken into separately sent
         components if there is more than one Certificate option, in
         order to avoid excessive fragmentation at the time this specification is being written, IP layer.  Unlike
         the
   chain MUST consist fragmentation at the IP layer, individual components of standard Public Key Certificates (PKC, an
         advertisement may be stored and used before all the components
         have arrived; this makes them slightly more reliable and less
         prone to Denial-of-Service attacks.

         The first message in a N-component advertisement has the
   sense of [21]).
         Component field set to N-1, the second set to N-2, and so on.
         Zero indicates that there are no more components coming in this
         advertisement.

         The certificates chain components MUST start from be ordered so that the identity
   of a trust anchor that end of
         the chain is shared by the host and one sent first.  Each certificate sent after
         it can be verified with the router.  This
   allows previously sent certificates.  The
         certificate of the host sender comes last.

      Reserved

         An unused field.  It MUST be initialized to anchor trust for the router's public key in zero by the
   trust anchor.  Note that there MAY sender
         and MUST be multiple certificates issued ignored by
   a single trust anchor.

6.5.1 Router Authorization the receiver.

   Valid Options:

      Certificate Profile

   Router Authorization Certificates be X.509v3 certificates, as defined

         One certificate is provided in RFC 3280 [11], and MUST contain at least one instance each Certificate option, to
         establish a (part of the X.509
   extension for IP addresses, as defined in [13].  The parent
   certificates in the a) certificate chain MUST contain one or more X.509
   IP address extensions, back up to the delegating authority (the
   Regional Address Registry or IANA) that delegated the original IP
   address space block.  The certificates for intermediate delegating
   authorities MUST contain X.509 IP address extension(s) for
   subdelegations. a trust anchor.

         The router's certificate is signed by the delegating
   authority for the prefixes the router is authorized to to advertize.

   The X.509 IP address extension MUST contain at least one
   addressesOrRanges element that contains an addressPrefix element with
   an IPv6 address prefix for a prefix of the router trust anchor itself SHOULD NOT be
         included.

      Trust Anchor

         Zero or the intermediate
   entity is authorized more Trust Anchor options may be included to advertize. help
         receivers decide which advertisements are useful for them.  If
         present, these options MUST appear in the entity is allowed to route first component of a
         multi-component advertisement.

      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any prefix, options they do not recognize
      and continue processing the used IPv6 address prefix message.  All included options MUST
      have a length that is greater than zero.

      ICMP length (derived from the null prefix, 0/0. IP length) MUST be 8 or more octets.

6.2.3 Trust Anchor Option

   The addressFamily element format of the containing IPAddrBlocks sequence
   element MUST contain Trust Anchor option is described in the IPv6 AFI (0002), following:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |  Name Type    |  Pad  Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Name ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the fields are as specified in [13] follows:

   Type

      TBD <To be assigned by IANA> for
   IPv6 prefixes.  Instead Trust Anchor.

   Length

      The length of an addressPrefix element, the
   addressesOrRange element MAY contain an addressRange element for a
   range option, (including the Type, Length, Name Type,
      Name Length, and Name fields,) in units of prefixes, if more than one prefix is authorized. 8 octets.

   Name Type

      The X.509
   IP address extension MAY contain additional IPv6 prefixes, expressed
   either as an addressPrefix or an addressRange.

   A SEND node receiving a Router Authorization Certificate MUST first
   check whether the certificate's signature was generated by type of the
   delegating authority.  Then name included in the client MUST check whether all Name field.  This
      specification defines only one legal value for this field:

               1        DER Encoded X.501 Name
               2        FQDN
   Pad Length

      The number of padding octets beyond the
   addressPrefix or addressRange entries in end of the router's certificate are
   contained Name field but
      within the address ranges in length specified by the delegating authority's
   certificate, Length field.  Padding octets
      MUST be set to zero by senders and whether the addressPrefix entries match any
   addressPrefix entries in ignored by receivers.

   Name

      When the delegating authority's certificate.  If
   an addressPrefix or addressRange Name Type field is not contained within the
   delegating authority's prefixes or ranges, the client MAY attept set to
   take an intersection of 1, the ranges/prefixes, Name field contains a
      DER encoded X.501 certificate Name, represented and use that
   intersection.  If the addressPrefix encoded
      exactly as in the certificate is the null
   prefix, 0/0, such an intersection SHOULD be used.  (In that case matching X.509v3 trust anchor certificate.

      When the
   intersection Name Type field is set to 2, the parent prefix or range.)  If Name field contains a
      Fully Qualified Domain Name of the resulting
   intersection trust anchor, for example,
      "trustanchor.example.com".  The name is empty, stored as a string, in the client
      "preferred name syntax" DNS format, as specified in RFC 1034 [1]
      Section 3.5.  Additionally, the restrictions discussed in RFC 3280
      [10] Section 4.2.1.7 apply.

      All systems MUST NOT accept implement support the certificate. DER Encoded X.501 Name.
      Implementations MAY support the FQDN name type.

6.2.4 Certificate Option

   The above check SHOULD format of the certificate option is described in the following:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |  Cert Type    |  Pad Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Certificate ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the fields are as follows:

   Type

      TBD <To be done assigned by IANA> for all certificates in Certificate.

   Length

      The length of the chain
   received through DCA messages.  If any option, (including the Type, Length, Cert Type,
      Pad Length, and Certificate fields,) in units of 8 octets.

   Cert Type

      The type of the checks fail, certificate included in the client
   MUST NOT accept Certificate field.
      This specification defines only one legal value for this field:

               1        X.509v3 Certificate, as specified below

   Pad Length

      The number of padding octets beyond the certificate.

   Since it is possible that some PKC certificates used with SEND do not
   immediately contain end of the X.509 IP address extension element, an
   implementation MAY contain facilities that allow Certificate
      field but within the prefix and range
   checks to be relaxed. However, any such configuration options SHOULD
   be off length specified by default.  That is, the system SHOULD have a default
   configuration that requires rigorious prefix Length field.
      Padding octets MUST be set to zero by senders and range checks.

6.6 ignored by
      receivers.

   Certificate

      When the Cert Type field is set to 1, the Certificate field
      contains an X.509v3 certificate [10], as described in Section
      6.1.1.

6.2.5 Processing Rules for Routers

   Routers SHOULD possess a key pair and a certificate from at least one
   certificate authority.

   A router MUST silently discard any received Delegation Chain
   Solicitation messages that do not satisfy all of the following
   validity checks:

   o  The IP Hop Limit field MUST have a value of 255, i.e., the packet
      could not possibly have been forwarded by a router.  All requirements listed in Section 6.2.1 are fulfilled.

   o  If the message includes an IP Authentication Header, the message
      authenticates correctly.

   o  ICMP Checksum is valid.

   o  ICMP Code is 0.

   o  ICMP length (derived from the IP length) is 8 or more octets.

   o  Identifier field is non-zero.

   o  All included options have a length that is greater than zero.

   The contents of the Reserved field, and of any unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to the protocol
   may specify the contents of the Reserved field or add new options;
   backward-incompatible changes may use different Code values.  The
   contents of any defined options that are not specified to be used
   with Router Solicitation messages MUST be ignored and the packet
   processed in the normal manner.  The only defined option that may
   appear is the Trust Anchor option.  A solicitation that passes the
   validity checks is called a "valid solicitation".

   Routers MAY SHOULD send unsolicited Delegation Chain Advertisements for
   their configured trust anchor(s).  When such advertisements are sent,
   their timing MUST follow in response to valid solicitations
   received on an advertising interface.  If the rules given for Router Advertisements in
   RFC 2461 [6].  The only defined options that may appear are the
   Certificate and Trust Anchor options. At least one Certificate option
   MUST be present.  Router SHOULD also include at least one Trust
   Anchor option to indicate the trust anchor on which the Certificate
   is based.

   In addition to sending periodic, unsolicited advertisements, a router
   sends advertisements in response to valid solicitations received on
   an advertising interface.  If the source address source address in the
   solicitation was the unspecified address, the router MUST send the
   response to the link-scoped All-Nodes multicast address.  If the
   source address was a unicast address, the router MUST send the
   response to the Solicited-Node multicast address corresponding to the
   source address.

   In  Routers SHOULD NOT send Delegation Chain
   Advertisements more than MAX_DCA_RATE times within a solicited-for second.  When
   there are more solicitations than this, the router SHOULD send the
   response to the All-Nodes multicast address regardless of the source
   address that appeared in the solicitation.

   In an advertisement, the router SHOULD include suitable Certificate
   options so that a delegation chain to the solicited trust anchor can
   be established.  The anchor is identified by the Trust Anchor option.
   If the Trust Anchor option is represented as a DER Encoded X.501
   Name, then the Name must be equal to the Subject field in the
   anchor's certificate.  If the Trust Anchor option is represented as
   an FQDN, the FQDN must be equal to an FQDN in the subjectAltName
   field of the anchor's certificate.  The router SHOULD include the
   Trust Anchor option(s) in the advertisement for which the delegation
   chain was found.

   If the router is unable to find a chain to the requested anchor, it
   SHOULD send an advertisement without any certificates.  In this case
   the router SHOULD include the Trust Anchor options which were
   solicited.

   Rate limiting of Delegation Chain Advertisements is performed as
   specified for Router Advertisements in RFC 2461 [6].

6.7

6.2.6 Processing Rules for Hosts

   Hosts SHOULD possess the public key and trust anchor name of at least
   one certificate authority, they SHOULD possess their own key pair,
   and they MAY posses a certificate from the above mentioned
   certificate authority.

   A host MUST silently discard any received Delegation Chain
   Advertisement messages that do not satisfy all of the following
   validity checks:

   o  IP Source Address MUST be a unicast address.  Note that routers
      may use multiple addresses, and therefore this address not
      sufficient for the unique identification of routers.

   o  IP Destination Address MUST be either the link-scoped All-Nodes
      multicast address or the Solicited-Node multicast address
      corresponding to one of the unicast addresses assigned to the
      host.

   o  The IP Hop Limit field MUST have a value of 255, i.e., the packet
      could not possibly have been forwarded by a router.  All requirements listed in Section 6.2.2 are fulfilled.

   o  If the message includes an IP Authentication Header, the message
      authenticates correctly.

   o  ICMP Checksum is valid.

   o  ICMP Code is 0.

   o  ICMP length (derived from the IP length) is 16 or more octets.

   o  All included options have a length that is greater than zero.

   The contents of the Reserved field, and of any unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to the protocol
   may specify the contents of the Reserved field or add new options;
   backward-incompatible changes may use different Code values.  The
   contents of any defined options that are not specified to be used
   with Delegation Chain Advertisement messages MUST be ignored and the
   packet processed in the normal manner.  The only defined options that
   may appear are the Certificate and Trust Anchor options.  An
   advertisement that passes the validity checks is called a "valid
   advertisement".

   Hosts SHOULD store certificate chains retrieved in Delegation Chain
   Discovery messages if they start from an anchor trusted by the host.
   The certificates certificate chains SHOULD be verified, as defined in Section
   6.5, 6.1,
   before storing them.  Routers are required to MUST send the certificates one by one,
   starting from the trust anchor end of the chain.  Except for
   temporary purposes to allow for message loss and reordering, hosts
   SHOULD NOT store certificates received in a Delegation Chain
   Advertisement unless they contain a certificate which can be
   immediately verified either to the trust anchor or to a certificate
   which has been verified earlier.

   Note that it may be useful to cache this information and implied
   verification results for use over multiple attachments to the
   network.

   When an interface becomes enabled, a

   The host may be unwilling to wait
   for the next unsolicited Delegation Chain Advertisement.  To obtain
   such advertisements quickly, has a host MAY transmit up need to
   MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages, each
   separated by at least RTR_SOLICITATION_INTERVAL seconds.  Delegation
   Chain Solicitations MAY be sent after any of the following events:

   o  The interface is initialized at system startup time.

   o  The interface is reinitialized after a temporary interface failure
      or after being temporarily disabled by system management.

   o  The system changes from being a router to being a host, by having
      its IP forwarding capability turned off by system management.

   o  The host attaches to a link for the first time.

   o  A movement has been indicated by lower layers or has been inferred
      from changed information in retrieve a Router Advertisement.

   o  The host re-attaches to delegation chain when a link after being detached for some time.

   o  A Router
   Advertisement has been received with a public key that is not stored
   in the hosts' cache of certificates, or there is no authorization
   delegation chain to the host's trust anchor.  In these situations,
   the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain
   Solicitation messages, each separated by at least DCS_INTERVAL
   seconds.

   Delegation Chain Solicitations SHOULD NOT be sent if the host has a
   currently valid certificate chain from a reachable router to a trust
   anchor.

   When soliciting certificates for a router, a host MUST send
   Delegation Chain Solicitations either to the All-Routers multicast
   address, if it has not selected a default router yet, or to the
   default router's IP address, if it has already been selected.

   If two hosts want to establish trust with the DCS and DCA messages,
   the DCS message SHOULD be sent to the Solicited-Node multicast
   address of the receiver.  The advertisements SHOULD be sent as
   specified above for routers.  However, the exact details are left for
   a future specification.

   Delegation Chain Solicitations SHOULD be rate limited and timed
   similarly with Router Solicitations, as specified in RFC 2461 [6].

   When processing possible advertisements sent as responses to a
   solicitation, the host MAY prefer to process first those
   advertisements with the same Identifier field value as in the
   solicitation.  This makes Denial-of-Service attacks against the
   mechanism harder (see Section 11.3). 9.3).

7. Securing Neighbor Discovery with SEND

   This section describes how to Addressing

7.1 CGA Addresses

   Nodes that use the mechanisms from Section 5,
   Section 6, and the reference [26] stateless address autoconfiguration, SHOULD generate a
   new CGA as specified in order to provide security Section 4 of [12] for
   Neighbor Discovery.

   There is no requirement that each new
   autoconfiguration run.  The nodes MAY continue to use both Secure Neighbor Discovery
   (as described in this Section) the same public
   key and Secure Router Discovery (as
   described in Section 8.  They modifier, and start the process from Step 4.

   By default, a SEND-enabled node SHOULD use only CGAs as its own
   addresses.  Other types of addresses MAY be used indepedently.

7.1 Neighbor Solicitation Messages

   All Neighbor Solicitation messages are protected with SEND.

7.1.1 Sending Secure Neighbor Solicitations

   Secure Neighbor Solicitation messages are sent as described in RFC
   2461 and 2462, with the additional requirements testing,
   diagnostics or other purposes.  However, this document does not
   describe how to choose between different types of addresses for
   different communications.  A dynamic selection can be provided by an
   API, such as listed in the
   following:

      All Neighbor Solicitation messages sent MUST contain one defined in [22].

7.2 Redirect Addresses

   If the Nonce,
      Timestamp, and Signature options, Target Address and MAY contain Destination Address fields in the CGA option.
      The Signature option ICMP
   Redirect message are equal, then this message is used to inform hosts
   that a destination is in fact a neighbor.  In this case the receiver
   MUST be constructed with verify that the sender's key
      pair, using given address falls within the configured authorization method(s), and if
      applicable, using range defined by
   the trust anchor and/or minSec value as
      configured.

7.1.2 Receiving Secure Neighbor Solicitations

   Received Neighbor Solicitation router's certificate.  Redirect messages are processed as described in failing this check MUST
   be silently discarded.

   Note that RFC 2461 and 2462, with rules prevent a bogus router from sending a
   Redirect message when the additional SEND-related requirements host is not using the bogus router as
   listed in a
   default router.

7.3 Advertised Prefixes

   The router's certificate defines the following:

      Neighbor Solicitation messages received without address range(s) that it is
   allowed to advertise.  Upon processing a Prefix Information option
   within a Router Advertisement, nodes SHOULD verify that the Nonce,
      Timestamp, or Signature prefix
   specified in this option falls within the range defined by the
   certificate, if the certificate contains a prefix extension.  Options
   failing this check MUST be silently discarded.  The
      Signature option MUST be constructed with

   Nodes SHOULD use one of the expected
      authorization method(s), certified prefixes for stateless
   autoconfiguration.  If none of the used key being within advertised prefixes match, then
   either there is a configuration problem or the configured
      minimum (and maximum) allowable key size, and if applicable, using advertising router is
   an acceptable trust anchor and/or minSec value.

7.2 Neighbor Advertisement Messages

   All Neighbor Advertisement messages are protected with SEND.

7.2.1 Sending Secure Neighbor Advertisements
   Secure Neighbor Advertisement messages are sent as described in RFC
   2461 attacker, and 2462, with the additional requirements as listed in the
   following:

      All Neighbor Advertisement messages sent host MUST be sent with use a different advertising router as
   its default router (if available).  If the
      Timestamp and Signature options and MAY be sent with node is performing
   stateful autoconfiguration, it SHOULD check the CGA
      option. The Signature option MUST be constructed with address provided by
   the sender's
      key pair, setting DHCP server against the authorization method certified prefixes and additional
      information as configured.

      Neighbor Advertisements sent in response to a Neighbor
      Solicitation MUST additionally contain a copy of NOT use the Nonce option
      included in
   address if the solicitation.

7.2.2 Receiving Secure Neighbor Advertisements

   Received Neighbor Advertisement messages are processed as described
   in RFC 2461 and 2462, with prefix is not certified.

   In any case, the additional SEND-related requirements
   as listed in user should inform the following:

      Any eighbor Advertisement messages received without network operator upon
   receiving an address or prefix outside the Timestamp certified range, since
   this is either a misconfiguration or Signature options MUST be silently discarded.  The Signature
      option MUST an attack.

   If the network operator wants to constrain which routers support
   particular prefixes, routers SHOULD be constructed configured with certificates
   having prefixes listed in the expected authorization
      method(s), the used key being within the prefix extension.  Routers so
   configured minimum (and
      maximum) allowable key size, and if applicable, using an
      acceptable trust anchor and/or minSec value.

      Received Neighbor Advertisements sent to a unicast destination
      address without a Nonce option MUST be silently discarded.

7.3 Other Requirements

   Upon receiving a message advertise exactly the prefixes for which the receiver has no certificate
   chain to a trust anchor, the receiver MAY use Authorization
   Delegation Discovery to learn the certificate chain of the peer.

   Nodes they are
   certified.

   Network operators that use stateless address autoconfiguration, SHOULD generate a
   new CGA as specified in Section 4 of [26] for each new
   autoconfiguration run.  The nodes MAY continue do not want to use the same public
   key and modifier, and start constrain particular routers to
   specific prefixes SHOULD configure routers with certificates
   containing either the process from Step 4. null prefix or no prefix extension at all.

7.4 Limitations

   This specification does not address the protection of Neighbor
   Discovery NDP packets for
   nodes that are configured with a static address (e.g., PREFIX::1).
   Future certificate chain based authorization specifications are
   needed for such nodes.

   It is outside the scope of this specification to describe the use of
   trust anchor authorization between nodes with dynamically changing
   addresses.  Such dynamically changing addresses may be the result of
   stateful or stateless address autoconfiguration, or through the use
   of RFC 3041 [9] [17] addresses.  If the CGA method is not used, nodes
   would be required to exchange certificate chains that terminate in a
   certificate authorizing a node to use an IP address having a
   particular interface identifier.  This specification does not specify
   the format of such certificates, since there are currently a few
   cases where such certificates are required by the link layer and it
   is up to the link layer to provide certification for the interface
   identifier.  This may be the subject of a future specification.  It
   is also outside the scope of this specification to describe how
   stateful address autoconfiguration works with the CGA method.

8. Securing Router Discovery with SEND

   This section describes how

   The Target Address in Neighbor Advertisement is required to be equal
   to use the mechanisms from Section 5,
   Section 6, and source address of the reference [26] packet, except in order to provide security for
   Router the case of proxy
   Neighbor Discovery.

8.1 Router Solicitation Messages

   All Router Solicitation messages are protected with SEND.

8.1.1 Sending Secure Router Solicitations

   Secure Router Solicitation messages are sent as described  Proxy Neighbor Discovery is not supported by
   this specification; it is planned to be specified in RFC
   2461, with a future
   document.

8. Transition Issues

   During the additional requirements transition to secure links or as listed in the following:

      Router Solicitation messages sent a policy consideration,
   network operators may want to run a particular link with an unspecified source
      address MUST have the Nonce a mixture of
   secure and Timestamp options.

      Other Router Solicitations MUST have insecure nodes.  Nodes that support SEND SHOULD support
   the Nonce, Timestamp, use of SEND and
      Signature options.  The Signature option MUST be configured with the sender's key pair, setting legacy NDP at the authorization method and
      additional information as is configured.

8.1.2 Receiving Secure Router Solicitations

   Received Router Solicitation same time.

   In a mixed environment, SEND nodes receive both secure and insecure
   messages are processed as described in
   RFC 2461, with but give priority to "secured" ones.  Here, the additional SEND-related requirements "secured"
   messages are ones that contain a valid signature option, as listed in
   the following:

      Router Solicitation message sent with an unspecified source
      address specified
   above, and without the Nonce or Timestamp options MUST be
      silently discarded.

      Router Solicitation "insecure" messages received with another type of source
      address but without are ones that contain no signature
   option.

   SEND nodes send only secured messages.  Legacy Neighbor Discovery
   nodes will obviously send only insecure messages.  Per RFC 2461 [7],
   such nodes will ignore the Nonce, Timestamp, or Signature unknown options
      MUST be silently discarded.

      The Signature option MUST be constructed with the configured
      authorization method(s), the used key being within the configured
      minimum (and maximum) allowable key size, and if applicable, using
      an acceptable trust anchor and/or minSec value.

      The configured authorization methods MUST include will treat secured
   messages in the trust anchor
      authorization method, same way as they treat insecure ones.  Secured and MAY be additionally configured to
      require CGA authorization.

8.2 Router Advertisement Messages

   All Router Advertisement messages are protected with SEND.

8.2.1 Sending Secure Router Advertisements

   Secure Router Advertisement messages are sent
   insecure nodes share the same network resources, such as described prefixes and
   address spaces.

   In a mixed environment SEND nodes follow the protocols defined in RFC
   2461,
   2461 and RFC 2462 with the additional requirements as listed in the following: following exceptions:

   o  All Router Advertisement messages solicitations sent by SEND nodes MUST contain be secured.

   o  Unsolicited advertisements sent by a Timestamp
      and Signature options.  The Signature option SEND node MUST be configured to
      protect the advertisement with the trust anchor authorization
      method and MAY be configured secured.

   o  A SEND node MUST send a secured advertisement in response to additionally protect it with the
      CGA authorization method.

      Router a
      secured solicitation.  Advertisements sent in response to a Router Solicitation an
      insecure solicitation MUST be secured as well, but MUST NOT
      contain a copy of the Nonce option included in option.

   o  A SEND node that uses the
      solicitation.

8.2.2 Receiving Secure Router Advertisements

   Received Router Advertisement messages are processed CGA authorization method for protecting
      Neighbor Solicitations SHOULD perform Duplicate Address Detection
      as described in
   RFC 2461, with follows.  If Duplicate Address Detection indicates the additional SEND-related requirements as listed
      tentative address is already in
   the following:

      Router Advertisement messages received without the Timestamp and
      Signature options MUST be silently discarded.

      Received Router Advertisements sent to use, generate a unicast destination new tentative CGA
      address.  If after 3 consecutive attempts no non-unique address without
      was generated, log a Nonce option MUST be silently discarded.

      The Signature option MUST be constructed with the configured
      authorization method(s), the used key being within the configured
      minimum (and maximum) allowable key size, system error and if applicable, using give up attempting to
      generate an acceptable trust anchor and/or minSec value.

      The configured authorization methods MUST include address for that interface.

      When performing Duplicate Address Detection for the trust anchor
      authorization method, first
      tentative address, accept both secured and MAY be additionally configured to
      require CGA authorization.

8.3 Redirect Messages

   All Redirect messages are protected with SEND.

8.3.1 Sending Redirects
   Secure Redirect messages are sent as described in RFC 2461, with the
   additional requirements insecure Neighbor
      Advertisements and Solicitations received as listed in response to the following:

      All Redirect messages sent MUST contain
      Neighbor Solicitations.  When performing Duplicate Address
      Detection for the Timestamp second or third tentative address, ignore
      insecure Neighbor Advertisements and
      Signature options. Solicitations.

   o  The Signature node SHOULD have a configuration option MUST be configured that causes it to use
      ignore insecure advertisements even when performing Duplicate
      Address Detection for the trust anchor authorization method, and MAY first tentative address.  This
      configuration option SHOULD be additionally
      configured to use the CGA method.

8.3.2 Receiving Redirects

   Received Redirect messages are processed as described in RFC 2461,
   with the additional SEND-related requirements as listed disabled by default.  This is
      recovery mechanism, in case attacks against the
   following:

      Redirect messages received without the Timestamp or Signature
      options MUST be silently discarded. first address
      become common.

   o  The Signature option Neighbor Cache, Prefix List and Default Router list entries
      MUST be constructed with have a secured/insecure flag that indicates whether the configured
      authorization method(s),
      message that caused the used key being within creation or last update of the configured
      minimum (and maximum) allowable key size, and if applicable, using
      an acceptable trust anchor and/or minSec value.

      The configured authorization methods entry was
      secured or insecure.  Received insecure messages MUST include the trust anchor
      authorization method, and MAY be additionally configured NOT cause
      changes to
      require CGA authorization.

      The receiver MUST verify that existing secured entries in the Redirect message comes from Neighbor Cache, Prefix
      List or Default Router List.  Received secured messages cause an
      IP address to which the host may have earlier sent
      update of the packet matching entries and flagging of them as secured.

   o  The conceptual sending algorithm is modified so that an insecure
      router is selected only if there is no reachable SEND router for
      the Redirect message now partially returns. prefix.  That is, the source
      address of the Redirect message must be the algorithm for selecting a default router or the
      on-link destination host for traffic sent
      favors reachable SEND routers over reachable non-SEND ones.

   o  A SEND node SHOULD have a configuration option that causes it to
      ignore all insecure Neighbor Solicitation and Advertisement,
      Router Solicitation and Advertisement, and Redirect messages.
      This can be used to enforce SEND-only networks.

9. Security Considerations

9.1 Threats to the destination of
      the returned packet.  If this is Local Link Not Covered by SEND

   SEND does not provide confidentiality for NDP communications.

   SEND does not compensate for an insecure link layer.  For instance,
   there is no assurance that payload packets actually come from the case,
   same peer that the message MUST NDP was run against.

   There may be
      silently discarded.

      This step prevents a bogus router from sending a Redirect message
      when no cryptographic binding in SEND between the host is not using link layer
   frame address and the bogus router as a default router.

8.4 Other Requirements

   Hosts SHOULD use Authorization Delegation Discovery IPv6 address.  On an insecure link layer that
   allows nodes to learn spoof the
   certificate chain of their default router (or peer host), as
   explained in Section 6.  The receipt link layer address of other nodes, an
   attacker could disrupt IP service by sending out a protected Router Neighbor
   Advertisement message for which no router Authorization Certificate
   and certificate chain is available triggers Authorization Delegation
   Discovery.

9. Co-Existence having the source address on the link layer frame of SEND a
   victim, a valid CGA address and non-SEND nodes

   During the transition to secure links or as a policy consideration,
   network operators may want valid signature corresponding to run
   itself, and a particular link with Target Link-layer Address extension corresponding to
   the victim.  The attacker could then proceed to cause a mixture of
   secure and insecure nodes.  Nodes that support SEND SHOULD support
   the use of SEND and traffic
   stream to bombard the legacy Neighbor Discovery Protocol at victim in a DoS attack.  This attack cannot be
   prevented just by securing the
   same time.

   In link layer.

   Even on a mixed environment, SEND nodes receive both secure and insecure
   messages but give priority to "secured" ones.  Here, the "secured"
   messages are ones link layer, SEND does not require that contain a valid signature option, as specified
   above, the addresses
   on the link layer and "insecure" messages are ones Neighbor Advertisements correspond to each
   other.  However, it is RECOMMENDED that contain no signature
   option.

   SEND nodes send only secured messages.  Legacy such checks be performed
   where this is possible on the given link layer technology.

   Prior to participating in Neighbor Discovery and Duplicate Address
   Detection, nodes will obviously send only insecure messages. Such nodes will (as
   per RFC 2461 [6]) ignore must subscribe to the unknown options link-scoped All-Nodes
   Multicast Group and will treat secured
   messages in the same way as they treat insecure ones.  Secured and
   insecure nodes share Solicited-Node Multicast Group for the same network resources, such as prefixes and
   address spaces.

   In a mixed environment SEND routers and hosts follow the protocols
   defined in that they are claiming for their addresses; RFC 2461 and RFC 2462 with [7].
   Subscribing to a multicast group requires that the following exceptions:

      All solicitations sent by SEND nodes MUST be secured.

      Unsolicited Neighbor and Router Advertisements sent by use MLD
   [16].  MLD contains no provision for security.  An attacker could
   send an MLD Done message to unsubscribe a SEND
      router MUST be secured.

      Secured solicitations MUST contain victim from the Nonce option. Secured
      advertisements sent in response
   Solicited-Node Multicast address.  However, the victim should be able
   to detect such an attack because the router sends a secured solicitation MUST
      contain a copy of
   Multicast-Address-Specific Query to determine whether any listeners
   are still on the Nonce option address, at which point the victim can respond to
   avoid being dropped from the solicitation.
      Unsolicited advertisements and ones sent in response group.  This technique will work if the
   router on the link has not been compromised.  Other attacks using MLD
   are possible, but they primarily lead to an
      insecure solicitation MUST NOT extraneous (but not
   overwhelming) traffic.

9.2 How SEND Counters Threats to NDP

   The SEND protocol is designed to counter the threats to NDP, as
   outlined in [25].  The following subsections contain a regression of
   the Nonce option.

      A SEND node that uses protocol against the CGA authorization method for protecting
      Neighbor Solicitations SHOULD perform Duplicate Address Detection
      as follows.  If Duplicate Address Detection indicates threats, to illustrate what aspects of
   the
      tentative address protocol counter each threat.

9.2.1 Neighbor Solicitation/Advertisement Spoofing

   This threat is already defined in use, generate Section 4.1.1 of [25].  The threat is that
   a new tentative CGA
      address.  If after 3 consecutive attempts no non-unique address
      was generated, log spoofed message may cause a system error and give up attempting to
      generate an address for that interface.

      When performing Duplicate Address Detection for the first
      tentative address, accept both secured and insecure false entry in a node's Neighbor
      Advertisements and Solicitations received Cache.
   There are two cases:

   1.  Entries made as response to the a side effect of a Neighbor Solicitations.  When performing Duplicate Solicitation or
       Router Solicitation.  A router receiving a Router Solicitation
       with a firm IPv6 source address and a Target Link-Layer Address
      Detection
       extension inserts an entry for the second or third tentative address, ignore
      insecure IPv6 address into its Neighbor Advertisements and Solicitations.

      The node SHOULD have
       Cache.  Also, a configuration option that causes it to
      ignore insecure advertisements even when node performing Duplicate Address Detection for the first tentative address. This
      configuration option SHOULD be disabled by default. (This is
      recovery mechanism for the unlikely case (DAD)
       that attacks against receives a Neighbor Solicitation for the
      first same address become common.)

      The Neighbor Cache, Prefix List and Default Router list entries
      MUST have a secured/insecure flag that indicates whether
       regards the
      message that caused situation as a collision and ceases to solicit for
       the creation or last update of address.

       In either case, SEND counters these treats by requiring the entry was
      secured or insecure.  Received insecure messages MUST NOT cause
      changes
       Signature and CGA options to existing secured entries be present in the Neighbor Cache, Prefix
      List or Default such solicitations.

       SEND nodes can send Router List.  Received secured Solicitation messages cause an
      update of the matching entries with a CGA
       source address and flagging of them as secured.

      The conceptual sending algorithm is modified so that an insecure
      router is selected only if there is no reachable SEND router for a CGA option, which the prefix.  That is, router can verify, so
       the algorithm for selecting Neighbor Cache binding is correct.  If a default router
      favors reachable SEND routers over reachable non-SEND ones.

      A SEND node SHOULD have must send
       a configuration option that causes it to
      ignore all insecure ND, RD and Redirect messages. (This can be
      used to enforce SEND-only networks.)

10. Performance Considerations

   The computations related to the Signature option are computationally
   relatively expensive.  In the application which Signature option has
   been designed for, however, Router Solicitation with the nodes typically have unspecified address, the need to
   perform only a few signature operations router
       will not update its Neighbor Cache, as they enter a link, and a
   few operations per RFC 2461.

   2.  Entries made as they find a new on-link peer with which to
   communicate.

   Routers are required to perform a larger number result of operations,
   particularly when a Neighbor Advertisement message.
       SEND counters this threat by requiring the frequency of router advertisements is high due Signature and CGA
       options to mobility requirements.  Still, the number of required signature
   operations be present in these advertisements.

   See also Section 9.2.5, below, for discussion about replay protection
   and timestamps.

9.2.2 Neighbor Unreachability Detection Failure

   This attack is on the order described in Section 4.1.2 of [25].  SEND counters
   this attack by requiring a few dozen ones per second, some of
   which can be precomputed as discussed below.  A large number of
   router solicitations may cause higher demand for performing
   asymmetric operations, although RFC 2461 limits the rate at which
   responses node responding to solicitations can be sent.

   Signatures related Neighbor Solicitations
   sent as NUD probes to the use of the include a Signature option be precomputed
   for Multicast Neighbor and Router Advertisements. Typically,
   solicited advertisements are sent proof of
   authorization to use the interface identifier in the unicast address from which being
   probed.  If these prerequisites are not met, the solicitation was sent.  Given that node performing NUD
   discards the IPv6 header is covered responses.

9.2.3 Duplicate Address Detection DoS Attack

   This attack is described in Section 4.1.3 of [25].  SEND counters
   this attack by requiring the signature, it is typically not possible Neighbor Advertisements sent as
   responses to precompute
   solicited-for advertisements.

11. Security Considerations

11.1 Threats DAD to include a Signature option and proof of
   authorization to use the Local Link Not Covered by SEND

   SEND does not compensate for an insecure link layer.  In particular,
   there is no cryptographic binding interface identifier in SEND between the link layer
   frame address and being
   tested.  If these prerequisites are not met, the IPv6 address.  On an insecure node performing DAD
   discards the responses.

   When a SEND node is used on a link layer that
   allows nodes also connects to spoof the link layer address of other non-SEND
   nodes, an
   attacker could disrupt IP service by sending out a the SEND node ignores any insecure Neighbor
   Advertisement having Solicitations or
   Advertisements that may be send by the source address on non-SEND nodes.  This protects
   the link layer frame SEND node from DAD DoS attacks by non-SEND nodes or attackers
   simulating to non-SEND nodes, at the cost of a
   victim, potential address
   collision between a valid CGA SEND node and non-SEND node.  The probability and
   effects of such an address collision are discussed in [12].

9.2.4 Router Solicitation and a valid signature corresponding Advertisement Attacks

   These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
   and 4.2.7 of [25].  SEND counters these attacks by requiring Router
   Advertisements to
   itself, contain a Signature option, and that the signature
   is calculated using the public key of a Target Link-layer Address extension corresponding node that can prove its
   authorization to route the victim.  The attacker could then proceed to cause a traffic
   stream to bombard the victim subnet prefixes contained in any Prefix
   Information Options.  The router proves its authorization by showing
   a DoS attack.  To certificate containing the specific prefix or the indication that
   the router is allowed to route any prefix.  A Router Advertisement
   without these protections is discarded.

   SEND does not protect against brute force attacks on the router, such
   as DoS attacks, link layer security MUST be used.  An example or compromise of such
   for 802 type networks the router, as described in Sections
   4.4.2 and 4.4.3 of [25].

9.2.5 Replay Attacks

   This attack is port-based access control defined described in the
   802.1X standard [34].

   Specifically, the 802.1X standard provides a mechanism by which a
   nodes can be authenticated to a particular point Section 4.3.1 of attachment to a
   LAN (called a "port" [25].  SEND protects
   against attacks in the standard). If the MAC on frames sent Router Solicitation/Router Advertisement and
   Neighbor Solicitation/Neighbor Advertisement transactions by
   including a
   node does not correspond to Nonce option in the MAC of solicitation and requiring the node originally
   authenticated
   advertisement to this port, then include a matching option.  Together with the point
   signatures this forms a challenge-response protocol.  SEND protects
   against attacks from unsolicited messages such as Neighbor
   Advertisements, Router Advertisements, and Redirects by including a
   Timestamp option.  A window of attachment drops vulnerability for replay attacks
   exists until the
   frames. Authorization to use timestamp expires.

   When timestamps are used, SEND nodes are protected against replay
   attacks as long as they cache the port is determined state created by the MAC
   address of the node that originally authenticated to message
   containing the port. timestamp.  The
   way 802.1X protects against this attack is that, if a cached state allows the node
   authenticated to a particular port attempts to spoof the MAC address
   of another node,
   protect itself against replayed messages.  However, once the port will drop node
   flushes the frames. Naturally, this
   requires that all ports state for whatever reason, an attacker can re-create the
   state by which replaying an old message while the timestamp is still valid.
   Since most SEND nodes can attach are likely to the LAN use
   802.1X authentication, and that all node physically attach through a
   port, fairly coarse grained
   timestamps, as explained in Section 5.3.1, this may affect some
   nodes.

9.2.6 Neighbor Discovery DoS Attack

   This attack is described in Section 4.3.2 of [25].  In this attack,
   the case with 802.3 switched LAN. For shared media, such
   as multiple nodes authenticated through attacker bombards the same 802.11 AP (which
   acts as a single port router with packets for all nodes), other measures are necessary,
   since an attacker fictitious
   addresses on the wireless link can spoof the MAC address of a
   victim on link, causing the same wireless link.

   802.1X router to busy itself with
   performing Neighbor Solicitations for addresses that do not exist.
   SEND does not provide protection for the layer 2 frame - layer 3
   packet address binding in traffic (that is, real time filtering to
   check this binding), and neither does SEND.  802.1X provides
   authentication and filtering threat because it can be addressed by
   techniques such as rate limiting Neighbor Solicitations, restricting
   the amount of MAC address to port; SEND provides
   protection state reserved for the layer 2 - layer 3 binding information unresolved solicitations, and clever
   cache management.  These are all techniques involved in the implementing
   Neighbor Discovery packet, via the CGA address (authorization to use
   the address via the public key) and the signature on the packet
   (authentication router.

9.3 Attacks against SEND Itself

   The CGAs have a 59-bit hash value.  The security of contents as from authorized IP address possessor).

   Prior to participating the CGA mechanism
   has been discussed in Neighbor Discovery [12].

   Some Denial-of-Service attacks against NDP and Duplicate Address
   Detection, nodes must subscribe to the link-scoped All-Nodes
   Multicast Group and the Solicited-Node Multicast Group for the
   address that they are claiming for their addresses; RFC 2461 [6].
   Subscribing SEND itself remain.
   For instance, an attacker may try to produce a multicast group requires very high number of
   packets that the nodes use MLD
   [20].  MLD contains no provision for security.  An attacker could
   send an MLD Done message to unsubscribe a victim from the
   Solicited-Node Multicast address.  However, the victim should be able
   to detect such an attack because the router sends a
   Multicast-Address-Specific Query to determine whether any listeners
   are still on the address, at which point the victim can respond to
   avoid being dropped from the group.  This technique will work if the host or router on the link has not been compromised.  Other attacks to verify using MLD asymmetric
   methods.  While safeguards are possible, but they primarily lead to extraneous (but not
   overwhelming) traffic.

11.2 How SEND Counters Threats required to Neighbor Discovery

   The prevent an excessive use
   of resources, this can still render SEND protocol non-operational.

   When CGA protection is designed to counter used, SEND deals with the threats to IPv6 Neighbor
   Discovery, as outlined DoS attacks using
   the verification process described in [27].  The following subsections contain Section 5.2.2.  In this
   process, a
   regression simple hash verification of the SEND protocol against the threats, to illustrate
   what aspects CGA property of the protocol counter each threat.

11.2.1 Neighbor Solicitation/Advertisement Spoofing

   This threat is defined in Section 4.1.1 of [27].  The threat
   address is that
   a spoofed Neighbor Solicitation or Neighbor Advertisement causes a
   false entry performed before performing the more expensive signature
   verification.

   When trust anchors and certificates are used for address validation
   in a node's Neighbor Cache.  There SEND, the defenses are two cases:

   1.  Entries made not quite as a side effect effective.  Implementations
   SHOULD track the resources devoted to the processing of a Neighbor Solicitation or
       Router Solicitation.  There are two cases:

       1.  A router receiving a Router Solicitation packets
   received with a firm IPv6
           source address and a Target Link-Layer Address extension
           inserts an entry for the IPv6 address into its Neighbor
           Cache.

       2.  A node doing Duplicate Address Detection (DAD) Signature option, and start selectively discarding
   packets if too many resources are spent.  Implementations MAY also
   first discard packets that receives are not protected with CGA.

   The Authorization Delegation Discovery process may also be vulnerable
   to Denial-of-Service attacks.  An attack may target a Neighbor Solicitation router by
   requesting a large number of delegation chains to be discovered for
   different trust anchors.  Routers SHOULD defend against such attacks
   by caching discovered information (including negative responses) and
   by limiting the same address regards the
           situation as number of different discovery processes they engage
   in.

   Attackers may also target hosts by sending a collision and ceases large number of
   unnecessary certificate chains, forcing hosts to solicit spend useless memory
   and verification resources for them.  Hosts can defend against such
   attacks by limiting the
           address.

   2.  Entries made as a result amount of a Neighbor Advertisement resources devoted to the
   certificate chains and their verification.  Hosts SHOULD also
   prioritize advertisements that sent as a response to a Neighbor Solicitation for purposes of on-link
       address resolution.

11.2.1.1 Solicitations with Effect

   SEND counters the threat of their
   solicitations with effect in the
   following ways:

   1.  As discussed in Section 5, SEND nodes preferably send above unsolicited advertisements.

10. Protocol Constants

   Host constants:

         MAX_DCS_MESSAGES              3 transmissions
         DCS_INTERVAL                  4 seconds

   Router
       Solicitations with a CGA address and a Signature option, which
       the router can verify, so the Neighbor Cache binding is correct.
       If a SEND node must send a Router Solicitation with the
       unspecified address, the router will not update its Neighbor
       Cache, as constants:

         MAX_DCA_RATE                  10 times per RFC 2461.

   See Section 11.2.5, below, for discussion about replay protection and
   timestamps.

11.2.1.2 Address Resolution

   SEND counters attacks on address resolution by requiring that the
   responding node include a signature option on the packet, and that
   the node's interface identifier either be a CGA, or that the node second

11. IANA Considerations

   This document defines two new ICMP message types, used in
   Authorization Delegation Discovery.  These messages must be
   able to produce a certificate authorizing that node to use assigned
   ICMPv6 type numbers from the public
   key. informational message range:

   o  The Neighbor Delegation Chain Solicitation and Advertisement pairs implement a
   challenge-response protocol, as explained message, described in Section 7 and discussed
      6.2.1.

   o  The Delegation Chain Advertisement message, described in Section 11.2.5 below.

11.2.2 Neighbor Unreachability Detection Failure
      6.2.2.

   This attack is document defines six new Neighbor Discovery Protocol [7]
   options, which must be assigned Option Type values within the option
   numbering space for Neighbor Discovery Protocol messages:

   o  The CGA option, described in Section 4.1.2 of [27].  SEND counters
   this attack by requiring a node responding to Neighbor Solicitations
   sent as NUD probes to include a 5.1.

   o  The Signature option and proof of
   authorization to use the interface identifier option, described in the address being
   probed.  If these prerequisites are not met, the node performing NUD
   discards the responses.

11.2.3 Duplicate Address Detection DoS Attack

   This attack is Section 5.2.

   o  The Timestamp option, described in Section 4.1.3 of [27].  SEND counters
   this attack by requiring 5.3.1.

   o  The Nonce option, described in Section 5.3.2.

   o  The Trust Anchor option, described in Section 6.2.3.

   o  The Certificate option, described in Section 6.2.4.

   This document defines a new 128-bit value under the Neighbor Advertisements sent as
   responses to DAD to include CGA Message Type
   [12] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.

   This document defines a Signature option and proof of
   authorization to use new name space for the interface identifier Name Type field in the address being
   tested.  If these prerequisites are not met, the node performing DAD
   discards the responses.

   When a SEND node is used on a link that also connects to non-SEND
   nodes, the SEND node ignores any insecure Neighbor Solicitations or
   Advertisements that may
   Trust Anchor option.  Future values of this field can be send by the non-SEND nodes.  This protects allocated
   using standards action [6].  The current values for this field are:

   1  DER Encoded X.501 Name

   2  FQDN

   Another new name space is allocated for the SEND node from DAD DoS attacks by non-SEND nodes or attackers
   simulating to non-SEND nodes, at Cert Type field in the cost
   Certificate option.  Future values of a potential address
   collision between a SEND node and non-SEND node. this field can be allocated
   using standards action [6].  The probability and
   effects of such an address collision are discussed in [26].

11.2.4 Router Solicitation current values for this field are:

   1  X.509v3 Certificate

Normative References

   [1]   Mockapetris, P., "Domain names - concepts and Advertisement Attacks

   These attacks are described facilities", STD
         13, RFC 1034, November 1987.

   [2]   Bradner, S., "Key words for use in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Kent, S. and 4.2.7 of [27].  SEND counters these attacks by requiring Router
   Advertisements to contain a Signature option, and that the signature
   is calculated using the public key of a node that can prove its
   authorization to route the subnet prefixes contained in any Prefix
   Information Options.  The router proves its authorization by showing
   a certificate containing the specific prefix or the indication that
   the router is allowed to route any prefix. A Router Advertisement
   without these protections is dropped.

   SEND does not protect against brute force attacks on the router, such
   as DoS attacks, or compromise of R. Atkinson, "Security Architecture for the router, as described in Sections
   4.4.2
         Internet Protocol", RFC 2401, November 1998.

   [4]   Kent, S. and 4.4.3 R. Atkinson, "IP Authentication Header", RFC 2402,
         November 1998.

   [5]   Piper, D., "The Internet IP Security Domain of [27].

11.2.5 Replay Attacks

   This attack is described in Interpretation
         for ISAKMP", RFC 2407, November 1998.

   [6]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section 4.3.1 of [27].  SEND protects
   against attacks in Router Solicitation/Router Advertisement RFCs", BCP 26, RFC 2434, October
         1998.

   [7]   Narten, T., Nordmark, E. and
   Neighbor Solicitation/Neighbor Advertisement transactions by
   including a Nonce option in the solicitation W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [8]   Thomson, S. and requiring the
   advertisement to include a matching option.  Together with the
   signatures this forms a challenge-response protocol.  SEND protects
   against attacks from unsolicited messages such as Neighbor
   Advertisements, Router Advertisements, T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [9]   Conta, A. and Redirects by including a
   Timestamp option.  A window of vulnerability for replay attacks
   exists until the timestamp expires.

   When timestamps are used, SEND nodes are protected against replay
   attacks as long as they cache the state created by the message
   containing the timestamp.  The cached state allows the node to
   protect itself against replayed messages.  However, once the node
   flushes the state for whatever reason, an attacker can re-create the
   state by replaying an old message while the timestamp is still valid.
   Since most SEND nodes are likely to use fairly coarse grained
   timestamps, as explained in Section 5.4.1, this may affect some
   nodes.

11.2.6 Neighbor Discovery DoS Attack

   This attack is described in Section 4.3.2 of [27].  In this attack,
   the attacker bombards the router with packets for fictitious
   addresses on the link, causing the router to busy itself with
   performing Neighbor Solicitations for addresses that do not exist.
   SEND does not address this threat because it can be addressed by
   techniques such as rate limiting Neighbor Solicitations, restricting
   the amount of state reserved for unresolved solicitations, and clever
   cache management. These are all techniques involved in implementing
   Neighbor Discovery on the router.

11.3 Attacks against SEND Itself

   The CGAs have a 59-bit hash value. The security of the CGA mechanism
   has been discussed in [26].

   Some Denial-of-Service attacks against NDP and SEND itself remain.
   For instance, an attacker may try to produce a very high number of
   packets that a victim host or router has to verify using asymmetric
   methods.  While safeguards are required to prevent an excessive use
   of resources, this can still render SEND non-operational.

   When CGA protection is used, SEND deals with the DoS attacks using
   the verification process described in Section 5.3.2. In this process,
   a simple hash verification of the CGA property of the address is
   performed first before performing the more expensive signature
   verification.

   When trust anchors and certificates are used for address validation
   in SEND, the defenses are not quite as effective. Implementations
   SHOULD track the resources devoted to the processing of packets
   received with the Signature option, and start selectively dropping
   packets if too many resources are spent. Implementations MAY also
   first drop packets that are not protected with CGA.

   The Authorization Delegation Discovery process may also be vulnerable
   to Denial-of-Service attacks.  An attack may target a router by
   requesting a large number of delegation chains to be discovered for
   different trust anchors.  Routers SHOULD defend against such attacks
   by caching discovered information (including negative responses) and
   by limiting the number of different discovery processes they engage
   in.

   Attackers may also target hosts by sending a large number of
   unnecessary certificate chains, forcing hosts to spend useless memory
   and verification resources for them.  Hosts can defend against such
   attacks by limiting the amount of resources devoted to the
   certificate chains and their verification.  Hosts SHOULD also
   prioritize advertisements that sent as a response to their
   solicitations above unsolicited advertisements.

12. IANA Considerations

   This document defines two new ICMP message types, used in
   Authorization Delegation Discovery.  These messages must be assigned
   ICMPv6 type numbers from the informational message range:

   o  The Delegation Chain Solicitation message, described in Section
      6.1.

   o  The Delegation Chain Advertisement message, described in Section
      6.2.

   This document defines six new Neighbor Discovery Protocol [6]
   options, which must be assigned Option Type values within the option
   numbering space for Neighbor Discovery Protocol messages:

   o  The Trust Anchor option, described in Section 6.3.

   o  The Certificate option, described in Section 6.4.

   o  The CGA option, described in Section 5.2.

   o  The Signature option, described in Section 5.3.

   o  The Timestamp option, described in Section 5.4.1.

   o  The Nonce option, described in Section 5.4.2.

   This document defines a new 128-bit CGA Message Type [26] value,
   0xXXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX (To be generated randomly).

   XXX: Use existing name spaces for these?

   This document defines a new name space for the Name Type field in the
   Trust Anchor option. Future values of this field can be allocated
   using standards action [5].

   Another new name space is allocated for the Cert Type field in the
   Certificate option. Future values of this field can be allocated
   using standards action [5].

Normative References

   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

   [2]   Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [3]   Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
         November 1998.

   [4]   Piper, D., "The Internet IP Security Domain of Interpretation
         for ISAKMP", RFC 2407, November 1998.

   [5]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

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

   [7]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [8]   Conta, A. and S. Deering, "Internet Control Message Protocol
         (ICMPv6) for the Internet Protocol Version 6 (IPv6)
         Specification", RFC 2463, December 1998.

   [9]   Narten, T. and R. Draves, "Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [10]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
         Identifiers for the Internet X.509 Public Key Infrastructure
         Certificate and Certificate Revocation List (CRL) Profile", RFC
         3279, April 2002.

   [11]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

   [12]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
         Addressing Architecture", RFC 3513, April 2003.

   [13]  Lynn, C., "X.509 Extensions for IP Addresses and AS
         Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-02 (work in
         progress), September 2003.

   [14]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
         2003.

   [15]  RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
         1, November 2002.

   [16]  National Institute of Standards and Technology, "Secure Hash
         Standard", FIPS PUB 180-1, April 1995, <http://
         www.itl.nist.gov/fipspubs/fip180-1.htm>.

Informative References

   [17]  Postel, J., "Internet Control Message Protocol", STD 5, RFC
         792, September 1981.

   [18]  Plummer, D., "Ethernet Address Resolution Protocol: Or
         converting network protocol addresses to 48.bit Ethernet
         address for transmission on Ethernet hardware", STD 37, RFC
         826, November 1982.

   [19]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409, November 1998.

   [20]  Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
         Discovery (MLD) for IPv6", RFC 2710, October 1999.

   [21]  Farrell, S. and R. Housley, "An Internet Attribute Certificate
         Profile for Authorization", RFC 3281, April 2002.

   [22]  Arkko, J., "Effects of ICMPv6 on IKE",
         draft-arkko-icmpv6-ike-effects-02 (work in progress), March
         2003.

   [23]  Arkko, J., "Manual Configuration of Security Associations for
         IPv6 Neighbor  Discovery", draft-arkko-manual-icmpv6-sas-02
         (work in progress), March 2003.

   [24]  Droms, R., "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
         November 2002.

   [25]  Kent, S., "IP Encapsulating Security Payload (ESP)",
         draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.

   [26]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-ietf-send-cga-01 (work in progress), August 2003.

   [27]  Nikander, P., "IPv6 Neighbor Discovery trust models and
         threats", draft-ietf-send-psreq-03 (work in progress), April
         2003.

   [28]  Montenegro, G. and C. Castelluccia, "SUCV Identifiers and
         Addresses", draft-montenegro-sucv-03 (work in progress), July
         2002.

   [29]  International Organization for Standardization, "The Directory
         - Authentication Framework", ISO Standard X.509, 2000.

   [30]  O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",
         Computer Communications Review, April 2001.

   [31]  Nikander, P., "Denial-of-Service, Address Ownership, and Early
         Authentication in the IPv6 World", Proceedings of the Cambridge
         Security Protocols Workshop, April 2001.

   [32]  Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. and
         M. Roe, "Securing IPv6 Neighbor Discovery", Wireless Security
         Workshop, September 2002.

   [33]  Montenegro, G. and C. Castelluccia, "Statistically Unique and
         Cryptographically Verifiable (SUCV) Identifiers and Addresses",
         NDSS, February 2002.

   [34]  Institute of Electrical and Electronics Engineers, "Local and
         Metropolitan Area Networks: Port-Based Network Access Control",
         IEEE Standard 802.1X, September 2001.

Authors' Addresses

   Jari Arkko
   Ericsson

   Jorvas  02420
   Finland

   EMail: jari.arkko@ericsson.com

   James Kempf
   DoCoMo Communications Labs USA
   181 Metro Drive
   San Jose, CA  94043
   USA

   EMail: kempf@docomolabs-usa.com

   Bill Sommerfeld
   Sun Microsystems
   1 Network Drive UBUR02-212
   Burlington, MA  01803
   USA

   EMail: sommerfeld@east.sun.com
   Brian Zill
   Microsoft

   USA

   EMail: bzill@microsoft.com

   Pekka Nikander
   Ericsson

   Jorvas  02420
   Finland

   EMail: Pekka.Nikander@nomadiclab.com

Appendix A. Contributors

   Tuomas Aura contributed the transition mechanism specification in
   Section 9.

Appendix B. IPR Considerations

   The optional CGA part of SEND uses public keys and hashes to prove
   address ownership. Several IPR claims have been made about such
   methods.

Appendix C. Cache Management

   In this section we outline a cache management algorithm that allows a
   node to remain partially functional even under a cache filling DoS
   attack.  This appendix is informational, and real implementations
   SHOULD use different algorithms in order to avoid he dangers of
   monocultural code.

   There are at least two distinct cache related attack scenarios:

   1.  There are a number of nodes on a link, and someone launches a
       cache filling attack.  The goal here is clearly make sure that
       the nodes can continue to communicate even if the attack is going
       on.

   2.  There is already a cache filling attack going on, and a new node
       arrives to the link.  The goal here is to make it possible S. Deering, "Internet Control Message Protocol
         (ICMPv6) for the new node to become attached to the network, inspite of the
       attack.

   From this point of view, it is clearly better to be very selective in
   how to throw out entries.  Reducing the timestamp Delta value is very
   discriminative against those nodess that have a large clock
   difference, while an attacker can reduce its clock difference into
   arbitrarily small.  Throwing out old entries just because their clock
   difference is large seems like a bad approach.

   A reasonable idea seems to be to have a separate cache space for new
   entries and old entries, and under an attack more eagerly drop new
   cache entries than old ones.  One could track traffic, Internet Protocol Version 6 (IPv6)
         Specification", RFC 2463, December 1998.

   [10]  Housley, R., Polk, W., Ford, W. and only allow
   those new entries that receive genuine traffic to be converted into
   old cache entries.  While such a scheme will make attacks harder, it
   will not fully prevent them. For example, an attacker could send a
   little traffic (i.e. a ping or TCP syn) after each NS to trick the
   victim into promoting its cache entry to the old cache.  Hence, the
   node may be more intelligent in keeping its cache entries, D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and not
   just have a black/white old/new boundary.

   It also looks like a good idea to consider the sec parameter when
   forcing cache entries out, Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

   [11]  Lynn, C., "X.509 Extensions for IP Addresses and let those entries with a larger sec a
   higher chance AS
         Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-02 (work in
         progress), September 2003.

   [12]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-ietf-send-cga-03 (work in progress), December 2003.

   [13]  RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
         1, November 2002.

   [14]  National Institute of staying in.

Appendix Standards and Technology, "Secure Hash
         Standard", FIPS PUB 180-1, April 1995, <http://
         www.itl.nist.gov/fipspubs/fip180-1.htm>.

Informative References

   [15]  Harkins, D. Comparison to AH-Based Approach

   This approach has the following benefits compared to the previous
   Working Group document approach:

   o  The full implementation of the security mechanism, including
      Nonces and CGAs, exists within one module.  There is no need to
      analyze the security of the mechanism across NDP, IPsec, D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409, November 1998.

   [16]  Deering, S., Fenner, W. and CGA
      layers.

   o  The CGA part of the solution has been separated into its own
      specification.  This is possible because the CGA handling is done B. Haberman, "Multicast Listener
         Discovery (MLD) for IPv6", RFC 2710, October 1999.

   [17]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
         Address Autoconfiguration in its own option.  (The authorization method configuration flag
      is the only thing common to the CGA IPv6", RFC 3041, January 2001.

   [18]  Farrell, S. and Signature options.)

   o  No extensions or modifications R. Housley, "An Internet Attribute Certificate
         Profile for Authorization", RFC 3281, April 2002.

   [19]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
         Addressing Architecture", RFC 3513, April 2003.

   [20]  Arkko, J., "Effects of ICMPv6 on IKE and IPsec processing are required:
      SPD entries are not required to distinguish ICMP types, AH does
      not need to support public keys or CGAs, Policies",
         draft-arkko-icmpv6-ike-effects-02 (work in progress), March
         2003.

   [21]  Arkko, J., "Manual SA Configuration for IPv6 Link Local
         Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
         June 2002.

   [22]  Nordmark, E., Chakrabarti, S. and destination address
      acgnostic security associations are not needed.

   o  It is not necessary to allocate a new multicast address to
      represent the Solicited-Node multicast address J. Laganier, "IPv6 Socket API
         for SEND nodes.

   o  It is not necessary to change the Address Selection", draft-chakrabarti-ipv6-addrselect-02
         (work in progress), October 2003.

   [23]  Droms, R., "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
         November 2002.

   [24]  Kent, S., "IP Encapsulating Security Payload (ESP)",
         draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.

   [25]  Nikander, P., "IPv6 Neighbor Discovery behavior with
      regards to the use trust models and
         threats", draft-ietf-send-psreq-00 (work in progress), October
         2002.

   [26]  International Organization for Standardization, "The Directory
         - Authentication Framework", ISO Standard X.509, 2000.

   [27]  Institute of Electrical and Electronics Engineers, "Local and
         Metropolitan Area Networks: Port-Based Network Access Control",
         IEEE Standard 802.1X, September 2001.

Authors' Addresses

   Jari Arkko
   Ericsson

   Jorvas  02420
   Finland

   EMail: jari.arkko@ericsson.com

   James Kempf
   DoCoMo Communications Labs USA
   181 Metro Drive
   San Jose, CA  94043
   USA

   EMail: kempf@docomolabs-usa.com

   Bill Sommerfeld
   Sun Microsystems
   1 Network Drive UBUR02-212
   Burlington, MA  01803
   USA

   EMail: sommerfeld@east.sun.com

   Brian Zill
   Microsoft

   USA

   EMail: bzill@microsoft.com

   Pekka Nikander
   Ericsson

   Jorvas  02420
   Finland

   EMail: Pekka.Nikander@nomadiclab.com

Appendix A. Contributors

   Tuomas Aura contributed the unspecified address.  Since all
      information is available within the Neighbor Discovery messages,
      unspecified source addresses can be used, still being able to
      correlate the CGA property with the Target Address transition mechanism specification in a Neighbor
      Solicitation during Duplicate Address Detection.

   o
   Section 8.

Appendix B. Acknowledgments

   The transition mechanisms for links with both SEND and non-SEND
      nodes are significantly simpler.  In particular, non-SEND nodes
      will be able authors would like to receive DAD probes thank Tuomas Aura, Erik Nordmark, Gabriel
   Montenegro, Pasi Eronen, and other messages sent by the
      SEND nodes.

   o  Only Francis Dupont for interesting
   discussions in this problem space.

Appendix C. Cache Management

   In this section we outline a single set of Neighbor Discovery messages from the router
      needs cache management algorithm that allows a
   node to be transmitted on remain partially functional even under a link. cache filling DoS
   attack.  This helps avoid extra
      overhead for mobility beacons and other frequently occurring
      messaging.

   o  Given that the asymmetric computations required in SEND are
      computationally expensive, it appendix is necessary to control the number
      of these operations informational, and real implementations
   SHOULD use different algorithms in order to avoid Denial-of-Service attacks.
      This control is easier to arrange with "application layer"
      information.  For instance, a router need not verify more Router
      Solicitations with an unspecified source address than it can
      respond to according to the RFC 2461 rules.

   o he dangers of
   mono-cultural code.

   There is no need for an API to communicate certificate chains
      requests and certificate chains between the IPsec and Neighbor
      Discovery modules.

      Also, are at least two distinct cache related attack scenarios:

   1.  There are a good implementation number of SEND would not require the user to
      configure it (beyond perhaps enabling it).  In order to achieve
      this with IPsec, nodes on a set of policy entries needs to be automatically
      created upon system start.

   o  There link, and someone launches a
       cache filling attack.  The goal here is no need for clearly make sure that
       the CGA parameters nodes can continue to be stored both in communicate even if the
      IPsec attack is going
       on.

   2.  There is already a cache filling attack going on, and Neighbor Discovery modules, where they are needed for a new node
       arrives to the construction of Authentication Headers and addresses,
      respectively.

   o  It link.  The goal here is not necessary to change existing BITS or BITW IPsec
      implementations to support SEND and AH_RSA_Sig.  There would have
      been two problems associated with such changes:

      *  A SEND implementation in such environment could not proceed
         until this modification were completed.

      *  Typical hardware that processes IPsec packets may not be easily
         changed make it possible for
       the new node to process asymmetric transforms.  (Of course, such
         packets can be passed become attached to the main CPU at network, in spite of the node, assuming
       attack.

   From this can easily point of view, it is clearly better to be done in the given implementation.)

   o  In addition, many IPsec implementations are highly optimized
      because they are on the fast path for packet processing.  For
      example, the Linux implementation runs very selective in
   how to throw out entries.  Reducing the kernel interrupt
      thread. Some of the SEND modifications might timestamp Delta value is very
   discriminative against those nodes that have required IPsec
      processing to wait on a semaphore while, for example, a
      certificate chain is fetched, large clock
   difference, while an operation that takes place attacker can reduce its clock difference into
   arbitrarily small.  Throwing out of
      band in regular IPsec processing old entries just because it their clock
   difference is done using IKE.
      While it might have been possible that the implemenation could
      have been arranged so that general IPsec processing wasqn't
      impacted, the resulting code would have been more complex.

   The use of IPsec to protect NDP would have been possible, but the
   limits and capabilities of IPsec would have large seems like a bad approach.

   A reasonable idea seems to be stretched. Small
   changes in the NDP protocol (or our understanding of the issues)
   might to have caused a situation which had no longer been easily handled
   when the "application" separate cache space for new
   entries and the security existed at different layers.
   Although IPsec as defined in RFC 2402 just defines a header format,
   RFC 2401 old entries, and the ensuing years of implementation have evolved under an attack more eagerly drop new
   cache entries than old ones.  One could track traffic, and only allow
   those new entries that receive genuine traffic to be converted into
   old cache entries.  While such a
   complex interconnected set of components for IPsec which would have
   required some modification scheme will make attacks harder, it
   will not fully prevent them.  For example, an attacker could send a
   little traffic (i.e.  a ping or TCP syn) after each NS to accommodate SEND.

   On the other hand, IPsec is trick the current solution for securing NDP in
   victim into promoting its cache entry to the original NDP RFCs.  Even if old cache.  Hence, the current IPsec can
   node may be used only more intelligent in
   very limited networks to secure NDP, it could have been argued that
   it would keeping its cache entries, and not
   just have been logical a black/white old/new boundary.

   It also looks like a good idea to continue its use. Also, consider the existence sec parameter when
   forcing cache entries out, and let those entries with a larger sec a
   higher chance of an asymmetric transform in IPsec would have been potentially
   useful in other contexts as well. staying in.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.