Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Expires: August 25, December 4, 2003                                       J. Kempf
                                          DoCoMo Communications Labs USA
                                                           B. Sommerfeld
                                                        SUN
                                                        Sun Microsystems
                                                                 B. Zill
                                                               Microsoft
                                                       February 24,
                                                             P. Nikander
                                                                Ericsson
                                                            June 5, 2003

                    SEcure Neighbor Discovery (SEND)
                      draft-ietf-send-ipsec-00.txt
                      draft-ietf-send-ipsec-01.txt

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 August 25, December 4, 2003.

Copyright Notice

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

Abstract

   IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other
   nodes on the link, to determine each other's link-layer addresses, to
   find routers and to maintain reachability information about the paths
   to active neighbors.  If not secured, ND protocol is vulnerable to
   various attacks.  This document specifies an extension to IPsec for
   securing ND.  Contrary to the original ND specifications that also
   called for use of IPsec, this extension does not require the creation
   of a large number of manually configured security associations.

Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.     Terms  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.     Neighbor and Router Discovery Overview . . . . . . . . . . .  6   7
   4.     Secure Neighbor Discovery Overview . . . . . . . . . . . . .  9  10
   5.    Cryptographically Generated Addresses     Modifications to Neighbor Discovery  . . . . . . . . . . . 11  12
          5.1    Unspecified Source Address Format . . . . . . . . . . . . . . . . . . . . 12
          5.2   Basic Interface Identifier Generation  . .    Secure-Solicited-Node Multicast Address  . . . . . . 12
          5.3   Address Generation    Nonce Option . . . . . . . . . . . . . . . . . . . . 13
          5.4   Duplicate Address Detection    Proxy Neighbor Discovery . . . . . . . . . . . . . . 14
   6.     Authorization Delegation Discovery . . . . . . . . . . . . .  15
          6.1    Delegation Chain Solicitation Message Format . . . . . 15
          6.2    Delegation Chain Advertisement Message Format  . . . . 17
          6.3    Trusted Root Option  . . . . . . . . . . . . . . . . . 19
          6.4    Certificate Option . . . . . . . . . . . . . . . . . . 20
          6.5    Router Authorization Certificate Format  . . . . . . 21
                 6.5.1  Field Values . . . . . . . . . . . . . . . . .22
          6.6    Processing Rules for Routers . . . . . . . . . . . . . 21
         6.6 23
          6.7    Processing Rules for Hosts . . . . . . . . . . . . . . 22 24
   7.     IPsec Extensions . . . . . . . . . . . . . . . . . . . . . . 25  27
          7.1    The AH_RSA_Sig Transform . . . . . . . . . . . . . . . 25 27
                 7.1.1  Reserved SPI Number  . . . . . . . . . . . . . . 25 .27
                 7.1.2  Authentication Data Format . . . . . . . . . . . 25 .27
                 7.1.3  AH_RSA_Sig Security Associations . . . . . . . . 27 .29
                 7.1.4  Replay Protection  . . . . . . . . . . . . . . . 28 .30
                 7.1.5  Processing Rules for Senders . . . . . . . . . . 28 .31
                 7.1.6  Processing Rules for Receivers . . . . . . . . . 29 .32
          7.2    Other IPsec Extensions . . . . . . . . . . . . . . . . 30 33
                 7.2.1  Destination Agnostic Security Associations . . . 30 .33
                 7.2.2  ICMP Type Specific Selectors . . . . . . . . . . 31 .33
   8.     Securing Neighbor Discovery with SEND  . . . . . . . . . . . 32  34
          8.1   Using IPsec to Secure    Neighbor Advertisement Solicitation Messages  32
         8.2   Security Policy and SA Database Configuration . . . . 32
   9.    Securing Router Discovery with SEND . . . . . . . 34
                 8.1.1  Sending Secure Neighbor Solicitations  . . . .34
                 8.1.2  Receiving Secure Neighbor Solicitations  . . 34
         9.1   Using IPsec to Secure Router .34
          8.2    Neighbor Advertisement Messages  . 34
         9.2   Using IPsec to Secure Redirect Messages  . . . . . . . 34
         9.3   Security Policy and SA Database Configuration . . . . 35
   10.   Operational Considerations
                 8.2.1  Sending Secure Neighbor Advertisements . . . .35
                 8.2.2  Receiving Secure Neighbor Advertisements . . .35
          8.3    Other Requirements . . . . . . . . . . . . 37
   11.   Performance Considerations . . . . . 36
          8.4    Configuration  . . . . . . . . . . . . 39
   12.   Security Considerations . . . . . . . 36
   9.     Securing Router Discovery with SEND  . . . . . . . . . . . 40
         12.1  Achieved Security Properties  39
          9.1    Router Solicitation Messages . . . . . . . . . . . . 39
                 9.1.1  Sending Secure Router Solicitations  . . 40
         12.2  Attacks against SEND Itself . . .39
                 9.1.2  Receiving Secure Router Solicitations  . . . .39
          9.2    Router Advertisement Messages  . . . . . . . . 40
   13.   IANA Considerations . . . 39
                 9.2.1  Sending Secure Router Advertisements . . . . .40
                 9.2.2  Receiving Secure Router Advertisements . . . .40
          9.3    Redirect Messages  . . . . . . . . . . 42
   14.   Conclusions and Remaining Work . . . . . . . 40
                 9.3.1  Sending Redirects  . . . . . . . . 43
         Normative References . . . . . .40
                 9.3.2  Receiving Redirects  . . . . . . . . . . . . .41
          9.4    Other Requirements . . . 44
         Informative References . . . . . . . . . . . . . . 41
          9.5    Configuration  . . . . . 45
         Authors' Addresses . . . . . . . . . . . . . . 42
   10.    Co-Existence of SEND and ND  . . . . . . . 46
   A.    Contributors . . . . . . . .  44
          10.1   Behavior Rules . . . . . . . . . . . . . . . . 47
   B.    Acknowledgements . . . 44
          10.2   Configuration  . . . . . . . . . . . . . . . . . . . 48
   C.    IPR 46
   11.    Performance Considerations . . . . . . . . . . . . . . . .  49
   12.    Implementation Considerations  . . . . . . . . 49
         Intellectual Property and Copyright Statements . . . . . . .  50

1. Introduction

   IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [6].
   Nodes on the same link use the ND protocol to discover each other's
   presence, to determine each other's link-layer addresses, to find
   routers and
   13.    Security Considerations  . . . . . . . . . . . . . . . . .  51
          13.1   Threats to maintain reachability information about the paths to
   active neighbors.  The ND protocol is used both Local Link Not Covered by hosts and routers.
   Its functions include Router SEND  . . . 51
          13.2   How SEND Counters Threats to Neighbor Discovery (RD), Address Auto-
   configuration, Address Resolution,  . . 51
                 13.2.1 Neighbor Solicitation/Advertisement Spoofing .51
                 13.2.2 Neighbor Unreachability Detection
   (NUD), Failure  . .53
                 13.2.3 Duplicate Address Detection (DAD), and Redirection.

   RFC 2461 called for the use of IPsec for protecting the ND messages.
   However, 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 [17] in using IKE [15] before ND is
   operational.  Furthermore, the number of security associations needed
   for protecting ND is impractically large [18].  Finally, RFC 2461 did
   not specify detailed instructions for using IPsec to secure ND.

   Section 4 describes our overall approach to securing ND.  This
   approach involves the use of IPsec AH [3] to secure all
   advertisements relating to Neighbor and DoS Attack . . . .53
                 13.2.4 Router Discovery.  A new
   transform for AH allows public keys to be used.  Routers are
   certified by a trusted root, Solicitation and a zero-configuration mechanism for
   showing address ownership.

   Section 5 describes the mechanism for showing address ownership,
   based on the use of Advertisement Attacks 53
                 13.2.5 Replay Attacks . . . . . . . . . . . . . . . .53
                 13.2.6 Neighbor Discovery DoS Attack  . . . . . . . .54
          13.3   Attacks against SEND Itself  . . . . . . . . . . . . 54
   14.    IANA Considerations  . . . . . . . . . . . . . . . . . . .  56
          Normative References . . . . . . . . . . . . . . . . . . .  57
          Informative References . . . . . . . . . . . . . . . . . .  59
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  60
   A.     Contributors . . . . . . . . . . . . . . . . . . . . . . .  62
   B.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  63
   C.     IPR Considerations . . . . . . . . . . . . . . . . . . . .  64
          Intellectual Property and Copyright Statements . . . . . .  65

1. Introduction

   IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [6].
   Nodes on the same link use the ND protocol 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.  The ND protocol is used both by hosts and routers.
   Its functions include Router Discovery (RD), Address Auto-
   configuration, Address Resolution, Neighbor Unreachability Detection
   (NUD), Duplicate Address Detection (DAD), and Redirection.

   RFC 2461 called for the use of IPsec for protecting the ND messages.
   However, 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 [23, 21] before ND is
   operational.  Furthermore, the number of such manually configured
   security associations needed for protecting ND is impractically large
   [24].  Finally, RFC 2461 did not specify detailed instructions for
   using IPsec to secure ND.

   Section 4 describes our overall approach to securing ND.  This
   approach involves the use of IPsec AH [3] to secure all
   advertisements relating to Neighbor and Router Discovery.  A new
   transform for AH allows public keys to be used.  Routers are
   certified by a trusted root, and a zero-configuration mechanism for
   showing address ownership.  The formats, procedures, and
   cryptographic mechanisms for this zero-configuration mechanism are
   described in a related specification [27].

   Section 6 describes the mechanism for distributing certificate chains
   to establish authorization delegation chain to a common trusted root.
   Section 7 describes the necessary modifications to IPsec.  Section 8
   and Section 9 show how to apply these components to securing Neighbor
   and Router Discovery.  A few small changes are required in the
   Neighbor Discovery protocol and these are discussed in Section 5.

   Finally, Section 10 discusses the co-existence of secure and
   non-secure Neighbor Discovery on the same link, Section 11 discusses
   performance considerations, Section 12 discusses the implementation
   considerations related to the IPsec extensions, and Section 13
   discusses security considerations for SEND.

2. Terms

   Authorization Certificate (AC)

      The signer of an authorization certificate has authorized the
      entity designated in the certificate for a specific task or
      service.

   Authorization Delegation Discovery (ADD)

      This is a process through which SEND nodes can acquire a
      certificate chain from a peer node to a trusted root.

   Cryptographically Generated Addresses (CGAs)

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

   Duplicate Address Detection (DAD)

      This mechanism defined in RFC 2462 [7] 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 is a part
      of ICMPv6.

   Neighbor Discovery (ND)

      The IPv6 Neighbor Discovery protocol [6].

   Neighbor Unreachability Detection (NUD)

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

   Nonce

      Nonces are random numbers generated by a node.  In SEND, they are
      used to ensure that a particular advertisement is linked to the
      solicitation that triggered it.

   Security association

      A security association is a simplex "connection" that affords
      security services to the traffic carried by it.  Security services
      are afforded to a security association by the use of AH, or ESP,
      but not both.  A security association is uniquely identified by a
      triple consisting of a Security Parameter Index (SPI), an IP
      Destination Address, and a security protocol (AH or ESP)
      identifier [2].

   Security association database

      A nominal database containing parameters that are associated with
      each (active) security association.  For inbound and outbound
      IPsec processing, these databases are separate.

   Security Parameters Index (SPI)

      An arbitrary 32-bit value.  Together with the destination IP
      address and security protocol (ESP or AH) identifier, the SPI
      uniquely identifies the Security Association.  Values from 1 to
      255 are reserved.

   Special SPI

      A Security Parameters Index from the reserved range 1 to 255.

   Security policy

      The security policy determines the security services afforded to
      an IPsec protected packet and the treatment of the packet in the
      network.

   Security policy database

      A nominal database containing a list of policy entries.  Each
      policy entry is keyed by one or more selectors that define the set
      of IP traffic encompassed by this policy entry.  Separate entries
      for inbound and outbound traffic is required  [2].

3. Neighbor and Router Discovery Overview

   IPv6 Neighbor and Router Discovery have several functions.  Many of
   these functions are overloaded on a few central message types such as
   the ICMPv6 Neighbor Discovery message.  In this section we explain
   some of these tasks and their effects in order to understand better
   how the messages should be treated.  Where this section and the
   original Neighbor Discovery RFCs are in conflict, the original RFCs
   take precedence.

   In IPv6, many of the tasks traditionally done at lower layers such as
   ARP have been moved to the IP layer.  As a consequence, unified
   mechanisms can be applied across link layers, security mechanisms or
   other extensions can be adopted more easily, and a clear separation
   of the roles between the IP and link layer can be achieved.

   The main functions of IPv6 Neighbor Discovery are as follows:

   o  Neighbor Unreachability Detection (NUD) is used for tracking the
      reachability of neighbors, both hosts and routers.  NUD is defined
      in Section 7.3 of RFC 2461 [6].  NUD is security-sensitive,
      because no higher level traffic can proceed if this procedure
      flushes out neighbor cache entries after (perhaps incorrectly)
      determining that the peer is not reachable.

   o  Duplicate Address Detection (DAD) is used for preventing address
      collisions [7].  A node that intends to assign a new address to
      one of its interfaces runs first the DAD procedure to verify that
      other nodes are not using the same address.  Since the outlined
      rules forbid the use of an address until it has been found unique,
      no higher layer traffic is possible until this procedure has
      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 [20].  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] 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 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 is used for automatically assigning
      addresses to a host [7].  This allows hosts to operate without
      configuration related to IP connectivity.  The Address
      Autoconfiguration mechanism is stateless, where the hosts use
      prefix information delivered to them during Router Discovery to
      create addresses, and then test these addresses for uniqueness
      using the DAD procedure.  A stateful mechanism, DHCPv6 [25],
      provides additional Autoconfiguration features.  Router and Prefix
      Discovery and Duplicate Address Detection have an effect to the
      Address Autoconfiguration tasks.

   o  The Redirect function is used for automatically redirecting hosts
      to an alternate router.  Redirect is specified in Section 8 of RFC
      2461 [6].  It is similar to the ICMPv4 Redirect message [19].

   o  The Router Discovery function allows IPv6 hosts to discover the
      local routers on an attached link.  Router Discovery is described
      in Section 6 of RFC 2461 [6].  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 messages follow the ICMPv6 message format and
   ICMPv6 types from 133 to 137.  The IPv6 Next Header value for ICMPv6
   is 58.  The actual Neighbor Discovery message includes an ND message
   header consisting of ICMPv6 header and ND message-specific data, and
   zero or more ND options:

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

   The ND message options are formatted in the Type-Length-Value format.

   All IPv6 ND protocol functions are realized using the following
   messages:

            ICMPv6 Type      Message
            ------------------------------------
            133              Router Solicitation (RS)
            134              Router Advertisement (RA)
            135              Neighbor Solicitation (NS)
            136              Neighbor Advertisement (NA)
            137              Redirect

   The functions of the ND protocol are realized using these messages as
   follows:

   o  Router Discovery uses the RS and RA messages.

   o  Duplicate Address Detection uses the NS and NA messages.

   o  Address Autoconfiguration uses the NS, NA, RS, 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 destination addresses used in these messages are as follows:

   o  Neighbor Solicitation: The destination address is either the
      solicited-node multicast address, unicast address, or an anycast
      address.

   o  Neighbor Advertisement: The destination address is either a
      unicast address or the All Nodes multicast address [1].

   o  Router Solicitation: The destination address is typically the All
      Routers multicast address [1].

   o  Router Advertisement: The destination address can be either a
      unicast or the All Nodes multicast address [1].  Like the
      solicitation message, the advertisement is also local to the link
      only.

   o  Redirect: This message is always sent from the router's link-local
      address to the source address of the packet that triggered the
      Redirect.  Hosts verify that the IP source address of the Redirect
      is the same as the current first-hop router for the specified ICMP
      Destination Address.  Rules in [1] dictate that unspecified,
      anycast, or multicast addresses may not be used as source
      addresses.  Therefore, the destination address will always be a
      unicast address.

4. Secure Neighbor Discovery Overview

   IPsec AH is used in to protect Neighbor and Router Discovery
   messages.  This specification introduces the use of a new transform
   for IPsec AH, extensions to the current IPsec selectors, an
   authorization delegation discovery process, and an address ownership
   proof mechanism.

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

   o  Trusted roots are expected to certify the authority of routers.  A
      host and a router must have at least one common trusted root
      before the host can adopt the router as its default router.
      Optionally, an authorization certificate can specify the prefixes
      for which the router is allowed to act as a router.  Delegation
      Chain Solicitation and Advertisement messages are used to discover
      a certificate chain to the trusted root without requiring the
      actual Router Discovery messages to carry lengthy certificate
      chains.

   o  Cryptographically Generated Addresses (CGAs).
   Section 6 describes are used to assure that the
      sender of a Neighbor or Router Advertisement is the owner of an
      the claimed address.  A public-private key pair needs to be
      generated by all nodes before they can claim an address.

   o  IPsec AH is used to protect all messages relating to Neighbor and
      Router discovery.

   o  IPsec security policy database and security association database
      are configured to require the protection as indicated above.  Note
      that such configuration may take place manually or the operating
      system may perform it automatically upon enabling Secure Neighbor
      Discovery.

      This specification introduces extensions to the required selectors
      used in security policy database entries.  This is necessary in
      order to enable the protection of specific ICMP message types,
      while leaving other messages unprotected.

   o  A new transform for IPsec AH allows public keys to be used on a
      security association directly without the involvement of a key
      management protocol.  Symmetric session keys are not used, public
      key signatures are used instead.  The trust to the public key is
      established either with the authorization delegation process or
      the address ownership proof mechanism, depending on configuration
      and the type of the message protected.

      The new transform uses also a fixed, standardized SPI (Security
      Parameters Index) number.  This is necessary again in order to
      avoid the involvement of a key management protocol.

      Given that Neighbor and Router Discovery messages are in some
      cases sent to multicast addresses, the new transform uses
      timestamps as a replay protection mechanism instead of sequence
      numbers.  To provide additional replay protection for distributing certificate chains the cases
      where required clock accuracy is not available, nonces are used in
      the Neighbor Discovery protocol.

5. Modifications to establish authorization delegation chain Neighbor Discovery

   Support for the SEND protocol can be added to a common trusted root. Neighbor Discovery
   implementation by providing the new Neighbor Discovery protocol
   mechanisms described in Section 7 describes 6, the necessary modifications to IPsec.  Finally, IPsec mechanisms described in
   Section 8 show how to apply these components to securing 7, and using them together as specified in Section 9 and
   Section 8.  However, the following aspects of the Neighbor Discovery
   protocol change with SEND:

   o  The use of the unspecified address as a source address is
      discouraged.

   o  The solicited-node multicast address is replaced with the
      securely-solicited-node multicast address.

   o  The Nonce option is required in all Neighbor Discovery
      solicitations, and for all solicited advertisements.

   o  Proxy Neighbor Discovery is not supported in this specification
      (it will be specified in a future document).

5.1 Unspecified Source Address

   In SEND, the unspecified address is not used as the source address in
   Neighbor Solicitation, Neighbor Advertisement, Router Discovery.

2. Terms

   Cryptographically Generated Addresses (CGAs) Advertisement,
   or Redirect messages.  A technique [22] where Neighbor Solicitation sent as a part of
   Duplicate Address Detection uses the tentative address for which the
   Duplicate Address Detection is being run.

   The use of the unspecified address is avoided in Router
   Solicitations, if possible.  RFC 2461 requires that Router
   Solicitations sent from the unspecified address do not cause a
   modification in the Neighbor Cache.

5.2 Secure-Solicited-Node Multicast Address

   SEND defines the securely-solicited-node multicast addresses.  These
   addresses are of the form:

       FF02:0:0:0:0:1:FEXX:XXXX

   Like the solicited-node multicast address, this multicast address is
   computed as a function of a node's unicast and anycast addresses.
   The securely-solicited-node multicast address of the node is cryptographically generated from formed by taking the
      public key
   low-order 24 bits of the node address (unicast or anycast) and some other parameters using a one-way
      hash function.

   Internet Control Message Protocol version 6 (ICMPv6) The IPv6 control
      signaling protocol.  Neighbor Discovery is appending
   those bits to the prefix FF02:0:0:0:0:1:FE00::/104 resulting in a part
   multicast address in the range FF02:0:0:0:0:1:FE00:0000 to
   FF02:0:0:0:0:1:FEFF:FFFF.

   As discussed in Section 8.1, SEND uses the securely-solicited-node
   multicast address instead of ICMPv6. the solicited-node multicast address
   when sending secured Neighbor Discovery (ND) The IPv6 Solicitations.  However, in order to
   allow for co-existence of secure and insecure Neighbor Discovery protocol [6].

   Security Association (SA) A Security Association (SA) is a simplex
      "connection" that affords security services to on
   the traffic carried
      by it.  Security services are afforded same link, SEND nodes will also send Duplicate Address Detection
   probes to an SA by the solicited-node multicast address (see Section 10).  The
   use of AH,
      or ESP, but not both.  A SA two different addresses is uniquely identified by a triple
      consisting necessary in order to distinguish
   between these messages in the security policy database.

5.3 Nonce Option

   The purpose of a Security Parameter Index (SPI), the Nonce option is to ensure that an IP Destination
      Address, and advertisement is
   a security protocol (AH or ESP) identifier [2].

   Security Association Database (SAD) A nominal database containing
      parameters that are associated with each (active) security
      association.  For inbound and outbound IPsec processing, these
      databases fresh response to a solicitation sent earlier by this same node.
   The format of the Nonce 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 separate.

   Security Parameters Index (SPI) An arbitrary 32-bit value.  Together
      with as follows:

   Type

      TBD <To be assigned by IANA> for Nonce.

   Length

      The length of the destination IP address and security protocol (ESP or AH)
      identifier, option (including the SPI uniquely identifies Type, Length, and Nonce
      fields) in units of 8 octets.

   Nonce

      This field contains a random number selected by the Security Association.
      Values from 1 to 255 are reserved.

   Special SPI A Security Parameters Index from sender of the reserved range 1 to
      255.

   Security Policy
      solicitation message.  The Security Policy determines length of the security services
      afforded number MUST be at least 6
      bytes.

5.4 Proxy Neighbor Discovery

   The Target Address in Neighbor Advertisement is required to be equal
   to an IPsec protected packet and the treatment source address of the
      packet packet, except in the network.

   Security Policy Database (SPD) A nominal database containing a list
      of policy entries.  Each policy entry is keyed by one or more
      selectors that define the set case of IP traffic encompassed by this
      policy entry.  Separate entries for inbound and outbound traffic
      is required  [2].

3. proxy
   Neighbor Discovery.  Proxy Neighbor and Router Discovery Overview is discussed in another
   specification.

6. Authorization Delegation Discovery

   Several protocols, including IPv6 Neighbor Discovery, allow a node to
   automatically configure itself based on information it learns shortly
   after connecting to a new link.  It is particularly easy for "rogue"
   routers to be configured, and it is particularly difficult for a
   network node to distinguish between valid and Router Discovery have several functions.  Many invalid sources of
   these functions are overloaded on a few central message types such as
   information when the ICMPv6 Neighbour Discovery message.  In node needs this section we explain
   some of these tasks and their effects in order to understand better
   how information before communicating
   off-link.

   Since the messages should newly-connected node likely can not communicate off-link,
   it can not be treated.  Where this section and the
   original Neighbor Discovery RFCs are in conflict, the original RFCs
   take precedence.

   In IPv6, many of the tasks traditionally done at lower layers such as
   ARP have been moved responsible for searching information to help validate
   the IP layer.  As router; however, given a consequence, unified
   mechanisms can be applied across link layers, security mechanisms or
   other extensions chain of appropriately signed
   certificates, it can be adopted more easily, check someone else's search results and conclude
   that a clear separation
   of particular message comes from an authorized source.
   Similarly, the roles between router, which is already connected to the IP and link layer network, can be achieved.
   if necessary communicate off-link and construct the certificate
   chain.

   The main functions of IPv6 Secure Neighbor Discovery protocol introduces two new ICMPv6
   messages that are as follows:

   o  Neighbor Unreachability Detection (NUD) is used for tracking the
      reachability of neighbors, both between hosts and routers.  NUD is defined
      in Section 7.3 routers to allow the client
   to learn the certificate chain with the assistance of RFC 2461 [6].  No higher level traffic can
      proceed if this procedure flushes out neighbour cache entries
      after (perhaps incorrectly) determining that the peer is not
      reachable.

   o  Duplicate Address Detection (DAD) router.
   Where hosts have certificates from a trusted root, these messages MAY
   also optionally be used between hosts to acquire the peer's
   certificate chain.

   The Delegation Chain Solicitation message is used for preventing address
      collisions [7].  A node that intends sent by hosts when they
   wish to assign request the certificate chain between a new address to router and the one of its interfaces runs first
   the DAD procedure hosts' trusted roots.  The Delegation Chain Advertisement message
   is sent as an answer to this message, or periodically to verify that
      other nodes are not using the same All
   Nodes multicast address.  Since  These messages are separate from the outlined
      rules forbid rest
   of the use Neighbor Discovery in order to reduce the effect of an address until it has been found unique,
      no higher layer traffic is possible until this procedure has
      completed.

   o  Address Resolution is similar the
   potentially voluminous certificate chain information to IPv4 ARP [14]. other
   messages.

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

6.1 Delegation Chain Solicitation Message Format

   Hosts send Delegation Chain Solicitations in order to prompt routers
   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
      Resolution function resolves a node's IPv6

         An IP address assigned to the
      corresponding link-layer sending interface, or the
         unspecified address for nodes on if no address is assigned to the link. sending
         interface.

      Destination Address
      Resolution is defined in

         Typically the all-routers multicast address, the
         securely-solicited-node multicast address (see Section 7.2 5.2, or
         the address of RFC 2461 [6] the hosts' default router.

      Hop Limit

         255

   ICMP Fields:

      Type

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

      Code

         0

      Checksum

         The ICMP checksum [8]..

      Identifier

         This 16 bit unsigned integer field acts as an identifier to
         help match advertisements to solicitations.  The Identifier
         field MUST NOT be zero.

      Reserved

         This field is unused.  It MUST be initialized to zero by the
         sender and it MUST be ignored by the receiver.

   Valid Options:

      Trusted Root

         One or more trusted roots that the client is
      used for hosts willing to accept.

      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and routers alike.  Again, no higher level traffic
      can proceed until continue processing the message.

6.2 Delegation Chain Advertisement Message Format

   Routers send out Delegation Chain Advertisement messages
   periodically, or 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      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |          Component            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address

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

      Destination Address

         Either the hardware securely-solicited-node multicast address of the
      destination node
         receiver or the next hop router.  Note that like its
      predecessor in ARP, IPv6 Neighbor Discovery does not check the
      source link layer address 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 all-nodes multicast address.

      Hop Limit

         255
   ICMP Fields:

      Type

         TBD <To be passed
      from layer to another layer.

   o  Address Autoconfiguration is used assigned by IANA> for automatically assigning
      addresses to a host [7]. Delegation Chain
         Advertisement.

      Code

         0

      Checksum

         The ICMP checksum [8]..

      Identifier

         This allows hosts 16 bit unsigned integer field acts as an identifier to operate without
      configuration related
         help match advertisements to IP connectivity. solicitations.  The Address
      Autoconfiguration mechanism is stateless, where the hosts use
      prefix information delivered to them during Router Discovery to
      create addresses, and then test these addresses Identifier
         field MUST be zero for uniqueness
      using the DAD procedure.  A stateful mechanism, DHCPv6 [19],
      provides additional Autoconfiguration features.  Router and Prefix
      Discovery unsolicited advertisements and Duplicate Address Detection have an effect to the
      Address Autoconfiguration tasks.

   o  The Redirect function MUST NOT
         be zero for solicited advertisements.

      Component

         This is a 16 bit unsigned integer field used for automatically redirecting hosts informing the
         receiver which certificate is being sent, and how many are
         still left to an alternate router.  Redirect be sent in the whole chain.  A single
         advertisement MUST be broken into separately sent components if
         there is specified more than one Certificate option, in Section 8 of RFC
      2461 [6].  It is similar order to avoid
         excessive fragmentation at the ICMPv4 Redirect message [13].

   o  The Router Discovery function allows IPv6 hosts to discover IP layer.  Unlike the
      local routers on
         fragmentation at the IP layer, individual components of an attached link.  Router Discovery is described
         advertisement may be stored and taken in Section 6 of RFC 2461 [6].  The main purpose of Router
      Discovery is use before all the
         components have arrived; this makes them slightly more reliable
         and less prone to find neighboring routers that are willing Denial-of-Service attacks.  The first message
         in a N-component advertisement has the Component field set to
      forward packets on
         N-1, the behalf of hosts.  Prefix discovery involves
      determining which destinations second set to N-2, and so on.  Zero indicates that
         there are directly on a link; no more components coming in this
      information advertisement.

      Reserved

         This field is necessary in order to know whether a packet should unused.  It MUST be sent to a router or initialized to zero by the destination node directly.
      Typically, address autoconfiguration and other tasks can't proceed
      until suitable routers
         sender and prefixes have been found.

   The Neighbor Discovery messages follow MUST be ignored by the ICMPv6 message format and
   ICMPv6 types from 133 to 137.  The IPv6 Next Header value for ICMPv6 receiver.

   Valid Options:

      Certificate

         One certificate is 58.  The actual Neighbor Discovery message includes an ND message
   header consisting of ICMPv6 header and ND message-specific data, and
   zero provided in Certificate option, to establish
         a (part of) certificate chain to a trusted root.

      Trusted Root

         Zero or more ND options:

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

   The ND message Trusted Root options may be included to help
         receivers decide which advertisements are formatted useful for them.  If
         present, these options MUST appear in the Type-Length-Value format.

   All IPv6 ND first component of a
         multi-component advertisement.

      Future versions of this protocol functions are realized using may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the following
   messages:

            ICMPv6 Type      Message
            ------------------------------------
            133              Router Solicitation (RS)
            134              Router Advertisement (RA)
            135              Neighbor Solicitation (NS)
            136              Neighbor Advertisement (NA)
            137              Redirect message.

6.3 Trusted Root Option

   The functions format of the ND protocol are realized using these messages Trusted Root option is as
   follows:

   o  Router Discovery uses the RS and RA messages.

   o  Duplicate Address Detection uses the NS and NA messages.

   o  Address Autoconfiguration uses the NS, NA, RS, and RA messages.

   o  Address Resolution uses the NS and NA messages.

   o  Neighbor Unreachability Detection uses described in the NS and NA messages.

   o  Redirect uses
   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    |  Name Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Name ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the Redirect message.

   The addresses used in these messages fields are as follows:

   o  Neighbor Solicitation:

   Type

      TBD <To be assigned by IANA> for Trusted Root.

   Length

      The destination address is either length of the
      solicited node multicast address, unicast address, or an anycast
      address.

   o  Neighbour Advertisement: The destination address is either a
      unicast address or option (including the All Nodes multicast address [1].

   o  Router Solicitation: Type, Length, Name Type,
      Name Length, and Name fields) in units of 8 octets.

   Name Type

      The destination address is typically type of the All
      Routers multicast address [1].

   o  Router Advertisement: name included in the Name field.  This
      specification defines only one legal value for this field:

               1        FQDN
   Name Length

      The destination address can be either a
      unicast or length of the All Nodes multicast address [1].  Like Name field, in bytes.  Octets beyond this length
      but within the
      solicitation message, length specified by the advertisement Length field are padding
      and MUST be set to zero by senders and ignored by receivers.

   Name

      When the Name Type field is also local set to 1, the Name field contains the
      Fully Qualified Domain Name of the trusted root, for example
      "trustroot.operator.com".

6.4 Certificate Option

   The format of the certificate 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     |  Cert Type    |  Pad Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Certificate ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the link
      only.

   o  Redirect: This message is always sent from fields are as follows:

   Type

      TBD <To be assigned by IANA> for Certificate.

   Length

      The length of the router's link-local
      address to option (including the source address Type, Length, Cert Type,
      Pad Length, and Certificate fields) in units of 8 octets.

   Cert Type

      The type of the packet that triggered the
      Redirect.  Hosts verify that certificate included in the IP source address Name field.  This
      specification defines only one legal value for this field:

               1        X.509 Certificate

   Pad Length

      The amount of padding beyond the Redirect
      is the same as end of the current first-hop router for Certificate field but
      within the length specified ICMP
      Destination Address.  Rules in [1] dictate that unspecified,
      anycast, or multicast addresses may not be used as source
      addresses.  Therefore, by the destination address will always Length field.  Padding MUST be a
      unicast address.

4. Secure Neighbor Discovery Overview

   IPsec AH is used in
      set to protect Neighbor zero by senders and Router Discovery
   messages.  This specification introduces ignored by receivers.

   Certificate

      When the use of a new transform
   for IPsec AH, extensions Cert Type field is set to 1, the current IPsec selectors, an
   authorization delegation discovery process, and Certificate field
      contains an address ownership
   proof mechanism. X.509 certificate [16].

6.5 Router Authorization Certificate Format

   The components certificate chain of the solution specified a router terminates in this document are as
   follows:

   o  IPsec AH is used to protect all advertisement messages relating to
      Neighbor and Router discovery.  Solicitation messages are not
      protected, as they do not carry any information.

   o  IPsec security policy database and security association database a router
   authorization certificate that authorizes a specific IPv6 node as a
   router.  Because authorization chains are configured to require not common practice in the protection as indicated above.  Note
      that such configuration may take place manually or
   Internet at the operating
      system may perform it automatically upon enabling Secure Neighbor
      Discovery.

      This time this specification introduces extensions to the required selectors
      used in security policy database entries.  This is necessary being written, the chain
   MUST consist of standard Public Key Certificates (PKC, in
      order to enable the protection sense
   of specific ICMP message types,
      while leaving other messages unprotected.

   o  A new transform [11]) for IPsec AH allows public keys identity from the trusted root shared with the host to be used on a
      security association directly without
   the involvement of a key
      management protocol.  Symmetric session keys are not used, public
      key signatures are used instead.  The trust router.  This allows the host to anchor trust for the router's
   public key is
      established either with in the authorization delegation process or trusted root.  The last item in the address ownership proof mechanism, depending on configuration
      and chain is an
   Authorization Certificate (AC, in the type sense of [12]) authorizing the message protected.

      The new transform uses also a fixed, standardized SPI (Security
      Parameters Index) number.  This necessary again in order
   router's right to avoid route.  Stronger certification is necessary here
   than for CGAs because the involvement right to route must be granted by an
   authorizing agency.  Future versions of a key management protocol.

      Given that Neighbor this specification may
   include provision for full authorization certificate chains, should
   they become common practice.

   SEND nodes MUST support the RFC 3281 X.509 attribute certificate
   format [12] as the default format for router authorization
   certificates, and MAY support other formats.  Router Discovery messages are authorization
   certificates MUST be signed by the network operator or other trusted
   third party whose PKC is above the router's PKC in some
      cases sent to multicast addresses, the new transform uses a
      timestamp mechanism as a replay mechanism instead of sequence
      numbers.

   o  Trusted roots are expected to certify delegation
   chain.  Routers MAY advertise multiple ACs if the authority of routers.  A
      host trust delegation
   obtains from different trust roots, and a the authorized prefixes in
   those certificates MAY be disjoint.  A router must have at least SHOULD only advertise
   one common trusted AC corresponding to one trust root
      before and all interfaces and
   prefixes covered by that trust root MUST be in the host can accept adopt AC.

   In the router as its default router.
      Delegation Chain Solicitation and Advertisement messages are used attribute certificate, the GeneralName type MUST be either a
   dNSName or iPAddress for the router, unless otherwise specified by
   RFC 3281.  If the GeneralName attribute is a dNSName, it MUST be
   resolvable to discover a certificate chain global unicast address assigned to the trusted root without
      requiring router.  If
   the actual Router Discovery messages to carry lengthy
      certificate chains.

   o  Cryptographically Generated Addresses are used GeneralName attribute is an iPAddress, it MUST be a global
   unicast address assigned to assure that the
      sender router.  For purposes of facilitating
   renumbering, a Neighbor dNSName SHOULD be used.  However, hosts MUST NOT use a
   dNSName or Router Advertisement is iPAddress for validating the owner certificate.  The router's
   public key hash, stored in the
   acinfo.holder.objectDigestInfo.objectDigest field of an the claimed address.  A public-private key pair needs to be
      generated by all nodes before they can claim an address.

5. Cryptographically Generated Addresses

   Cryptographically Generated Addresses (CGAs) [22][23][20][25] are a
   technique whereby a node's IPv6 address certificate
   provides the definitive validation.  As explained in Section 9.2, the
   addresses from the certificate can be unalterably tied to matched against the node's public key.  Conceptually, CGAs allow a recipient global
   addresses claimed in the Router Advertisement.

6.5.1 Field Values

   acinfo.holder.entityName

      This field MAY contain one or several entityNames, of a
   message type dNSName
      or iPAddress, referring to determine whether the sender is authorized global address(es) belonging to use the
   public key
      router.

   acinfo.objectDigestInfo.digestedObjectType

      This field MUST be present and address claimed to of type (1), publicKey.

   acinfo.holder.digestAlgorithm

      This field MUST indicate id-sha1 as indicated in RFC 3279 [10].

   acinfo.objectDigestInfo.objectDigest

      This field MUST be associated with a SHA-1 digest over either a PKCS#1 [17] (RSA)
      or an RFC 3279 Section 2.3.2 representation [10] (DSA)
      representation of the packet.
   Typically, router's public key.  If this requires the sender to use digest does
      not match the hash digest of the node's router's public key as from its PKC, a
      node MUST discard the interface identifier in certificate.

   acinfo.issuer.v2form.issuerName

      The field MUST contain the bottom 64 bits of distinguished name from the
   IPv6 address.

   Authorization through CGAs and certificates are related, but separate
   mechanisms.  It is separate in that other techniques of authorization
   (i.e.  digital certificates) can be PKC used instead of CGAs to achieve
      sign the same effect.  However, certificates require router AC.

   acinfo.attrCertValidityPeriod

      A node MUST NOT accept a means to create and
   distribute them, thereby imposing more overhead than CGA.  It is
   related in that certificate if the validity period has
      ended or has not yet started.

   acinfo.attributes

      This field MUST contain a digital signature list of prefixes that the router is required in addition
      authorized to route, or the
   CGA address and  unspecified  prefix  if  the signature must cover  router
      is  allowed  to  route  any prefix.  The field has the address, in order that following
      type:

         name: AuthorizedSubnetPrefix
          OID: {id-rcert}
       Syntax: iPAddress
       values: Multiple allowed
               Multiple prefix values are allowed.

      The details of the recipient can have above syntax are specified in Section 2.2.3.8
      of [14].

      If the confidence that router is authorized only to route specific prefixes, the address was not
   altered
      ipAddress values consist of IPv6 addresses in transit.  Furthermore, to properly authorize standard RFC 3513
      [13] prefix format.  One iPAddress value appears for each prefix
      routed by the address
   use, router.  If the router is authorized to route any
      prefix, a single ipAddress value appears with the issuer value of the certificate must be considered as a valid
   source of authority
      unspecified address.

6.6  Processing Rules for certifying address usage, Routers

   Routers SHOULD possess a key pair and must be capable
   of making statements about an individual's use 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 addresses.
   Theoretically, proper use Hop Limit field has a value of certificates provides more assurance
   about address usage authorization than CGA.  However, it is often
   practically difficult to arrange 255, i.e., the certificate authorities so that
   they can control which IP addresses can be used by which parties.
   The authorization provide packet could
      not possibly have been forwarded by CGA a router.

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

   o  ICMP Checksum is computational in nature, deriving
   its strength valid.

   o  ICMP Code is 0.

   o  ICMP length (derived from the computational difficulty 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 creating duplicate
   CGA addresses.  It does not require any configuration tasks, and it
   does not impose any requirements on the infrastructure.
   Respectively, certificate based authorization is administrative in
   nature, Reserved field, and does not impose restrictions to the structure of any unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to the
   addresses.

   CGAs are particularly useful for Neighbor Discovery because they
   provide a low overhead way for protocol
   may specify the sender contents of a Neighbor Advertisement
   to indicate their authorization for claiming the address. Reserved field or add new options;
   backward-incompatible changes may use different Code values.  The
   recipient
   contents of a Neighbor Advertisement any defined options that are not specified to be used
   with a CGA Address, a public
   key, Router Solicitation messages MUST be ignored and a digital signature in the header can have confidence that:

   o  The packet was not modified
   processed in transit (due to the signature),

   o normal manner.  The sender of the packet has a right to claim possession of only defined option that may
   appear is the
      address (due to Trusted Root option.  A solicitation that passes the authenticated CGA address).

   In this section, we describe how
   validity checks is called a sender generates CGA addresses and
   digital signatures "valid solicitation".

   Routers MAY send unsolicited Delegation Chain Advertisements for the AH header in Neighbor Advertisement
   packets, and how the receiver of
   their trusted root.  When such a packet verifies it.  The
   description of CGA use advertisements are sent, their timing
   MUST follow the rules given for IPv6 Neighbor Discovery follows closely
   that described Router Advertisements in [24].

5.1 Address Format RFC 2461
   [6].  The basic idea behind CGA addresses only defined option that may appear is the Certificate
   option.  At least one such option MUST be present.  Router SHOULD
   also include at least one Trusted Root option to use some function of indicate the
   host's public key as input trusted
   root on which the Certificate is based.

   In addition to sending periodic, unsolicited advertisements, a hash function router
   sends advertisements in response to generate valid solicitations received on
   an advertising interface.  A router MUST send the
   interface identifier (bottom 64 bits) response to the
   all-nodes multicast address, if the source address in the IPv6
   solicitation was the unspecified address.
   Variations on this basic theme provide additional security against
   denial of service attacks and futureproofing against increases in
   attacker processing power due to Moore's Law.  For purposes of secure
   Neighbor Discovery, CGA addresses are modified EUI-64 addresses [1]
   in which  If the source address was
   a unicast address, the router MUST send the "universal/local" bit (bit 6) is set response to 1 (indicating
   global scope) and the "individual/group" bit (bit 7) is set
   securely-solicited-node multicast address corresponding to 1
   (indicating the CGA group).  Correct handling of these bits
   effectively reduces the size of the interface identifier to 62 bits.

5.2 Basic Interface Identifier Generation

   The basic hash algorithm for CGA addresses generates source
   address.

   In a 160 bit hash
   by concatenating solicited advertisement, the node's public key, router SHOULD include suitable
   Certificate options so that a nonce, and routing prefix
   for the address in question.  This result is then hashed delegation chain to obtain the actual interface identifier. solicited root
   can be established.  The input hash is generated as
   follows:

   Equation (1).
       H(N) = Hash-160(public_key |
                       nonce |
                       routing_prefix)
       H(i) = Hash-160(H(i+1))

   where Hash-160 root is identified by the 160 bits obtained FQDN from applying the SHA-1
   secure hashing algorithm [12], public_key is the node's public key
   Trusted Root option being equal to an FQDN in the format defined in Section 7.1.2, and nonce is a random octet
   string AltSubjectName
   field of 8 or more bytes. the root's certificate.  The selection N router SHOULD include the
   Trusted Root option(s) in the advertisement for which the delegation
   chain was found.

   If the router is unable to find a local matter, but chain to the requested root, it
   MUST be at least 3.  N
   SHOULD send an advertisement without any certificates.  In this case
   the router SHOULD include the Trusted Root options which were
   solicited.

   Rate limitation of Delegation Chain Advertisements is used performed as a defense mechanism against
   denial-of-service attacks.

   The routing_prefix
   specified for Router Advertisements in RFC 2461 [6].

6.7  Processing Rules for Hosts

   Hosts SHOULD possess the certificate of at least one certificate
   authority, and MAY possess their own key pair and certificate from
   this 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 is the routing prefix for the address in question. a unicast address.  Note that routers may use
      multiple addresses, so this value is used regardless of whether address not sufficient for the scope unique
      identification of routers.

   o  IP Destination Address is either the all-nodes multicast address to be generated is link-local, site-local,
      or global.  If the
   scope is securely-solicited-node multicast address corresponding to
      one of the unicast addresses assigned to the host.

   o  The IP Hop Limit field has a value of 255, i.e., the packet could
      not global, it is possible that different networks will be
   using possibly have been forwarded by a router.

   o  If the same routing prefix, such as message includes an IP Authentication Header, the FE80::/10 prefix for
   link-local addresses.  This message
      authenticates correctly.

   o  ICMP Checksum is allowed, as valid.

   o  ICMP Code is 0.

   o  ICMP length (derived from the addresses are not used
   in IP length) is 16 or more octets.

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

   The contents of the same network.  In Reserved field, and of any case, other components in Equation (1)
   typically provide sufficient randomness unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to avoid collisions and
   Duplicate Address Detection would avoid possibly remaining address
   collisions.

   The host generates a series the protocol
   may specify the contents of these hash the Reserved field or add new options;
   backward-incompatible changes may use different Code values.  The actual
   interface identifier is then generated by performing taking the
   rightmost 60 bits
   contents of the SHA-1 hash applied any defined options that are not specified to be used
   with Delegation Chain Advertisement messages MUST be ignored and the input value:

   Equation (2).
       interface_id = Hash-60(H(i))

   where Hash-60
   packet processed in the normal manner.  The only defined option that
   may appear is the rightmost 60 bits obtained from the application
   of Certificate option.  An advertisement that passes
   the SHA-1 algorithm, i starts at 0 and increases depending on
   whether additional rounds of duplicate address detection must be
   negotiated (see Section 5.4).

   The routing_prefix term validity checks is included called a "valid advertisement".

   Hosts SHOULD store all certificates retrieved in the above Delegation Chain
   Advertisements for use in order subsequent verification of Neighbor
   Discovery messages.  Note that it may be useful to
   introduce a strong binding between the prefixes and interface
   identifiers, cache this
   information and implied verification results for use over multiple
   attachments to add some randomness in the network.  In order to defeat brute
   force and birthday attacks.  If it is not included, use an attacker can
   generate a lookup table of key pairs advertisement for each of the possible 2**60
   values
   verification of a specific Neighbor Discovery message, the interface identifier and use them to disrupt duplicate
   address detection.  Note, however, that including these host
   matches the key hash in acinfo.Holder.objectDigestInfo to the
   address requires public
   key carried in the IPsec AH Authentication Data field.

   When an interface becomes enabled, a host may be unwilling to perform duplicate address detection for
   each address configured on the interface, not just wait
   for the link local
   address, as is allowed next unsolicited Delegation Chain Advertisement.  To obtain
   such advertisements quickly, a host SHOULD transmit up to
   MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages each
   separated by RFC 2462.

5.3 Address Generation

   Equation (2) in Section 4.1.1 only takes 60 bits of the SHA-1 hash,
   although 62 bits are theoretically available at least RTR_SOLICITATION_INTERVAL seconds.  Delegation
   Chain Solicitations SHOULD be sent after the "u" and "g"
   bits are omitted.  This is because the right most 2 bits of the
   interface identifier are reserved for a security parameter.  The
   security parameter can have a value of 0 through 3, and is a way any of
   future-proofing the CGA address against increases in processing power
   in attackers due to Moore's Law, since 62 bits following events:

   o  The interface is on the borderline
   of what initialized at system startup time.

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

   o  The system changes from being a router to attack.  Conceptually,
   the security parameter is being a way host, by having
      its IP forwarding capability turned off by system management.

   o  The host attaches to increase the computational effort
   of both generating and attacking an address.  While this has the side
   effect of increasing the effort a link for the client, the client presumably
   only first time.

   o  A movement has to generate the address once, while an attacker may have to
   generate the address multiple times. been indicated by lower layers or has been inferred
      from changed information in a Router Advertisement.

   o  The algorithm host re-attaches to a link after being detached for generating the actual address is as follows, given
   the security parameter some time.

   o  A Router Advertisement has value Sec:

   1.  Generate been received with a public key pair.

   2.  Generate a nonce value.

   3.  Generate a table of hash values according to Equation (1).

   4.  Generate a target identifier according to Equation (2), but
       taking 20 x Sec + 60 bits instead of just 60 bits.

   5.  Compare the leftmost 20 x Sec to zero.  If that is
      not zero, go back to
       Step 2.

   6.  Set the universal and group bits to 1 and stored in the rightmost two bits hosts' cache of certificates, or there is no
      authorization delegation chain to Sec.

   7.  Use the result of Step 6 as host's trusted root.

   Delegation Chain Solicitations MUST NOT be sent if the interface identifier host has a
   currently valid certificate chain for the
       address.

   If the security parameter is zero, this algorithm is router to a trusted root,
   including the basic CGA
   algorithm.

   If Attribute Certificate for the security parameter is greater than zero, desired router (or host).

   A host MUST send Delegation Chain Solicitations either to the algorithm is
   All-Routers multicast address, if it has not
   guaranteed to terminate after selected a certain number of iterations (though default
   router yet, or to the default router's IP address if it will ultimately terminate).  For security parameter values 1, 2,
   and 3, has already
   been selected.

   If two hosts communicate with the average number of iterations required to produce a
   matching hash output are 2**19, 2**39, solicitations and 2**59, i.e.  2**(20 x Sec
   -1) [24].  The additional amount of computational effort involved in
   increasing the security parameter allows advertisements,
   the SEND algorithm solicitations MUST be sent to scale
   as Moore's law increases processing power.

5.4 Duplicate Address Detection

   During Duplicate Address Detection, a node may encounter a clash with
   another node on the link.  One possible denial securely-solicited-node
   multicast address of service attack
   occurs when the attacker deliberately provokes an address clash, receiver.  The advertisements MUST be sent
   as specified above for routers.

   Delegation Chain Solicitations SHOULD be rate limited and timed
   similarly with Router Solicitations, as specified in
   order to prevent the victim from claiming the address. RFC 2462 [7]
   inadvertently facilitates this attack, by requiring nodes to
   terminate Duplicate Address Detection when 2461 [6].

   When processing a clash is detected.

   For Secure Neighbor Discovery, possible advertisement sent as a node performs Duplicate Address
   Detection response to a maximum of 3 times.  If an address clash is detected,
   solicitation, the
   node restarts interface identifier generation at Step 2 of host MAY prefer to process first those
   advertisements with the
   algorithm described same Identifier field value as in Section 4.1.2, by selecting a different hash
   input for target identifier generation.  If clashes are detected
   after three tries, the node is probably under attack, so it should
   shut down and report
   solicitation.  This makes Denial-of-Service attacks against the situation
   mechanism harder (see Section 13.3).

7. IPsec Extensions

   In order to an administrator.

6. Authorization Delegation Discovery

   Several protocols, including IPv6 use IPsec in securing Neighbor Discovery, allow a node to
   automatically configure itself based on information it learns shortly
   after connecting to and Router Discovery some
   extensions have been specified in this document.  These include a new link.  It is particularly easy
   transform suitable for "rogue"
   routers to be configured, and it is particularly difficult the use of public keys and/or CGAs, a
   timestamp mechanism suitable for replay protection in a
   network node multicast
   environment, and some extensions to distinguish between valid security association and invalid sources of
   information when the node needs this information before security
   policy databases.

   These changes are related to
   communicate off-link.

   Since the newly-connected node likely can't communicate off-link, it
   can't be responsible for searching information to help validate proposed new transform and the
   router; however, given
   reserved SPI number, and do not represent a chain fundamental change to the
   IPsec architecture.  Some of appropriately signed certificates,
   it can check someone else's search results and conclude that the changes, such as the treatment of
   destination addresses, are also being proposed as a
   particular message comes from an authorized source.  Similarly, part of the
   router, which is already connected to
   revision of the network, IPsec standards.

7.1 The AH_RSA_Sig Transform

   The AH_RSA_Sig transform specifies how AH can if necessary
   communicate off-link be used without a
   symmetric key.  This transform introduces the use of a new reserved
   SPI number and construct a new format for the certificate chain. Authentication Data field in AH.

   AH_RSA_Sig MUST NOT be negotiated in IKE.  For consistency it has an
   IPsec DOI [4] Transform ID TBD <To Be Assigned by IANA>, however.

7.1.1 Reserved SPI Number

   The Secure Neighbor Discovery protocol introduces two new ICMPv6
   messages that can AH_RSA_Sig MUST be only be used between hosts and routers to allow with the
   client to learn reserved SPI number TBD
   <To Be Assigned by IANA>.

7.1.2 Authentication Data Format

   The format of the certificate chain with Authentication Data field in AH depends on the assistance
   chosen transform.  For the AH_RSA_Sig transform, the format is as
   follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                          Timestamp                            +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Key Information                        .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .              Digital Signature (remaining bytes)              .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meaning of the
   router.  Where hosts have certificates from fields is described below:

   Timestamp

      This 64 bit unsigned integer field contains a trusted root, these
   messages may also optionally be timestamp used between hosts to acquire the
   peer's certificate chain. for
      replay protection (the Sequence Number field in AH is not used for
      AH_RSA_Sig).  The Delegation Chain Solicitation message use of this field is sent by hosts when they
   wish to request the certificate chain between a router and discussed in Section 7.1.4.

   Key Information

      This variable length field contains the one public key of the hosts' trusted roots.  The Delegation Chain Advertisement message sender.
      It also may contain some other additional information which is sent as an answer to this message, or periodically to
      necessary when CGA is used.

      The contents of the All
   Nodes multicast address.  Due to Key Information field are represented as ASN.1
      DER-encoded data item of the size following type:

        SendKeyInformation ::= SEQUENCE {
          cgaParameters  CGAParameters OPTIONAL,
          signerInfo     SubjectPublicKeyInfo OPTIONAL }

        CGAParameters ::= SEQUENCE {
          publicKey      SubjectPublicKeyInfo,
          auxParameters  CGAAuxParameters OPTIONAL }

      (The normative definition of certificates and
   potentially long certificate chains, the advertisement message may type CGAParameters is in in
      [27]).

      At least one or both fields in SendKeyInformation MUST be present.
      The packet MUST be
   large. silently discarded if both are missing.  The messages have been made separate from the rest
      verification of
   Neighbor Discovery in order to reduce their effect the CGA is based on the size contents of
   other messages.  Long certificate chains may also be broken to
   multiple messages. the
      cgaParameters field.  The Authorization Delegation Discovery process does not exclude other
   forms verification of discovering the certificate chains.  For instance, during
   fast movements mobile nodes may learn information - including Digital Signature
      field is based on the
   chains - contents of the next router from signerInfo field if it is
      present.  Otherwise, the previous router.

6.1 Delegation Chain Solicitation Message Format

   Hosts send Delegation Chain Solicitations verification is based on the publicKey
      field in order to prompt routers
   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 IP the cgaParameters field.

      This specification requires that if both cgaParameters and
      signerInfo fields are present, then the public keys in them MUST
      be the same, and 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 assigned and the signer to
      be different parties.

      The length of the Key Information field is determined by the ASN.1
      encoding.

   Digital Signature

      This variable length field contains the sending interface, or signature made using the
         unspecified address if no address
      sender's private key, over the the whole packet as defined by the
      usual AH rules [3].  The signature is assigned to made using the sending
         interface.

      Destination Address

         Typically RSA algorithm
      and MUST be encoded as private key encryption in PKCS #1 format
      [17].

      The length of this field is determined by the all-routers multicast address, or PKCS #1 encoding.

7.1.3 AH_RSA_Sig Security Associations

   Incoming security associations that specify the address use of AH_RSA_Sig
   transform MUST record the hosts' default router.

      Hop Limit

         255

   ICMP Fields:

      Type

         TBD <To following additional configuration
   information:

   CGA flag

      A flag that indicates whether or not the CGA property must be assigned by IANA>
      verified.

   router authority

      Whether or not router authority must be verified as described in
      Section 6.5.

   root

      The public key of the trusted root, if authorization delegation is
      in use.

   minbits

      The minimum acceptable key length for Delegation Chain Solicitation.

      Code

         0

      Checksum peer public keys (and any
      intermediaries between the trusted root and the peer).  The ICMP checksum [8]..

      Identifier

         This 16 bit unsigned integer field acts as
      default SHOULD be 768 bits.  Implementations MAY also set an identifier upper
      limit in order to limit the amount of computation they need to
      perform when verifying packets that use these security
      associations.

   minSec

      The minimum acceptable Sec value, if CGA verification is required
      (see Section 2 in [27].

   Outgoing security associations MUST also record the following
   additional information:

   keypair

      A public-private key pair.  If authorization delegation is in use,
      there must exist a delegation chain from a trusted root to
         help match advertisements this
      key pair.

   CGA flag

      A flag that indicates whether or not the CGA is used.

   CGA parameters

      Optionally any information required to solicitations.  The Identifier
         field MUST NOT be zero.

      Reserved

         This construct CGAs, including
      the used Sec value and nonce, and the CGA itself.

7.1.4 Replay Protection

   For AH_RSA_Sig, the Sequence Number field is unused.  It in AH MUST be initialized set to zero
   by the sender and MUST be ignored by receivers.

   If anti-replay has been enabled in the receiver.

   Valid Options:

      Trusted Root

         One or more trusted roots that security association, senders
   MUST set the client is willing Timestamp field to accept.

      Future versions the current time.  The format is 64
   bits, and the contents are the number of milliseconds since January
   1, 1970 00:00 UTC.

   If anti-replay has been enabled, receivers MUST be configured with an
   allowed Delta value and maintain a cache of messages received within
   this protocol may define new option types. time period from each specific source address.  Receivers MUST silently ignore any options they do not recognize
      and continue processing
   then check the message.

6.2 Delegation Chain Advertisement Message Format

   Routers send out Delegation Chain Advertisement messages
   periodically, or 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      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |M|        Component            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address Timestamp field as follows:

   o  A packet with a Timestamp field value beyond the current time plus
      or minus the allowed Delta value MUST be silently discarded.

      Recommended default value for the link-local address assigned allowed Delta is 3,600 seconds.

   o  A packet accepted according to the interface from
         which this message is sent.

      Destination Address

         Typically above rule MUST be checked for
      uniqueness within the Source Address cache of a host invoking Delegation
         Chain Solicitation or received messages from the all-nodes multicast given
      source address.

      Hop Limit

         255
   ICMP Fields:

      Type

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

      Code

         0

      Checksum

         The ICMP checksum [8]..

      Identifier

         This 16 bit unsigned integer field acts as an identifier to
         help match advertisements to solicitations.  The Identifier  A packet that has already been seen from the same
      source with the same Timestamp field value MUST be zero for unsolicited advertisements and silently
      discard.

   o  A packet that passes both of the above tests MUST NOT be zero registered in
      the cache for the given source address.

   o  If the cache becomes full, the receiver SHOULD temporarily reduce
      the Delta value for that source address so that all messages
      within that value can still be stored.

   Note that timestamps are not necessary for replay protection in
   solicited advertisements.

      M

         A single advertisement MUST advertisements, but must be broken into separately sent
         components if there is more than one Certificate option, included in
         order to avoid excessive fragmentation at the IP layer.  Unlike messages.

7.1.5 Processing Rules for Senders

   A node sending a packet using the fragmentation at AH_RSA_Sig transform MUST construct
   the IP layer, individual components of an
         advertisement may be stored packet as follows:

   o  The Next Header, Payload Len, and taken Reserved fields are set as
      described in use before all RFC 2402.

   o  The Security Parameters Index is set to the
         components have arrived; this makes them slightly more reliable
         and less prone value specified in
      Section 7.1.1.

   o  The Sequence Number field is set to Denial-of-Service attacks. 0.

   o  The 'M' flag,
         when set, indicates that there are more components coming in
         this advertisement.

      Component

         This Timestamp field is a 15 bit unsigned integer field. set as described in Section 7.1.4.

   o  The first message Key Information field in
         a multi-component advertisement has the Component Authentication Data field is set
      to
         0, the second set to 1, and so on.

      Reserved

         This field is unused.  It MUST be initialized SendKeyInformation structure according to zero by the
         sender rules in
      Section 7.1.2 and MUST be ignored by [27].  The used public key is the receiver.

   Valid Options:

      Certificate

         Zero or one certificates are provided stored in Certificate options,
         to establish a certificate chain to a trusted root.

      Trusted Root

         Zero or more Trusted Root options may be included
      the security association.

   o  The packet, in the form defined for AH's coverage, is signed using
      the private key in the security association, and the resulting
      PCKS #1 signature is put to help
         receivers decide which advertisements are useful the Digital Signature field.  One of
      the keys from the Key Information field is used for them.  If
         present, these options MUST appear this purpose,
      as described in Section 7.1.2.

   o  Additionally, if the first component use of a
         multi-component advertisement.

      Future versions CGA has been specified for the
      security association, the source address of this protocol may define new option types. the packet MUST be
      constructed as specified in [27].

7.1.6 Processing Rules for Receivers

   A packet received on a security association employing AH_RSA_Sig
   transform MUST silently ignore any options they do not recognize be checked as follows:

   o  Next Header and continue processing the message.

6.3 Trusted Root Option Payload Len fields are valid as specified in RFC
      2402.

   o  The format of SPI field is equal to the Trusted Root option value defined in Section 7.1.1.

   o  The Timestamp field is verified as described in Section 7.1.4.

   o  The Key Information and Digital Signature fields have correct
      encoding, and do not exceed 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 length of the Authentication Data
      field.

   o  If the use of CGA has been specified in the security association,
      we additionally require the receiving node to verify the source
      address of the packet using the algorithm described in Section 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |  Name Type    |  Name Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Name ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where
      of [27].  The inputs for the fields algorithm are as follows:

   Type

      TBD <To be assigned by IANA> for Trusted Root.

   Length

      The length the contents of the option (including
      CGAParameters structure from the Type, Length, Name Type,
      Name Length, Key Information field, the source
      address of the packet, and Name fields) the minimum acceptable Sec value from
      the security association.  If the CGA verification is successful,
      the recipient proceeds with the cryptographically more time
      consuming check of the AH signature.

      Note that a receiver which does not support CGA or has not
      specified its use in units of 8 octets.

   Name Type its security associations can still verify
      packets using trusted roots, even if CGA had been used on a
      packet.  The type CGA property of the name included address is simply left untested.

   o  The Digital Signature verification shows that it has been
      calculated as specified in the Name field.  This
      specification defines only one legal value for this field:

               1        FQDN

   Name Length

      The length of previous sections.

   o  If the Name field, in bytes.  Octets beyond this length
      but within use of a trusted root has been configured for the length specified by security
      association, a valid authorization delegation chain is known
      between the Length field are padding
      and MUST be set to zero by senders receiver's trusted root and ignored by receivers.

   Name

      When the Name Type field is set to 1, sender's public key.

      Note that the Name field contains receiver may verify just the
      Fully Qualified Domain Name CGA property of a
      packet, even if the sender has used a trusted root, for example
      "trustroot.operator.com".

6.4 Certificate Option

   The format of the certificate option is root as described in well.

   Packets that do not pass all 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 above tests MUST be silently
   discarded.

7.2 Other IPsec Extensions

7.2.1 Destination Agnostic Security Associations

   In order to allow the fields are as follows:

   Type

      TBD <To same security association to be assigned by IANA> for Certificate.

   Length

      The length of used when the option (including
   the Type, Length, Cert Type,
      Pad Length, node sends packets to different peers using the same addresses,
   an extension must be provided to the RFC 2401 rules on how security
   associations are identified.  This change is particularly important,
   for instance, when routers use the same keys and Certificate fields) in units of 8 octets.

   Cert Type

      The type security association
   to send Router Advertisements for up to number of prefixes x 2^64
   hosts on an interface.

   This extension is mandatory for all nodes that support the certificate included in AH_RSA_Sig
   transform.  Security associations that use the Name field.  This
      specification defines only one legal SPI value for specified in
   Section 7.1.1 MUST be identified solely by the SPI and protocol
   numbers, not by the destination IP address.

   Note that this field:

               1        X.509 Certificate
   Pad Length

      The amount extension can be supported without implementation
   modifications where the proposed revisions of padding beyond the end IPsec standards are
   in use [26].

7.2.2 ICMP Type Specific Selectors

   In order to allow finer granularity of protection for various ICMPv6
   messages, it is necessary to extend the Certificate field but
      within security policy database and
   security association selectors with the length specified by capability to distinguish
   between different messages.

   All nodes that support the Length field.  Padding AH_RSA_Sig transform MUST be
      set to zero by senders capable of
   using ICMP and ignored ICMPv6 Type field as a selector.

   Note that this can be achieved in an implementation by receivers.

   Certificate

      When using the port
   number field to contain the Cert Type ICMP type if the protocol field is set ICMP.

8. Securing Neighbor Discovery with SEND

   This section describes how to 1, use IPsec and the Certificate field
      contains an X.509 certificate [10].

6.5  Processing Rules mechanisms from [27],
   Section 6, Section 7 in order to provide security for Routers

   Routers SHOULD possess a keypair Neighbor
   Discovery.

8.1 Neighbor Solicitation Messages

   All Neighbor Solicitation messages are protected with AH_RSA_Sig.

8.1.1 Sending Secure Neighbor Solicitations

   Secure Neighbor Solicitation messages are sent as described in RFC
   2461 and certificate from at least one
   certificate authority.

   A router MUST silently discard any received Delegation Chain 2462, with the additional requirements listed in the
   following.

   All Neighbor Solicitation messages that do not satisfy all of sent MUST be protected with IPsec,
   using the following
   validity checks:

   o AH_RSA_Sig transform.  The IP Hop Limit field has a value of 255, i.e., security associations used for
   this MUST be configured with the packet could
      not possibly have been forwarded by a router.

   o  If sender's key pair, optionally
   setting the message includes an IP Authentication Header, CGA flag and including additional CGA parameter
   information.

   The source address of the message
      authenticates correctly.

   o  ICMP Checksum is valid.

   o  ICMP Code is 0.

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

   o  Identifier field is non-zero.

   o  All included options have unspecified
   address.  A Neighbor Solicitation sent as a length that is greater than zero.

   The contents part of Duplicate Address
   Detection MUST use as a source address the Reserved field, and of any unrecognized options, tentative address for
   which the Duplicate Address Detection is being run.

   In SEND, Neighbor Solicitations MUST be ignored.  Future, backward-compatible changes sent either to the protocol
   may specify target
   address or to the contents securely-solicited-node multicast address
   corresponding to the target address.  When an interface is
   initialized, a node MUST join securely-solicited-node multicast
   address corresponding to each of the Reserved field or add new options;
   backward-incompatible changes may use different Code values. IP addresses assigned to the
   interface.  The
   contents set of any defined options that are not specified addresses assigned to an interface may change
   over time.  New addresses might be used
   with Router Solicitation messages MUST added and old addresses might be ignored
   removed [7].  In such cases the node MUST join and leave the packet
   processed as normal.  The only defined option that may appear is
   securely-solicited-node multicast address corresponding to the
   Trusted Root option.  A solicitation new
   and old addresses, respectively.  Note that passes multiple unicast
   addresses may map into the validity checks
   is called same solicited-node multicast address; a "valid solicitation".

   Routers MAY send unsolicited Delegation Chain Advertisements for
   their trusted root.  When such advertisements are sent, their timing
   node MUST follow NOT leave the rules given for Router Advertisements securely-solicited-node multicast group until
   all assigned addresses corresponding to that multicast address have
   been removed.

   The Nonce option MUST be included in all messages.

8.1.2 Receiving Secure Neighbor Solicitations

   Received Neighbor Solicitation messages are processed as described in
   RFC 2461
   [6].  The only defined option that may appear is and 2462, with the Certificate
   option.  At least one such option additional SEND-related requirements
   listed in the following.

   Neighbor Solicitation messages received without an IPsec AH header
   and the AH_RSA_Sig transform MUST be present.  Router SHOULD
   also include at least one Trusted Root option to indicate silently discarded.  The
   security associations used for this MUST be configured with the
   expected authorization mechanism (CGA or trusted
   root on which root), 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.  A router MAY choose to unicast minimum
   allowable key size, and optionally with the
   response directly information related to
   the soliciting host's address (if trusted root and the
   solicitation's acceptable minSec value.

   If source address is not the unspecified address), but of the usual case Neighbor Solicitation message is to multicast the response to the all-nodes group.

   In a solicited advertisement, the router SHOULD include suitable
   Certificate options so that a delegation chain to
   unspecified address, the solicited root
   can message MUST be established.  The root is identified by the FQDN from silently discarded.

   Neighbor Solicitations received without the
   Trusted Root Nonce option being equal to an FQDN MUST be
   silently discarded.

8.2 Neighbor Advertisement Messages

   All Neighbor Advertisement messages are protected with AH_RSA_Sig.

8.2.1 Sending Secure Neighbor Advertisements

   Secure Neighbor Advertisement messages are sent as described in RFC
   2461 and 2462, with the AltSubjectName
   field of the root's certificate.  The router SHOULD include the
   Trusted Root option(s) additional requirements listed in the advertisement
   following.

   All Neighbor Advertisement messages sent MUST be protected with
   IPsec, using the AH_RSA_Sig transform.  The security associations
   used for which this MUST be configured with the delegation
   chain was found.

   If sender's key pair,
   optionally setting the router is unable CGA flag and including additional CGA
   parameter information.

   Neighbor Advertisements sent in response to find a chain to the requested root, it
   SHOULD send an advertisement without any certificates.  In this case Neighbor Solicitation
   MUST contain a copy of the router SHOULD include Nonce option included in the Trusted Root options which were
   solicited.

   Rate limitation solicitation.

   The source address of Delegation Chain the message MUST NOT be the unspecified
   address.

8.2.2 Receiving Secure Neighbor Advertisements is performed

   Received Neighbor Advertisement messages are processed as
   specified for Router Advertisements described
   in RFC 2461 [6].

6.6  Processing Rules for Hosts

   Hosts SHOULD possess the certificate of at least one certificate
   authority, and MAY possess their own keypair and certificate from
   this authority.

   A host MUST silently discard any received Router Advertisement
   messages that do not satisfy all of 2462, with the following validity checks:

   o  IP Source Address is a link-local address.  Routers must use their
      link-local address as additional SEND-related requirements
   listed in the source for Router following.

   Neighbor Advertisement and
      Redirect messages so that hosts can uniquely identify routers.

   o  The IP Hop Limit field has a value of 255, i.e., the packet could
      not possibly have been forwarded by a router.

   o  If the message includes received without an IP Authentication Header, IPsec AH header
   and the message
      authenticates correctly.

   o  ICMP Checksum is valid.

   o  ICMP Code is 0.

   o  ICMP length (derived from AH_RSA_Sig transform MUST be silently discarded.  The
   security associations used for this MUST be configured with the IP length) is 16
   expected authorization mechanism (CGA or more octets.

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

   The contents of trusted root), the Reserved field, minimum
   allowable key size, and of any unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to optionally with the protocol
   may specify information related to
   the contents of trusted root and 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 acceptable minSec value.

   Received Neighbor Advertisements sent to be used
   with Router Advertisement messages a unicast destination
   address without a Nonce option MUST be ignored and silently discarded.

   If source address of the packet
   processed as normal.  The only defined option that may appear Neighbor Advertisement message is the
   Certificate option.  An advertisement that passes
   unspecified address, the validity checks
   is called message MUST be silently discarded.

8.3 Other Requirements

   Upon receiving a "valid advertisement".

   Hosts SHOULD store all certificates retrieved in Delegation Chain
   Advertisements message for use in subsequent verification of Router (and
   optionally Neighbor) Advertisements.  Note that it may be useful which the receiver has no certificate
   chain to
   cache this information and implied verification results for a trusted root, the receiver MAY use over
   multiple attachments Authorization
   Delegation Discovery to learn the network.

   When an interface becomes enabled, certificate chain of the peer.

   Hosts that use stateless address autoconfiguration MUST generate a host may be unwilling to wait
   new CGA as specified in Section 4 of [27] for each new
   autoconfiguration run.

   It is outside the next unsolicited Delegation Chain Advertisement.  To obtain
   such advertisements quickly, a host SHOULD transmit up scope of this specification to
   MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages each
   separated by at least RTR_SOLICITATION_INTERVAL seconds.  Delegation
   Chain Solicitations describe the use of
   trusted root authorization between hosts with dynamically changing
   addresses.  Such dynamically changing addresses may be sent after any the result of
   stateful or stateless address autoconfiguration or through the following events:

   o  The interface is initialized at system startup time.

   o  The interface use of
   RFC 3041 [9].  If the CGA method is reinitialized after not used, hosts would be required
   to exchange certificate chains that terminate in a temporary interface failure
      or after being temporarily disabled by system management.

   o  The system changes from being certificate
   authorizing a router host to being a host, by having
      its use an IP forwarding capability turned off 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 system management.

   o  The host attaches the link layer and it is up to a the link
   layer to provide certification for the first time.

   o  A movement has been indicated 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.4 Configuration

   This section shows example security policy and security associations
   database entries for the protection of Neighbor Solicitation and
   Advertisement messages.  The following table summarizes the inbound
   security policy data base along with the inbound security
   associations:

   Policy entries:

    +------------------------------------------------------------------+
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    +------------------------------------------------------------------+
    |    ICMPv6: NS    |       *      |       own        |  SA = NS_In |
    +------------------------------------------------------------------+
    |    ICMPv6: NS    |       *      |  sec-sol-node MC |  SA = NS_In |
    +------------------------------------------------------------------+
    |    ICMPv6: NA    |       *      |       own        |  SA = NA_In |
    +------------------------------------------------------------------+
    |    ICMPv6: NA    |       *      |   all-nodes MC   |  SA = NA_In |
    +------------------------------------------------------------------+

   Security associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto |    Transform    |
    +------------------------------------------------------------------+
    |    NS_In   |   Inbound   | To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    NA_In   |   Inbound   | To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by lower layers or has been inferred
      from changed information in a Router Advertisement.

   o IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+

   The host re-attaches to a link after being detached for some time.

   o  A Router Advertisement has been received with a public following table summarizes outbound security policy database:

   Policy entries:

    +------------------------------------------------------------------+
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    +------------------------------------------------------------------+
    |    ICMPv6: NS    |      own     |         *        | SA = NS_Out |
    +------------------------------------------------------------------+
    |    ICMPv6: NA    |      own     |         *        | SA = NA_Out |
    +------------------------------------------------------------------+

   Security associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto |    Transform    |
    +------------------------------------------------------------------+
    |    NS_Out  |  Outbound   | To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       | key that is
      not stored in the hosts' cache of certificates, or there is no
      authorization delegation chain to the host's trusted root.

   Delegation Chain Solicitations MUST NOT pair = ...  |
    |            |             | by IANA     |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    NA_Out  |  Outbound   | To be sent if a valid
   certificate chain exists in the host's cache from the desired router
   (or host) to the host's trusted root.

   A host MUST send Delegation Chain Solicitations either       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       | key pair = ...  |
    |            |             | by IANA     |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+

9. Securing Router Discovery with SEND

   This section describes how to use IPsec and the
   All-Routers multicast address, if it hasn't selected a default router
   yet, or mechanisms from [27],
   Section 6, Section 7 in order to the default router's IP address if it has already been
   selected.  If two hosts communicate provide security for Router
   Discovery.

9.1 Router Solicitation Messages

   All Router Solicitation messages are protected with the solicitations and
   advertisements, these MUST be unicast to the hosts's address.

   Delegation Chain AH_RSA_Sig.

9.1.1 Sending Secure Router Solicitations SHOULD be rate limited and timed
   similarly with

   Secure Router Solicitations, Solicitation messages are sent as specified described in RFC 2461 [6].

   When processing a possible advertisement sent as a response to a
   solicitation, the host MAY prefer to process first those
   advertisements
   2461, with the same Identifier field value as additional requirements listed in the
   solicitation.  This make Denial-of-Service attacks against the
   mechanism harder (see Section 12.2).

7. IPsec Extensions

   In order to use IPsec in securing Neighbor and following.

   All Router Discovery some
   extensions have been specified in this document.  These include a new
   transform suitable for Solicitation messages sent MUST be protected with IPsec,
   using the use of public keys and/or CGAs, a
   timestamp mechanism suitable for replay protection in a multicast
   environment, and some extensions to security association and security
   policy databases.

7.1 The AH_RSA_Sig Transform transform.  The AH_RSA_Sig transform specifies how AH can be security associations used without a
   symmetric key.  This transform introduces for
   this MUST be configured with the sender's key pair, optionally
   setting the CGA flag and including additional CGA parameter
   information.

   Hosts SHOULD avoid the use of a new reserved
   SPI number and a new format for the Authentication Data field unspecified address as the source
   address in AH.

   AH_RSA_Sig a Router Solicitation message, if other addresses are
   available.

   The Nonce option MUST NOT be negotiated included in IKE.  For consistency it has all messages.

9.1.2 Receiving Secure Router Solicitations

   Received Router Solicitation messages are processed as described in
   RFC 2461, with the additional SEND-related requirements listed in the
   following.

   Router Solicitation messages received without an IPsec DOI [4] Transform ID TBD <To Be Assigned by IANA>, however.

7.1.1 Reserved SPI Number

   The AH header and
   the AH_RSA_Sig transform MUST be only be silently discarded.  The security
   associations used for this MUST be configured with the reserved SPI number TBD
   <To Be Assigned by IANA>.

7.1.2 Authentication Data Format

   The format of expected
   authorization mechanism (CGA or trusted root), the Authentication Data field in AH depends on minimum allowable
   key size, and optionally with the
   chosen transform.  For information related to the AH_RSA_Sig transform, trusted
   root and the format is as
   follows:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            PK_Len             |          Nonce_Len            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                          Timestamp                            +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                          Public key                           .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                       Nonce (optional)                        .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .              Digital Signature (remaining bytes)              .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meaning of acceptable minSec value.

   Router Solicitations received without the fields is Nonce option MUST be
   silently discarded.

9.2 Router Advertisement Messages

   All Router Advertisement messages are protected with AH_RSA_Sig.

9.2.1 Sending Secure Router Advertisements

   Secure Router Advertisement messages are sent as described below:

   PK_Len

      This 16 bit unsigned integer field contains the length of in RFC
   2461, with the
      Public Key field additional requirements listed in bytes.

   Nonce_Len

      This 16 bit unsigned integer field contains the length of following.

   All Router Advertisement messages sent MUST be protected with IPsec,
   using the
      Nonce field in bytes. AH_RSA_Sig transform.  The length is set to zero if that field is
      not present.

   Timestamp

      This 64 bit unsigned integer field contains a timestamp used for
      replay protection (the Sequence Number field in AH is not security associations used for
      AH_RSA_Sig).  The use of
   this field is discussed in Section 7.1.4.

   Public key

      This variable length field contains MUST be configured with the public sender's key of pair, optionally
   setting the sender CGA flag and including additional CGA parameter
   information.

   Router Advertisements sent in X.509 format [10].

   Nonce

      This variable length field, if present, contains response to a Router Solicitation MUST
   contain a copy of the nonce used Nonce option included in the construction solicitation.

   The source address of the CGA message MUST NOT be the unspecified
   address.

   Digital Signatures

      This variable length field, if present, contains

9.2.2 Receiving Secure Router Advertisements

   Received Router Advertisement messages are processed as described in
   RFC 2461, with the signature
      made using additional SEND-related requirements listed in the sender's private key, over
   following.

   Router Advertisement messages received without an IPsec AH header and
   the AH_RSA_Sig transform MUST be silently discarded.  The security
   associations used for this MUST be configured with the expected
   authorization mechanism (CGA or trusted root), the whole packet as
      defined by minimum allowable
   key size, and optionally with the usual AH rules [3].  The signature information related to the trusted
   root and the acceptable minSec value.

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

   If source address of the Router Advertisement message is made using the RSA algorithm and
   unspecified address, the message MUST be encoded silently discarded.

9.3 Redirect Messages

   All Redirect messages are protected with AH_RSA_Sig.

9.3.1 Sending Redirects

   Secure Redirect messages are sent as private key encryption described in
      PKCS #1 format [11].

7.1.3 AH_RSA_Sig Security Associations

   Security associations that specify RFC 2461, with the use of AH_RSA_Sig transform
   additional requirements listed in the following.

   All Redirect messages sent MUST record be protected with IPsec, using the following additional configuration information:

   o  A flag that indicates whether or not authorization delegation to a
      trusted root is used.

   o  A flag that indicates whether or not CGA addresses are used.

   Incoming
   AH_RSA_Sig transform.  The security associations used for this MUST also record
   be configured with the following sender's key pair, optionally setting the CGA
   flag and including additional information:

   o CGA parameter information.

   The public key source address of the trusted root, if authorization delegation is Redirect message MUST NOT be the
   unspecified address.

9.3.2 Receiving Redirects

   Received Redirect messages are processed as described in use.

   o  The minimum acceptable key length for peer public keys (and any
      intermediaries between RFC 2461,
   with the trusted root and additional SEND-related requirements listed in the peer).  The
      default SHOULD be 768 bits.  Implementations MAY also set
   following.

   Redirect messages received without an upper
      limit in order to limit IPsec AH header and the amount of computation they need to
      perform when verifying packets that use these security
      associations.

   o
   AH_RSA_Sig transform MUST be silently discarded.  The minimum acceptable Sec value, if CGA verification is required.

   Outgoing security
   associations used for this MUST also record be configured with the following
   additional information:

   o  A public-private keypair.  If expected
   authorization delegation is in use,
      there must exist a delegation chain from a trusted root to this
      keypair.

   o  Optionally any mechanism (CGA or trusted root), the minimum allowable
   key size, and optionally with the information required related to construct CGA signatures,
      including the used Sec value and nonce, trusted
   root and the resulting CGA
      address.

7.1.4 Replay Protection

   For AH_RSA_Sig, acceptable minSec value.

   If only CGA-based security associations are used, hosts MUST follow
   the Sequence Number field in AH rules defined below when receiving Redirect messages:

   1.  The Redirect message MUST be set protected as discussed above.

   2.  The receiver MUST verify that the Redirect message comes from an
       IP address to zero
   by which the sender and ignored by receivers.

   If anti-replay has been enabled in host may have earlier sent the security association, senders
   MUST set packet
       that the Timestamp field to Redirect message now partially returns.  That is, the current time.  The format is 64
   bits, and
       source address of the contents are Redirect message must be the number default router
       for traffic sent to the destination of milliseconds since January
   1, 1970 00:00 UTC. the returned packet.  If anti-replay has been enabled, receivers
       this is not the case, the message MUST be configured with an
   allowed Delta value and maintain silently discarded.

       This step prevents a cache of messages received within
   this time period bogus router from each specific source address.  Receivers MUST
   then check sending a Redirect message
       when the Timestamp field host is not using the bogus router as follows:

   o  A packet with a Timestamp field value beyond default router.

   If source address of the current time plus
      or minus Redirect message is the unspecified address,
   the message MUST be silently discarded.

9.4 Other Requirements

   The certificate for a router MAY specify the global IP address(es) of
   the router.  If so, only these addresses can appear in advertisements
   where the allowed Delta value Router Address (R) bit [15] is set.  All hosts MUST be silently discarded.

   o  A packet accepted according have
   the certificate of a trusted root.

   Hosts SHOULD use Authorization Delegation Discovery to learn the above rule MUST be checked
   certificate chain of their default router or peer host, as explained
   in Section 6.  The receipt of a protected Router Advertisement
   message for which no router Authorization Certificate and certificate
   chain is available triggers Authorization Delegation Discovery.

9.5 Configuration

   This section shows example security policy and security associations
   database entries for
      uniqueness within the cache protection of received messages from the given
      source address.  A packet that has already been seen from Redirect, Router Solicitation
   and Advertisement messages.  The following table summarizes the same
      source
   inbound security policy data base along with the same Timestamp field value MUST inbound security
   associations:

   Policy entries:

    +------------------------------------------------------------------+
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    +------------------------------------------------------------------+
    |    ICMPv6: RS    |       *      |       own        |  SA = RS_In |
    +------------------------------------------------------------------+
    |    ICMPv6: RS    |       *      |  all-routers MC  |  SA = RS_In |
    +------------------------------------------------------------------+
    |    ICMPv6: RA    |       *      |       own        |  SA = RA_In |
    +------------------------------------------------------------------+
    |    ICMPv6: RA    |       *      |   all-nodes MC   |  SA = RA_In |
    +------------------------------------------------------------------+
    | ICMPv6: REDIRECT |       *      |       own        |  SA = RE_In |
    +------------------------------------------------------------------+

   Security associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto |    Transform    |
    +------------------------------------------------------------------+
    |    RS_In   |   Inbound   | To be silently
      discard.

   o  A packet that passes both of the above tests MUST       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RA_In   |   Inbound   | To be registered in
      the cache for the given source address.

   o  If the cache becomes full, the receiver SHOULD temporarily reduce
      the Delta value for that source address so that all messages
      within that value can still       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RE_In   |   Inbound   | To be stored.

7.1.5 Processing Rules for Senders

   A node sending a packet using the       |   AH  |    AH_RSA_Sig transform MUST construct
   the packet as follows:

   o   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+

   The Next Header, Payload Len, following table summarizes outbound security policy database.
   The Router Advertisement and Reserved fields Redirect entries are set as
      described only present in RFC 2402.

   o  The
   routers.

   Policy entries:

    +------------------------------------------------------------------+
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    +------------------------------------------------------------------+
    |    ICMPv6: RS    |      own     |         *        | SA = RS_Out |
    +------------------------------------------------------------------+
    |    ICMPv6: RA    |      own     |         *        | SA = RA_Out |
    +------------------------------------------------------------------+
    | ICMPv6: REDIRECT |      own     |         *        | SA = RE_Out |
    +------------------------------------------------------------------+

   Security Parameters Index is set to the value specified in
      Section 7.1.1.

   o  The Sequence Number field is set to 0.

   o  The PK_Len field in Authentication Data is set to the length of
      the public key used for signing this packet.  This public key is
      stored in the security association.  The associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto |    Transform    |
    +------------------------------------------------------------------+
    |    RS_Out  |  Outbound   | To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       | key itself is put to the
      Public pair = ...  |
    |            |             | by IANA     |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RA_Out  |  Outbound   | To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       | key field.

   o  If the security association has specified the use of the pair = ...  |
    |            |             | by IANA     |       | CGA
      method, the Nonce_len field is set to the length of the nonce used
      in the construction of the = yes/no    |
    |            |             |             |       | CGA address.  In this case the nonce is
      copied to the Nonce field.  Otherwise, the Nonce_Len field is set
      to zero and the Nonce field is omitted.

   o  The Timestamp field is set as described in Section 7.1.4.

   o  The packet, in the form defined for AH's coverage, is signed using
      the private params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RE_Out  |  Outbound   | To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       | key in the security association, and the resulting
      PCKS #1 signature is put to the Digital Signature field.

   o  Additionally, if the use of pair = ...  |
    |            |             | by IANA     |       | CGA = yes/no    |
    |            |             |             |       | CGA has been specified for the
      security association we require that the source address params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+

10. Co-Existence of the
      packet has been constructed as specified in Section 5.  A sending
      node uses as inputs the sender's public key, nonce, the subnet
      prefix from the Target Address, and the Target Link Layer Address.
      The Target Address (including the subnet prefix) is put to the
      Source Address field in the IPv6 header, and the public key SEND and ND

   During the nonce are put transition to the Authentication Data field in the AH
      header.

7.1.6 Processing Rules for Receivers

   A packet received on a security association employing AH_RSA_Sig
   transform MUST be checked as follows:

   o  Next Header and Payload Len fields are valid secure links or as specified in RFC
      2402.

   o  The SPI field is equal a policy consideration,
   network operators may want to the value defined in Section 7.1.1.

   o  The sum of the PK_Len, Nonce_Len, and LLA_Len fields does not
      exceed the length of the Authentication Data field.

   o  The Nonce_Len field is non-zero if the use of CGA has been
      specified in the security association.

   o  The Timestamp field is verified as described in Section 7.1.4.

   o  If the use of CGA has been specified in the security association,
      we additionally require that A node receiving an Neighbor or
      Router Advertisement message run a particular link with CGA protection first checks the
      CGA address in the Target Address field by generating the address
      using the algorithm described in Section 5.3.  The inputs for the
      algorithm are the sender's public key a mixture of
   secure and nonce, included in insecure nodes.  In such a case, the
      AH packet link is required to
   operate as described in Section 7.1.2, the subnet prefix from
      the Target Address, the Target Link Layer Address, which MUST be
      included in two separate logical links, and packets between a Target Link Layer Address option, secure
   and insecure node always go through the security
      parameter from the rightmost router.

   Routers configured for SEND advertise two bits sets of globally routable
   prefixes: one set for SEND nodes and one set for nodes that implement
   insecure Neighbor Discovery.  The insecure nodes will ignore the Target Address.  If
      the interface identifier checks, the recipient proceeds with the
      cryptographically more time consuming check of
   advertisements sent using SEND, as the original Neighbor Discovery
   specifications require silently discarding packets if they contain an
   AH signature.

      Note header that a receiver which does not support CGA or has not
      specified its use in its security associations they can still verify
      packets using trusted roots, even if CGA had been used on a
      packet. not verify.

10.1 Behavior Rules

   The CGA property of following considerations apply to all nodes:

   o  Nodes configured for SEND MUST listen to the solicited-node
      multicast address is simply left untested.

   o in addition to the securely-solicited-node
      multicast address.  The Public key and Digital Signature fields can be correctly
      decoded, and messages received on the solicited-node
      multicast address are unprotected, but the Digital Signature verifies SEND node MUST respond
      to them as specified in
      the previous section.

   o  If the use of follows.

      Upon seeing a trusted root has been configured Neighbor Solicitation for an address which is
      currently assigned to its own interface, the security
      association, SEND node sends as a valid authorization delegation chain
      response a Neighbor Solicitation with the following contents:

      *  Source address is known
      between the receiver's trusted root and unspecified address.

      *  Destination address is the sender's public key.

      Note that solicited-node multicast address of
         the receiver may verify just target address.

      *  Target address is copied from the CGA property of original Neighbor
         Solicitation.

      *  No AH header is included.

      *  The Nonce option is included in the Neighbor Solicitation.

      As a
      packet, even if result of seeing this Neighbor Solicitation, the sender has used a trusted root as well.

   Packets of
      the original Neighbor Solicitation concludes that do not pass all it is attempting
      to use an address which another node is also attempting to use.
      This prevents the above tests MUST be silently
   discarded.

7.2 Other IPsec Extensions

7.2.1 Destination Agnostic Security Associations non-SEND node from using an address already in
      use by a SEND node.

      On some interface types, multicast messages can loop back to the
      sending node.  In order to allow prevent the same security association SEND node from responding
      to itself, the above solicitations MUST NOT be used sent when the
      original Neighbor Solicitation included the node sends packets Nonce option.

      Note that while SEND nodes attempt to different peers using the same addresses, a
   change must be provided ensure that non-SEND nodes
      use addresses not assigned to the RFC 2401 rules on how security
   associations are identified. SEND nodes, the reverse is not
      true: SEND nodes do not avoid the use of an address which is
      already claimed to be in use by a non-SEND node.  This change is particularly important,
   for instance,
      necessary in order to prevent a denial-of-service attack on secure
      Duplicate Address Detection.

   o  Similarly, when routers use performing Duplicate Address Detection, nodes
      configured for SEND MUST send the Neighbor Solicitations both to
      the same keys securely-solicited-node multicast address with protection, and security association
      to send Router Advertisements for up the solicited-node multicast address without protection.

   The following considerations apply to number hosts:

   o  Hosts configured for SEND MUST use SEND for all of prefixes x 2^64
   hosts on an interface.

   The change is mandatory their
      addresses, including link local addresses.

   o  Hosts configured for SEND MUST validate all nodes that support Router Advertisements
      with the AH_RSA_Sig
   transform.  Security associations protocol described in Section 8.  Note that use this includes
      discarding advertisements received without a valid IPsec AH
      header, thus making insecure prefixes invisible to them.

   o  Hosts configured for SEND MUST secure and validate all Neighbor
      Advertisements with the SPI value specified protocol described in Section 7.1.1 8.  Note
      that this includes discarding advertisements received without a
      valid IPsec AH header.

   The following considerations apply to routers:

   o  Routers MUST send two sets of Router Advertisements.  The
      advertisements containing the secure prefixes MUST be identified solely by secured with
      the SPI and protocol
   numbers, not by described in Section 9.  The advertisements
      containing the destination IP address.

7.2.2 ICMP Type Specific Selectors

   In order to allow finer granularity of protection insecure prefixes MUST be sent without AH header.

   o  Routers MUST assign different addresses for various ICMPv6
   messages, it is necessary to extend the security policy database their secure and
      insecure communications, including their link-local addresses.
      Secure Router and Neighbor Advertisements MUST use a source
      address that satisfies the security association selectors with properties outlined in Section
      9.  Unless this address is link-local, it MUST belong to one of
      the capability advertised secure prefixes.  Similarly, source addresses for
      insecure advertisements MUST belong to distinguish
   between different messages.

   All nodes that support one of the AH_RSA_Sig transform advertised
      insecure prefixes, unless the address is link-local.

   o  Routers MUST be capable of
   using ICMP and ICMPv6 Type field as refrain from sending Redirects to a selector.

8. Securing Neighbor Discovery SEND-secured node
      with SEND

   This section describes how to use IPsec and the mechanisms from
   Section 5, Section 6, Section 7 in order Destination Address field set to provide security an address for
   Neighbor Discovery.

8.1 Using IPsec to Secure Neighbor Advertisement Messages

   All Neighbor Solicitation messages SHOULD be sent without protection.

   All Neighbor Advertisement messages an
      insecure node.  Similarly, routers MUST be protected refrain from sending
      Redirects to a insecure node with IPsec,
   using the AH_RSA_Sig transform.  The protection can be based on CGA
   addresses, Destination Address field
      set to an address for a SEND-secured node certificates

   The above rules require secure nodes to ignore all insecure Neighbor
   and trusted roots, or both as specified
   in the security association.

   All Router Discovery messages, and all insecure nodes MUST have to ignore all
   SEND-secured messages.  This implies that the necessary key pairs, and as applicable,
   certificates secure and CGA parameters associated with their relationship insecure
   nodes will not be able to
   trusted root discover each other, or to an address.

   Hosts even realize that use stateless address autoconfiguration MUST generate new
   CGA addresses as specified
   the other prefixes are on-link.  Thus, these hosts will request the
   router to route packets destined to a host in Section 5 for each new
   autoconfiguration run.

   It is outside the scope of this specification other group.  The
   rules regarding Redirect messages above have been provided to describe trusted
   roots ensure
   that the router performs its routing task and address autoconfiguration (stateful or stateless) with
   dynamically changing addresses works.  It is also outside does not instruct the scope
   hosts to communicate directly.

   One effect of this specification to describe how stateful address
   autoconfiguration works is that secure hosts can not communicate with the CGA method.

   Hosts MAY use Authorization Delegation
   insecure hosts using link-local addresses, and vice versa.

   The security policy or security association database entries are
   needed for insecure nodes as far as Neighbor Discovery to learn is concerned.
   SEND-secured nodes have the
   certificate chain of their default router or peer host.

8.2 Security Policy and SA Database usual entries required by SEND.

10.2 Configuration

   This section gives a description for presents the security policy and security
   associations database entries, under which association
   data base configuration required for the outbound co-existence of SEND and inbound
   Neighbor Advertisement messages can be protected.
   non-SEND hosts.  The following table summarizes the inbound security policy data base
   along with the inbound security associations:
   configuration on a SEND node:

   Policy entries:

    *------------------------------------------------------------------*

    +------------------------------------------------------------------+
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    *------------------------------------------------------------------*
    +------------------------------------------------------------------+
    |    ICMPv6: NS    |       *      |         *       own        |     pass  SA = NS_In |
    *------------------------------------------------------------------*
    +------------------------------------------------------------------+
    |    ICMPv6: NA    |       * NS    |       own  unspecified |  SA = NA_In solicited-node MC|     pass    |
    *------------------------------------------------------------------*
    +------------------------------------------------------------------+
    |    ICMPv6: NA NS    |       *      |   all-nodes  sec.sol-node MC |  SA = NA_In NS_In |
    *------------------------------------------------------------------*

   Security associations:
    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto    ICMPv6: NA    |    Transform       *      |
    +------------------------------------------------------------------+       own        |  SA = NA_In |   Inbound   | TBD (fixed) |   AH  |    AH_RSA_Sig   |
    |
    +------------------------------------------------------------------+
    |    ICMPv6: NA    |       *      |   all-nodes MC   |   CGA  SA = yes/no  |
    |            |             |             | NA_In | root = ... (opt)|
    +------------------------------------------------------------------+

   The following table summarizes outbound security policy database:

   Policy entries:

    *------------------------------------------------------------------*
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    *------------------------------------------------------------------*
    |    ICMPv6: NS    |       * RS    |       *      |     pass    |
    *------------------------------------------------------------------*
    |    ICMPv6: NA    |       own        |         *        |  SA = NA_Out RS_In |
    *------------------------------------------------------------------*

   Security associations:
    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto    ICMPv6: RS    |    Transform       *      |
    +------------------------------------------------------------------+  all-routers MC  |    NA_Out  SA = RS_In |  Outbound
    +------------------------------------------------------------------+
    | TBD (fixed)    ICMPv6: RA    |   AH       *      |    AH_RSA_Sig       own        |  SA = RA_In |
    +------------------------------------------------------------------+
    |    ICMPv6: RA    |       *      |   all-nodes MC   | key pair  SA = ...  | RA_In |
    +------------------------------------------------------------------+
    | ICMPv6: REDIRECT |       *      |       own        | CGA  SA = yes/no    | RE_In |
    +------------------------------------------------------------------+

   Security associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | CGA params = ...| Proto |    Transform    |
    +------------------------------------------------------------------+
    |    NS_In   |   Inbound   | root = ... (opt)|
    +------------------------------------------------------------------+

9. Securing Router Discovery with SEND

   This section describes how to use IPsec and the mechanisms from
   Section 5, Section 6, Section 7 in order to provide security for
   Router Discovery.

9.1 Using IPsec to Secure Router Advertisement Messages

   All Router Solicitation messages SHOULD be sent without protection.

   All Router Advertisement messages MUST be protected with IPsec, using
   the AH_RSA_Sig transform.  The protection can be based on CGA
   addresses, node certificates and trusted roots, or both as specified
   in the security association.

   All routers MUST have the necessary key pairs, and as applicable,
   certificates and CGA parameters associated with their relationship to
   trusted root or to an address.  All hosts MUST have the certificate
   of a trusted root.

   Hosts SHOULD use Authorization Delegation Discovery to learn the
   certificate chain of their default router or peer host.

9.2 Using IPsec to Secure Redirect Messages

   All Redirect messages MUST be protected with IPsec, using the
   AH_RSA_Sig transform.  The protection can To be based on CGA addresses,
   node certificates and trusted roots, or both as specified in the
   security association.

   If only CGA-based security associations are used, hosts MUST follow
   the rules defined below when receiving Redirect messages:

   1.  The Redirect message MUST       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    NA_In   |   Inbound   | To be protected as discussed above.

   2.  The receiver MUST verify that the Redirect message comes from an
       IP address to which the host may have earlier sent the packet
       that the Redirect message now partially returns.  That is, the
       source address of the Redirect message must       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RS_In   |   Inbound   | To be the default router
       for traffic sent to the destination of the returned packet.  If
       this is not the case, the message MUST       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RA_In   |   Inbound   | To be silently discarded.

       This step prevents a bogus router from sending a Redirect message
       when the host is not using the bogus router as a default router.

9.3 Security Policy and SA Database Configuration

   This section gives a description for the security policy and security
   associations database entries, under which the outbound and inbound
   Router Advertisement and Redirect messages can       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RE_In   |   Inbound   | To be protected.       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       |CGA flag = yes/no|
    |            |             | by IANA     |       | root = ... (opt)|
    +------------------------------------------------------------------+

   The following second table summarizes the inbound security policy data base
   along with the inbound security associations: outbound configuration:

   Policy entries:

    *------------------------------------------------------------------*

    +------------------------------------------------------------------+
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    *------------------------------------------------------------------*
    +------------------------------------------------------------------+
    |    ICMPv6: RS NS    |       *  unspecified | solicited-node MC|     pass    |
    +------------------------------------------------------------------+
    |    ICMPv6: NS    |      own     |         *        |     pass SA = NS_Out |
    *------------------------------------------------------------------*
    +------------------------------------------------------------------+
    |    ICMPv6: RA NA    |      own     |         *        | SA = NA_Out |
    +------------------------------------------------------------------+
    |    ICMPv6: RS    |      own     |         *        | SA = RA_In RS_Out |
    *------------------------------------------------------------------*
    +------------------------------------------------------------------+
    |    ICMPv6: RA    |       *      own     |   all-nodes MC         *        | SA = RA_In RA_Out |
    *------------------------------------------------------------------*
    +------------------------------------------------------------------+
    | ICMPv6: REDIRECT |       *      |      own     |         *        | SA = RE_In RE_Out |
    *------------------------------------------------------------------*
    +------------------------------------------------------------------+

   Security associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto |    Transform    |
    +------------------------------------------------------------------+
    |    RA_In    NS_Out  |   Inbound  Outbound   | TBD (fixed) To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       | key pair = ...  |
    |            |             | by IANA     |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RE_In    NA_Out  |   Inbound  Outbound   | TBD (fixed) To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       | key pair = ...  |
    |            |             | by IANA     |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+

   The following table summarizes outbound security policy database.
   The Router Advertisement and Redirect entries are only present in
   routers.

   Policy entries:

    *------------------------------------------------------------------*
    |    Proto: Type    RS_Out  |    Source  Outbound   |    Destination To be       |  Treatment   AH  |
    *------------------------------------------------------------------*    AH_RSA_Sig   |    ICMPv6: RS
    |       *            |         *             |     pass assigned    |
    *------------------------------------------------------------------*       |    ICMPv6: RA key pair = ...  |      own
    |         *            | SA = RA_Out             |
    *------------------------------------------------------------------* by IANA     | ICMPv6: REDIRECT       |      own CGA = yes/no    |         *
    | SA = RE_Out            |
    *------------------------------------------------------------------*

   Security associations:

    +------------------------------------------------------------------+             |    Name             |  Direction       |     SPI CGA params = ...|
    |            |             | Proto             |    Transform       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RA_Out  |  Outbound   | TBD (fixed) To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       | key pair = ...  |
    |            |             | by IANA     |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RE_Out  |  Outbound   | TBD (fixed) To be       |   AH  |    AH_RSA_Sig   |
    |            |             | assigned    |       | key pair = ...  |
    |            |             | by IANA     |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+

10. Operational

11. Performance Considerations

   During

   The computations related to AH_RSA_Sig transform are substantially
   more expensive than those with traditional symmetric transforms.
   While computational power is increasing, it appears still impractical
   to use asymmetric transforms for a significant number of packets.

   In the transition application for which AH_RSA_Sig has been designed, however,
   hosts typically have the need to secure links or perform only a few operations as
   they enter a policy consideration,
   network operators may want to run link, and a particular link few operations as they find a new on-link
   peer with which to communicate.

   Routers are required to perform a mixture larger number of
   secure and insecure nodes.  In such a case, operations,
   particularly when the link frequency of router advertisements is required high due
   to
   operate as two separate logical links, and packets between a secure
   and insecure node always go through mobility requirements.  Still, the router.

   Routers configured for SEND advertise two sets number of globally routable
   prefixes: one set for SEND nodes and one set for nodes that implement
   insecure Neighbor Discovery.  The insecure nodes will ignore operations on a
   router is on the
   advertisements sent using SEND, order of a few dozen operations 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 original Neighbor Discovery
   specifications require silently discarding packets if they contain an
   AH header that they rate at which
   responses to solicitations can not verify.

   The following considerations apply be sent.

   Signatures related to hosts:

   o  Hosts configured for SEND MUST the use SEND for all of their
      addresses, including link local addresses.

   o  Hosts configured the AH_RSA_Sig transform MAY be
   precomputed for SEND MUST validate all Multicast Neighbor and Router Advertisements
      with Advertisements.
   Typically, solicited advertisements are sent to the unicast address
   from which the solicitation was sent.  Given that the protocol described IPv6 header is
   covered by the AH integrity protection, it is typically not possible
   to precompute solicited advertisements.

12. Implementation Considerations

   In addition to the IPsec extensions discussed in Section 8.  Note that this includes
      discarding advertisements received without a valid specification,
   it becomes necessary for the IPsec AH header implementation and CGA address, thus making insecure prefixes invisible the Neighbor
   Discovery implementation to them.

   o  Hosts configured for SEND MUST secure exchange some information.  Because IPsec
   security associations are typically set up either manually or using
   IKE, keys are shared and validate all Neighbor
      Advertisements traditional IPsec does not have to deal with
   certificates.  SEND uses public key cryptography, however, and
   therefore the protocol described keys included in Section 8.  Note
      that this includes discarding advertisements received without a
      valid IPsec the AH header and CGA address.

   The following considerations apply to routers:

   o  Routers MUST send two sets must be certified,
   except in the case where simple proof of Router Advertisements.  The
      advertisements containing IP address ownership using
   CGAs is being determined.  This requires an API between the secure prefixes MUST
   AH_RSA_Sig transform processing code and the host's certificate
   store, so that the received keys can be secured with checked.  Furthermore, if the protocol described
   necessary certificate chain is not in Section 9.  The advertisements
      containing the insecure prefixes MUST certificate store, a
   Delegation Chain Solicitation message must be sent without security.

   o  Routers MUST assign different addresses triggered to fetch the
   chain.  This may require an additional API, although, depending on
   how the certificate store is implemented, the API may or may not
   involve the code for their secure and
      insecure communications, including their link-local addresses.
      Secure Router and Neighbor Advertisements MUST use a source
      address that satisfies the security properties outlined in Section
      9.  Unless this address is link-local, it MUST belong to one of AH_RSA_Sig transform.

   Both the extensions and the advertised secure prefixes.  Similarly, source addresses API are required for
      insecure advertisements MUST belong to one all types of IPsec
   implementations, including Bump-in-the-Stack (BITS) implementations.

13. Security Considerations

13.1 Threats to the advertised Local Link Not Covered by SEND

   SEND does not compensate for an insecure prefixes, unless link layer.  In particular,
   there is no cryptographic binding in SEND between the link layer
   frame address is link-local.

   o  Routers MUST refrain from sending Redirects to a SEND-secured node
      with and the Destination Address field set to IPv6 address.  On an insecure link layer that
   allows nodes to spoof the link layer address for of other nodes, an
      insecure node.  Similarly, routers MUST refrain from
   attacker could disrupt IP service by sending
      Redirects to out a insecure node with Neighbor
   Advertisement having the Destination Address field
      set to an source address for on the link layer frame of a SEND-secured node
   victim, a valid CGA with valid AH signature corresponding to itself,
   and a Target Link-layer Address extension corresponding to the
   victim.  The above rules require secure nodes attacker could then proceed to ignore all insecure cause a traffic stream to
   bombard the victim in a DoS attack.  To protect against such attacks,
   link layer security MUST be used.  An example of such for 802 type
   networks is port-based access control [34].

   Prior to participating in Neighbor
   and Router Discovery messages, and all insecure Duplicate Address
   Detection, nodes must subscribe to ignore all
   SEND-secured messages.  This implies that the secure All Nodes Multicast Group and insecure
   Solicited Node Multicast Group for the address that they are claiming
   RFC 2461 [6].  Subscribing to a multicast group requires that the
   nodes will not use MLD [22].  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 discover each other, or even realize that detect such an attack because the other prefixes router sends a
   Multicast-Address-Specific Query to determine whether any listeners
   are on-link.  Thus, these hosts still on the address, at which point the victim can respond to
   avoid being dropped from the group.  This technique will request work if the
   router on the link has not been compromised.  Other attacks using MLD
   are possible, but they primarily lead to route packets destined extraneous (but not
   overwhelming) traffic.

13.2 How SEND Counters Threats to Neighbor Discovery

   The SEND protocol is designed to counter the a host threats to IPv6 Neighbor
   Discovery outlined in the other group. [28].  The rules regarding Redirect messages above have been provided to
   ensure that following subsections contain a
   regression of the router performs its routing task and does not
   instruct SEND protocol against the hosts threats, to communicate directly.

   One effect illustrate
   what aspects of this the protocol counter each threat.

13.2.1 Neighbor Solicitation/Advertisement Spoofing

   This threat is that secure hosts can not communicate with
   insecure hosts using link-local addresses, and vice versa. defined in Section 4.1.1 of [28].  The security policy threat is that
   a spoofed Neighbor Solicitation or security association database entries Neighbor Advertisement causes a
   false entry in a node's Neighbor Cache.  There are
   needed for insecure nodes as far two cases:

   1.  Entries made as a side effect of a Neighbor Discovery is concerned.
   SEND-secured nodes have the usual entries required by SEND.

11. Performance Considerations

   The computations related to AH_RSA_Sig transform Solicitation or
       Router Solicitation.  There are substantially
   more expensive than those two cases:

       1.  A router receiving a Router Solicitation with traditional symmetric transforms.
   While computational power is increasing, it appears still impractical
   to use asymmetric transforms 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) that receives
           a significant amount packets.

   In the application Neighbor Solicitation for which AH_RSA_Sig has been designed, however,
   hosts typically have the need to perform only a few operations same address regards the
           situation as
   they enter a link, collision and ceases to solicit for the
           address.

   2.  Entries made as a few operations result of a Neighbor Advertisement sent as they find a new on-link
   peer to communicate with.

   Routers are required
       response to perform a larger amount of operations,
   particularly when the frequency Neighbor Solicitation for purposes of router advertisements is high due
   to mobility requirements.  Still, on-link
       address resolution.

13.2.1.1 Solicitations with Effect

   SEND counters the number threat of operations on a
   router is solicitations with effect in the order of
   following ways:

   1.  As discussed in Section 5, SEND nodes preferably send Router
       Solicitations with a few dozen operations per second, some of firm IPv6 address and AH header, which the
       router can be precomputed as discussed below.  A large number of verify, so the Neighbor Cache binding is correct.  If
       a SEND node must send a Router Solicitation with the unspecified
       address, the router solicitations may cause higher demand for performing
   asymmetric operations, although will not update its Neighbor Cache, as per
       RFC 2461 limits 2461.

   2.  When SEND nodes are performing DAD, they use the rate at which
   responses to solicitations can be sent.

   Signatures related to tentative
       address as the use of source address on the AH_RSA_Sig transform MAY be
   precomputed for Multicast Neighbor Solicitation
       packet, and Router Advertisements.
   Typically, solicited advertisements are sent include an IPv6 AH header.  This allows the receiving
       SEND node to verify the unicast solicitation.

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

13.2.1.2 Address Resolution

   SEND counters attacks on address
   from which resolution by requiring that the
   responding node include an AH header with a signature on the solicitation was sent.  Given packet,
   and that the IPv6 header is
   covered by the AH integrity protection, it is typically not possible
   to precompute solicited advertisements.

12. Security Considerations

12.1 Achieved Security Properties

   The node's interface identifier either be a CGA method assures or that the received messages are coming from the
   owner of the address.  However, this method does not eliminate all
   security vulnerabilities related to the ND functions.  CGA prevents
   spoofed answers to DAD queries.  An attacker may still
   node be able to
   prevent valid responses or requests from reaching the intended
   recipient.  As produce a result both participants are forced to believe certificate authorizing that
   no address collision exists, when there in fact is.

   Within Address Resolution and NUD functions CGA can be used to
   prevent spoofed responses.  However, it is still possible node to prevent use
   the Address Resolution interface identifier.

   The Neighbor Solicitation and NUD from completing for Advertisement pairs implement a given address.
   For the NUD,
   challenge-response protocol, as explained in Section 8 and discussed
   in Section 13.2.5 below.

13.2.2 Neighbor Unreachability Detection Failure

   This attack is described in Section 4.1.2 of [28].  SEND counters
   this means that attack by requiring a node is claimed responding to be unreachable,
   when it really is not.

   Hosts can use CGA Neighbor Solicitations
   sent as NUD probes to show that the Redirect messages come from their
   current router.  Still, we cannot say anything about include an AH header and proof of authorization
   to use the other router
   mentioned interface identifier in the Redirect message.  When trusted roots address being probed.  If
   these prerequisites are used to
   certify routers, this is, however, not an issue.

   Within the Router Discovery functionality met, the CGA method ensures that
   we are communicating with node performing NUD discards the same router all
   responses.

13.2.3 Duplicate Address Detection DoS Attack

   This attack is described in Section 4.1.3 of [28].  SEND counters
   this attack by requiring the time, Neighbor Advertisements sent as
   responses to DAD to include an AH header and prevents
   spoofing proof of authorization
   to use the link-layer address of interface identifier in the router.  But it does address being tested.  If
   these prerequisites are not
   help to verify that met, the router is connected to node performing DAD discards the Internet or that
   it is authorized to advertise
   responses.

   When a specific route prefix.  A proper
   verification of these properties will not be possible without
   involving SEND node is used on a trusted root.

   Protection of Router (or Neighbor) Discovery with trusted roots
   ensures link that the given router (or neighbor) belongs also connects to non-SEND
   nodes, the set of
   trusted entities.  It does not provide assurance that the given
   router is not spoofing another legitimate router (but see Section
   14).

12.2 Attacks against SEND Itself

   The CGA node defends its addresses have a 60-bit hash.  This length is in within the
   range of by sending unprotected
   Neighbor Solicitations with an feasible attack unspecified address, as explained in
   Section 10.   However, the future.  The following mechanisms
   have been built in this draft to counteract such attacks:

      The inclusion of SEND node ignores any unprotected Neighbor
   Solicitations or Advertisements that may be send by the routing prefix prevents precomputation
      attacks.

      The Sec parameter helps non-SEND
   nodes.   This protects the SEND algorithm node from DAD DoS attacks by non-SEND
   nodes or attackers simulating to scale as Moore's law
      increases processing power.  Additional amount non-SEND nodes, at the cost of computational
      effort is involved in for both attackers a
   potential address collision between a SEND node and non-SEND node.
   The probability and owners effects of such an address;
      verifiers of a message still need to spend the same amount of
      effort.

   Some Denial-of-Service address collision are
   discussed in [27].

13.2.4 Router Solicitation and Advertisement Attacks

   These attacks against ND are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
   and SEND itself remain.
   For instance, an attacker may try to produce a very high number 4.2.7 of
   packets that a victim host or router has to verify using asymmetric
   methods.  While safeguards are required [28].  SEND counters these attacks by requiring Router
   Advertisements to prevent contain an excessive use
   of resources, this can still render AH header, and that the SEND in-operational.

   Security associations based on signature in the use of asymmetric cryptography can
   header be vulnerable to Denial-of-Service attacks, particularly when calculated using the
   attacker public key of a host that can guess prove
   its authorization to route the SPIs and destination addresses used subnet prefixes contained in any
   Prefix Information Options.  The router proves it authorization by
   showing an attribute certificate containing the
   security associations.  In SEND this is easy, as both specific prefix or
   the SPIs and indication that the addresses (such as all nodes multicast address) are standardized.
   Due router is allowed to the use route any prefix.  A
   Router Advertisement without these protections is dropped as part of multicast, one packet sent by
   the attacker will be
   processed by multiple receivers.

   When CGA protection is used, IPsec processing.

   SEND deals with these does not protect against brute force attacks using the
   verification process described Section 7.1.6.  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 trusted roots and certificates are used in SEND, on the defenses
   are not quite router, such
   as effective.  Implementations SHOULD track how much
   resources are being devoted to the processing DoS attacks, or compromise of packets received
   with the AH_RSA_Sig transform, router, as described in Sections
   4.4.2 and start selectively dropping packets
   if too much resources are spent.  Implementations MAY also start
   first dropping packets that which 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
   request a large number 4.4.3 of [28].

13.2.5 Replay Attacks
   This attack is described in Section 4.3.1 of delegation chains to be discovered for
   different roots.  Routers SHOULD defend [28].  SEND protects
   against such attacks by
   caching discovered information (including negative responses) in Router Solicitation/Router Advertisement and
   Neighbor Solicitation/Neighbor Advertisement transactions by
   limiting
   including a Nonce option in the number of different discovery processes they engage in.

   Attackers may also target hosts solicitation 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, and Redirects by sending including a large number
   timestamp into the AH header.  A window of
   unnecessary certificate chains, forcing hosts to spend useless memory
   and verification resources vulnerability for them.  Hosts defend replay
   attacks exists until the timestamp expires.

   When timestamps are used, SEND nodes are protected against such replay
   attacks as long as they cache the state created by limiting the amount of resources devoted to message
   containing the
   certificate chains and their verification.  Hosts SHOULD also
   prioritize advertisements sent as a response timestamp.  The cached state allows the node to their requests over
   multicast advertisements.

13. IANA Considerations

   This document defines two new ICMP message types, used in
   Authorization Delegation Discovery.  These messages must be assigned
   ICMPv6 type numbers from
   protect itself against replayed messages.  However, once the informational node
   flushes the state for whatever reason, an attacker can re-create the
   state by replaying an old message range:

   o  The Delegation Chain Solicitation message, described while the timestamp is still valid.
   Since most SEND nodes are likely to use fairly coarse grained
   timestamps, as explained in Section
      6.1.

   o  The Delegation Chain Advertisement message, 7.1.4, this may affect some
   nodes.

13.2.6 Neighbor Discovery DoS Attack

   This attack is described in Section
      6.2.

   This document defines two new 4.3.2 of [28].  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 Discovery [6] options, which
   must Solicitations for addresses that do not exist.
   SEND does not address this threat because it can be assigned Option Type values within addressed by
   techniques such as rate limiting Neighbor Solicitations, restricting
   the option numbering space amount of state reserved for unresolved solicitations, and clever
   cache management.  These are all techniques involved in implementing
   Neighbor Discovery messages:

   o on the router.

13.3 Attacks against SEND Itself

   The Trusted Root option, described in Section 6.3.

   o CGAs have a 59-bit hash value.  The Certificate option, described security of the CGA mechanism
   has been discussed in Section 6.4.

   This document defines [27].

   Some Denial-of-Service attacks against ND and SEND itself remain.
   For instance, an attacker may try to produce a new reserved SPI 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.

   Security associations based on the use of asymmetric cryptography can
   be vulnerable to Denial-of-Service attacks, particularly when the
   attacker can guess the SPIs and destination addresses used in the Reserved SPI
   range 1-255 [3].

   This document defines a new IPSEC AH Transform Identifier for
   security associations.  In SEND this is easy, as both the
   IPsec DOI [4].  This identifier represents SPIs and
   the AH_RSA_Sig transform
   from Section 7.1.

   This document defines a new name space for addresses (such as all nodes multicast address) are standardized.
   Due to the use of multicast, one packet sent by the attacker will be
   processed by multiple receivers.

   When CGA protection is used, SEND deals with these attacks using the Name Type field
   verification process described in Section 7.1.6.  In this process a
   simple hash verification of the
   Trusted Root option.  Future values CGA property of this field can be allocated
   using standards action [5].

   Another new name space the address is allocated for
   performed first before performing the Cert Type field more expensive signature
   verification.

   When trusted roots and certificates are used for address validation
   in SEND, the
   Certificate option.  Future values defenses are not quite as effective.  Implementations
   SHOULD track the resources devoted to the processing of this field can be allocated
   using standards action [5].

14. Conclusions packets
   received with the AH_RSA_Sig transform, and Remaining Work

   This draft documents ongoing work.  The following areas start selectively
   dropping packets if too many resources are still
   being studied:

   o  Protection of solicitations.  There spent.  Implementations
   MAY also drop first packets that are no provisions yet 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
   request a large number of delegation chains to be discovered for
   different roots.  Routers SHOULD defend against such attacks by
   caching discovered information (including negative responses) and by
   limiting the
      protection number of Address Resolution which takes place as different discovery processes they engage in.

   Attackers may also target hosts by sending a
      side-effect large number of Neighbor Solicitations.  Similarly,
   unnecessary certificate chains, forcing hosts to spend useless memory
   and verification resources for them.  Hosts defend against such
   attacks by limiting the effects amount of
      Duplicate Address Detection probes on other nodes currently doing
      DAD have not been covered, as they too are carried by
      solicitations.

   o  CGA detailed format resources devoted to the
   certificate chains and calculation formulas: The CGA formulas their verification.  Hosts SHOULD also
   prioritize advertisements sent as a response to their requests above
   multicast advertisements.

14. IANA Considerations

   This document defines two new ICMP message types, used in this document are
   Authorization Delegation Discovery.  These messages must be assigned
   ICMPv6 type numbers from an early approach to the control of
      the security level informational message range:

   o  The Delegation Chain Solicitation message, described in an environment with a constrained number of
      output bits.  An advanced version of this approach will be
      published soon and appears interesting [21]. Section
      6.1.

   o  Transition issues: Security policy and security association
      database entry examples are needed before the correctness of the
      approach outlined  The Delegation Chain Advertisement message, described in Section 10 can
      6.2.

   This document defines two new Neighbor Discovery [6] options, which
   must be estimated.  Also, assigned Option Type values within the
      ability of hosts to simultaneously use SEND and insecure ND
      without a router.  The ability of a non-SEND router to participate
      on a link with SEND-capable hosts and other routers. option numbering space
   for Neighbor Discovery messages:

   o  The security considerations, achieved security properties, and the
      treatment of Denial-of-Service attacks on the SEND mechanisms
      themselves need further work. Trusted Root option, described in Section 6.3.

   o  The formats used to carry trusted root references, certificates,
      and public keys may change. Certificate option, described in Section 6.4.

   o  It is unclear at this time how, and if, router and neighbor
      protection based on trusted roots relates to addresses and
      prefixes.  Is  The Nonce option, described in Section 5.3.

   This document defines a router only certified to use new reserved SPI number in the Reserved SPI
   range 1-255 [3].

   This document defines a particular IP
      address, or to provide new IPSEC AH Transform Identifier for the
   IPsec DOI [4].  This identifier represents the AH_RSA_Sig transform
   from Section 7.1.

   This document defines a particular prefix to new name space for the link?

   o  It is unclear whether MLD [16] protection Name Type field in the
   Trusted Root option.  Future values of this field can be allocated
   using standards action [5].

   Another new name space is needed or not. 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]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

   [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]  Farrell, S. and R. Housley, "An Internet Attribute Certificate
         Profile for Authorization", RFC 3281, April 2002.

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

   [14]  Lynn, C., "X.509 Extensions for IP Addresses and AS
         Identifiers", Internet-Draft (expired)
         draft-ietf-pkix-x509-ipaddr-as-extn-00, February 2002.

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

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

   [11]

   [17]  RSA Laboratories, "RSA Encryption Standard, Version 1.5", PKCS
         1, November 1993.

   [12]

   [18]  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

   [13]

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

   [14]

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

   [15]

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

   [16]

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

   [17]

   [23]  Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
         draft-arkko-icmpv6-ike-effects-01 (work in progress), June
         2002.

   [18]

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

   [19]

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

   [20]

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

   [27]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-ietf-send-cga-00.txt (work in progress), May 2003.

   [28]  Nikander, P., "IPv6 Neighbor Discovery trust models and
         threats", draft-ietf-send-psreq-00 (work in progress), October
         2002.

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

   [21]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-aura-cga-00.txt (work in progress), February 2003.

   [22]

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

   [23]

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

   [24]

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

   [25]

   [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
   Sun Microsystems
   1 Network Drive UBUR02-212
   Burlington  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

   Steven Bellovin was the first to suggest the use of IPsec in this
   manner for the protection of Neighbor Discovery.  Pekka Nikander  Ran Atkinson and
   Brian Weis have in the past experimented with public-key based
   variants of AH for other purposes.  Vesa-Matti Mantyla were co-authors was a
   co-author of an unpublished draft from which many of the details of
   this document have been inherited.  The theoretical foundations of
   protecting Neighbor Discovery were laid out in a paper [24] [32] where
   Tuomas Aura, Vesa-Matti Mantyla, Pekka Nikander, and Mike Roe were
   co-authors.

Appendix B. Acknowledgements

   The authors would like to thank Erik Nordmark and Nordmark, Gabriel Montenegro Montenegro,
   Tuomas Aura, Pekka Savola, and Alper Yegin for interesting
   discussions in this problem space.

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

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.

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.