base.txt   issue48.txt 
  Skipping to change at page 2, line 33:
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 . . . . . . . . . . . . .19
5.3.1 Timestamp Option . . . . . . . . . . . . . . . 19 5.3.1 Timestamp Option . . . . . . . . . . . . . . . 19
5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 20 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . 21
6. Authorization Delegation Discovery . . . . . . . . . . . . . 24 6. Authorization Delegation Discovery . . . . . . . . . . . . . 24
6.1 Certificate Format . . . . . . . . . . . . . . . . . .24 6.1 Certificate Format . . . . . . . . . . . . . . . . . .24
6.1.1 Router Authorization Certificate Profile . . . 24 6.1.1 Router Authorization Certificate Profile . . . 24
6.2 Certificate Transport . . . . . . . . . . . . . . . .26 6.2 Certificate Transport . . . . . . . . . . . . . . . .27
6.2.1 Delegation Chain Solicitation Message Format . 27 6.2.1 Delegation Chain Solicitation Message Format . 27
6.2.2 Delegation Chain Advertisement Message Format 29 6.2.2 Delegation Chain Advertisement Message Format 29
6.2.3 Trust Anchor Option . . . . . . . . . . . . . 31 6.2.3 Trust Anchor Option . . . . . . . . . . . . . 31
6.2.4 Certificate Option . . . . . . . . . . . . . . 32 6.2.4 Certificate Option . . . . . . . . . . . . . . 32
6.2.5 Processing Rules for Routers . . . . . . . . . 33 6.2.5 Processing Rules for Routers . . . . . . . . . 33
6.2.6 Processing Rules for Hosts . . . . . . . . . . 34 6.2.6 Processing Rules for Hosts . . . . . . . . . . 34
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .36 7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .37
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .36 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .37
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .36 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .37
7.4 Limitations . . . . . . . . . . . . . . . . . . . . .37 7.4 Limitations . . . . . . . . . . . . . . . . . . . . .38
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 38 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . 41
9.1 Threats to the Local Link Not Covered by SEND . . . .40 9.1 Threats to the Local Link Not Covered by SEND . . . .41
9.2 How SEND Counters Threats to NDP . . . . . . . . . . .40 9.2 How SEND Counters Threats to NDP . . . . . . . . . . .41
9.2.1 Neighbor Solicitation/Advertisement Spoofing . 41 9.2.1 Neighbor Solicitation/Advertisement Spoofing . 42
9.2.2 Neighbor Unreachability Detection Failure . . 41 9.2.2 Neighbor Unreachability Detection Failure . . 42
9.2.3 Duplicate Address Detection DoS Attack . . . . 41 9.2.3 Duplicate Address Detection DoS Attack . . . . 42
9.2.4 Router Solicitation and Advertisement Attacks 42 9.2.4 Router Solicitation and Advertisement Attacks 43
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 42 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 43
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 43 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 44
9.3 Attacks against SEND Itself . . . . . . . . . . . . .43 9.3 Attacks against SEND Itself . . . . . . . . . . . . .44
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 45 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 46
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 47
Normative References . . . . . . . . . . . . . . . . . . . . 47 Normative References . . . . . . . . . . . . . . . . . . . . 48
Informative References . . . . . . . . . . . . . . . . . . . 49 Informative References . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 52 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 53
C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 53 C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . 54 Intellectual Property and Copyright Statements . . . . . . . 55
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 25, line 41:
intersection. If the addressPrefix in the certificate is the null intersection. If the addressPrefix in the certificate is the null
prefix, 0/0, such an intersection SHOULD be used. (In that case the prefix, 0/0, such an intersection SHOULD be used. (In that case the
intersection is the parent prefix or range.) If the resulting intersection is the parent prefix or range.) If the resulting
intersection is empty, the client MUST NOT accept the certificate. intersection is empty, the client MUST NOT accept the certificate.
The above check SHOULD be done for all certificates in the chain. If The above check SHOULD be done for all certificates in the chain. If
any of the checks fail, the client MUST NOT accept the certificate. any of the checks fail, the client MUST NOT accept the certificate.
The client also needs to perform validation of advertised prefixes as The client also needs to perform validation of advertised prefixes as
discussed in Section 7.3. discussed in Section 7.3.
Care should be taken if the certificates used in SEND are re-used to
provide authorization in other circumstances, for example with
routing gateway protocols. It is necessary to ensure that the
authorization information is appropriate for all applications. SEND
certificates may authorize a larger set of prefixes than the router
is really authorized to advertise on a given interface. For
instance, SEND allows the use of the null prefix. This prefix might
cause verification or routing problems in other applications. It is
RECOMMENDED that SEND certificates containing the null prefix are
only used for SEND.
Since it is possible that some PKC certificates used with SEND do not Since it is possible that some PKC certificates used with SEND do not
immediately contain the X.509 IP address extension element, an immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD checks to be relaxed. However, any such configuration options SHOULD
be off by default. That is, the system SHOULD have a default be off by default. That is, the system SHOULD have a default
configuration that requires rigorous prefix and range checks. configuration that requires rigorous prefix and range checks.
The following is an example of a certificate chain. Suppose that The following is an example of a certificate chain. Suppose that
ispgroup.com is the trust anchor. The host has this certificate for ispgroup.com is the trust anchor. The host has this certificate for
it: it:
 End of changes. 

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