base.txt   issue57.txt 
  Skipping to change at page 2, line 20:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification of Requirements . . . . . . . . . . . . 4 1.1 Specification of Requirements . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7 3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11 5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11
5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11
5.1.1 Processing Rules for Senders . . . . . . . . . 12 5.1.1 Processing Rules for Senders . . . . . . . . . 12
5.1.2 Processing Rules for Receivers . . . . . . . . 13 5.1.2 Processing Rules for Receivers . . . . . . . . 13
5.1.3 Configuration . . . . . . . . . . . . . . . . 14 5.1.3 Configuration . . . . . . . . . . . . . . . . 14
5.2 Signature Option . . . . . . . . . . . . . . . . . . .14 5.2 Signature Option . . . . . . . . . . . . . . . . . . .15
5.2.1 Processing Rules for Senders . . . . . . . . . 16 5.2.1 Processing Rules for Senders . . . . . . . . . 17
5.2.2 Processing Rules for Receivers . . . . . . . . 17 5.2.2 Processing Rules for Receivers . . . . . . . . 17
5.2.3 Configuration . . . . . . . . . . . . . . . . 18 5.2.3 Configuration . . . . . . . . . . . . . . . . 18
5.2.4 Performance Considerations . . . . . . . . . . 19 5.2.4 Performance Considerations . . . . . . . . . . 19
5.3 Timestamp and Nonce options . . . . . . . . . . . . .19 5.3 Timestamp and Nonce options . . . . . . . . . . . . .20
5.3.1 Timestamp Option . . . . . . . . . . . . . . . 19 5.3.1 Timestamp Option . . . . . . . . . . . . . . . 20
5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 20 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 21
5.3.3 Processing rules for senders . . . . . . . . . 21 5.3.3 Processing rules for senders . . . . . . . . . 21
5.3.4 Processing rules for receivers . . . . . . . . 21 5.3.4 Processing rules for receivers . . . . . . . . 22
6. Authorization Delegation Discovery . . . . . . . . . . . . . 24 6. Authorization Delegation Discovery . . . . . . . . . . . . . 25
6.1 Certificate Format . . . . . . . . . . . . . . . . . .24 6.1 Certificate Format . . . . . . . . . . . . . . . . . .25
6.1.1 Router Authorization Certificate Profile . . . 24 6.1.1 Router Authorization Certificate Profile . . . 25
6.2 Certificate Transport . . . . . . . . . . . . . . . .27 6.2 Certificate Transport . . . . . . . . . . . . . . . .28
6.2.1 Delegation Chain Solicitation Message Format . 27 6.2.1 Delegation Chain Solicitation Message Format . 28
6.2.2 Delegation Chain Advertisement Message Format 29 6.2.2 Delegation Chain Advertisement Message Format 30
6.2.3 Trust Anchor Option . . . . . . . . . . . . . 31 6.2.3 Trust Anchor Option . . . . . . . . . . . . . 32
6.2.4 Certificate Option . . . . . . . . . . . . . . 33 6.2.4 Certificate Option . . . . . . . . . . . . . . 34
6.2.5 Processing Rules for Routers . . . . . . . . . 33 6.2.5 Processing Rules for Routers . . . . . . . . . 34
6.2.6 Processing Rules for Hosts . . . . . . . . . . 34 6.2.6 Processing Rules for Hosts . . . . . . . . . . 35
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 37 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .37 7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .38
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .37 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .37 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38
7.4 Limitations . . . . . . . . . . . . . . . . . . . . .38 7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 39 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . 42
9.1 Threats to the Local Link Not Covered by SEND . . . .41 9.1 Threats to the Local Link Not Covered by SEND . . . .42
9.2 How SEND Counters Threats to NDP . . . . . . . . . . .41 9.2 How SEND Counters Threats to NDP . . . . . . . . . . .42
9.2.1 Neighbor Solicitation/Advertisement Spoofing . 42 9.2.1 Neighbor Solicitation/Advertisement Spoofing . 43
9.2.2 Neighbor Unreachability Detection Failure . . 42 9.2.2 Neighbor Unreachability Detection Failure . . 43
9.2.3 Duplicate Address Detection DoS Attack . . . . 42 9.2.3 Duplicate Address Detection DoS Attack . . . . 43
9.2.4 Router Solicitation and Advertisement Attacks 43 9.2.4 Router Solicitation and Advertisement Attacks 44
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 43 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 44
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 44 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 45
9.3 Attacks against SEND Itself . . . . . . . . . . . . .44 9.3 Attacks against SEND Itself . . . . . . . . . . . . .45
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 46 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 47
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 47 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 48
Normative References . . . . . . . . . . . . . . . . . . . . 48 Normative References . . . . . . . . . . . . . . . . . . . . 49
Informative References . . . . . . . . . . . . . . . . . . . 50 Informative References . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 52
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 53 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54
C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 54 C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 55 Intellectual Property and Copyright Statements . . . . . . . 56
1. Introduction 1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7] IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]
and 2462 [8]. Nodes on the same link use NDP to discover each and 2462 [8]. Nodes on the same link use NDP to discover each
other's presence, to determine each other's link-layer addresses, to other's presence, to determine each other's link-layer addresses, to
find routers, and to maintain reachability information about the find routers, and to maintain reachability information about the
paths to active neighbors. NDP is used both by hosts and routers. paths to active neighbors. NDP is used both by hosts and routers.
Its functions include Neighbor Discovery (ND), Router Discovery (RD), Its functions include Neighbor Discovery (ND), Router Discovery (RD),
Address Autoconfiguration, Address Resolution, Neighbor Address Autoconfiguration, Address Resolution, Neighbor
  Skipping to change at page 13, line 40:
the CGA option is not used when the source address is the the CGA option is not used when the source address is the
unspecified address. unspecified address.
Router Advertisement Router Advertisement
The address MUST be the source address of the message. The address MUST be the source address of the message.
5.1.2 Processing Rules for Receivers 5.1.2 Processing Rules for Receivers
Neighbor Solicitation and Advertisement messages without the CGA Neighbor Solicitation and Advertisement messages without the CGA
option MUST be silently discarded. Router Solicitation messages option MUST be treated as insecure, i.e., processed in the same way
without the CGA option MUST be silently discarded, unless the source as NDP messages sent by a non-SEND node. The processing of insecure
address of the message is the unspecified address. messages is specified in Section 8. Note that SEND nodes that do not
attempt to interoperate with non-SEND nodes MAY simply discard the
insecure messages.
Router Solicitation messages without the CGA option MUST be also
treated as insecure, unless the source address of the message is the
unspecified address.
A message containing a CGA option MUST be checked as follows: A message containing a CGA option MUST be checked as follows:
If the interface has been configured to use CGA, the receiving If the interface has been configured to use CGA, the receiving
node MUST verify the source address of the packet using the node MUST verify the source address of the packet using the
algorithm described in Section 5 of [12]. The inputs for the algorithm described in Section 5 of [12]. The inputs for the
algorithm are the contents of the Collision Cnt, Modifier, and the algorithm are the contents of the Collision Cnt, Modifier, and the
Key Information fields, the claimed address in the packet (as Key Information fields, the claimed address in the packet (as
discussed in the previous section), and the minimum acceptable Sec discussed in the previous section), and the minimum acceptable Sec
value. If the CGA verification is successful, the recipient value. If the CGA verification is successful, the recipient
  Skipping to change at page 17, line 33:
* The contents of the message, starting from the ICMPv6 header, * The contents of the message, starting from the ICMPv6 header,
up to but excluding the Signature option. up to but excluding the Signature option.
o The message, in the form defined above, is signed using the o The message, in the form defined above, is signed using the
configured private key, and the resulting PKCS#1 signature is put configured private key, and the resulting PKCS#1 signature is put
to the Digital Signature field. to the Digital Signature field.
5.2.2 Processing Rules for Receivers 5.2.2 Processing Rules for Receivers
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages without the Signature option MUST be silently and Redirect messages without the Signature option MUST be treated as
discarded. Router Solicitation messages without the Signature option insecure, i.e., processed in the same way as NDP messages sent by a
MUST be silently discarded, unless the source address of the message non-SEND node. See Section 8.
is the unspecified address.
Router Solicitation messages without the Signature option MUST be
also treated as insecure, unless the source address of the message is
the unspecified address.
A message containing a Signature option MUST be checked as follows: A message containing a Signature option MUST be checked as follows:
o The Signature option MUST appear as the last option. o The Signature option MUST appear as the last option.
o The Key Hash field MUST indicate the use of a known public key, o The Key Hash field MUST indicate the use of a known public key,
either one learned from a preceding CGA option, or one known by either one learned from a preceding CGA option, or one known by
other means. other means.
o The Digital Signature field MUST have correct encoding, and not o The Digital Signature field MUST have correct encoding, and not
  Skipping to change at page 22, line 10:
5.3.4 Processing rules for receivers 5.3.4 Processing rules for receivers
The processing of the Nonce and Timestamp options depends on whether The processing of the Nonce and Timestamp options depends on whether
a packet is a solicited-for advertisement or not. A system may a packet is a solicited-for advertisement or not. A system may
implement the distinction in various means. Section 5.3.4.1 defines implement the distinction in various means. Section 5.3.4.1 defines
the processing rules for solicited-for advertisements. Section the processing rules for solicited-for advertisements. Section
5.3.4.2 defines the processing rules for all other messages. 5.3.4.2 defines the processing rules for all other messages.
In addition, the following rules apply in any case: In addition, the following rules apply in any case:
o Messages received without the Timestamp option MUST be silently o Messages received with the Signature option but without the
discarded. Timestamp option MUST be silently discarded.
o Solicitation messages received without the Nonce option MUST be o Solicitation messages received with the Signature option but
silently discarded. without the Nonce option MUST be silently discarded.
o Advertisements sent to a unicast destination address without a o Advertisements sent to a unicast destination address with the
Nonce option MUST be silently discarded. Signature option but without a Nonce option MUST be silently
discarded.
o An implementation may utilize some mechanism such as a timestamp o An implementation may utilize some mechanism such as a timestamp
cache to strengthen resistance to replay attacks. When there is a cache to strengthen resistance to replay attacks. When there is a
very large number of nodes on the same link, or when a cache very large number of nodes on the same link, or when a cache
filling attack is in progress, it is possible that the cache filling attack is in progress, it is possible that the cache
holding the most recent timestamp per sender becomes full. In holding the most recent timestamp per sender becomes full. In
this case the node MUST remove some entries from the cache or this case the node MUST remove some entries from the cache or
refuse some new requested entries. The specific policy as to refuse some new requested entries. The specific policy as to
which entries are preferred over the others is left as an which entries are preferred over the others is left as an
implementation decision. However, typical policies may prefer implementation decision. However, typical policies may prefer
 End of changes. 

This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/