base.txt   issue58.txt 
  Skipping to change at page 2, line 45:
6.2.2 Delegation Chain Advertisement Message Format 30 6.2.2 Delegation Chain Advertisement Message Format 30
6.2.3 Trust Anchor Option . . . . . . . . . . . . . 32 6.2.3 Trust Anchor Option . . . . . . . . . . . . . 32
6.2.4 Certificate Option . . . . . . . . . . . . . . 34 6.2.4 Certificate Option . . . . . . . . . . . . . . 34
6.2.5 Processing Rules for Routers . . . . . . . . . 34 6.2.5 Processing Rules for Routers . . . . . . . . . 34
6.2.6 Processing Rules for Hosts . . . . . . . . . . 35 6.2.6 Processing Rules for Hosts . . . . . . . . . . 35
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .38 7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .38
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38
7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39 7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 40 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . 42 9. Security Considerations . . . . . . . . . . . . . . . . . . 43
9.1 Threats to the Local Link Not Covered by SEND . . . .42 9.1 Threats to the Local Link Not Covered by SEND . . . .43
9.2 How SEND Counters Threats to NDP . . . . . . . . . . .42 9.2 How SEND Counters Threats to NDP . . . . . . . . . . .43
9.2.1 Neighbor Solicitation/Advertisement Spoofing . 43 9.2.1 Neighbor Solicitation/Advertisement Spoofing . 44
9.2.2 Neighbor Unreachability Detection Failure . . 43 9.2.2 Neighbor Unreachability Detection Failure . . 44
9.2.3 Duplicate Address Detection DoS Attack . . . . 43 9.2.3 Duplicate Address Detection DoS Attack . . . . 44
9.2.4 Router Solicitation and Advertisement Attacks 44 9.2.4 Router Solicitation and Advertisement Attacks 45
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 44 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 45
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 45 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 46
9.3 Attacks against SEND Itself . . . . . . . . . . . . .45 9.3 Attacks against SEND Itself . . . . . . . . . . . . .46
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 47 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 48
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 48 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49
Normative References . . . . . . . . . . . . . . . . . . . . 49 Normative References . . . . . . . . . . . . . . . . . . . . 50
Informative References . . . . . . . . . . . . . . . . . . . 51 Informative References . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 55
C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 55 C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . 57
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 38, line 38:
the router's certificate. Redirect messages failing this check MUST the router's certificate. Redirect messages failing this check MUST
be silently discarded. be silently discarded.
Note that RFC 2461 rules prevent a bogus router from sending a Note that RFC 2461 rules prevent a bogus router from sending a
Redirect message when the host is not using the bogus router as a Redirect message when the host is not using the bogus router as a
default router. default router.
7.3 Advertised Prefixes 7.3 Advertised Prefixes
The router's certificate defines the address range(s) that it is The router's certificate defines the address range(s) that it is
allowed to advertise. Upon processing a Prefix Information option allowed to advertise securely. A router MAY, however, advertise a
within a Router Advertisement, nodes SHOULD verify that the prefix combination of certified and uncertified prefixes. Uncertified
specified in this option falls within the range defined by the prefixes are treated as insecure, i.e., processed in the same way as
certificate, if the certificate contains a prefix extension. Options insecure router advertisements sent by non-SEND routers. The
failing this check MUST be silently discarded. processing of insecure 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 information.
Nodes SHOULD use one of the certified prefixes for stateless Certified prefixes fall into the following two categories:
autoconfiguration. If none of the advertised prefixes match, then
either there is a configuration problem or the advertising router is
an attacker, and the host MUST use a different advertising router as
its default router (if available). If the node is performing
stateful autoconfiguration, it SHOULD check the address provided by
the DHCP server against the certified prefixes and MUST NOT use the
address if the prefix is not certified.
In any case, the user should inform the network operator upon Constrained
receiving an address or prefix outside the certified range, since
this is either a misconfiguration or an attack.
If the network operator wants to constrain which routers are allowed If the network operator wants to constrain which routers are
to route particular prefixes, routers SHOULD be configured with allowed to route particular prefixes, routers SHOULD be configured
certificates having prefixes listed in the prefix extension. Routers with certificates having prefixes listed in the prefix extension.
so configured MUST advertise the prefixes which they are certified to
route, or a subset thereof. Routers so configured SHOULD advertise the prefixes which they are
certified to route, or a subset thereof.
Unconstrained
Network operators that do not want to constrain routers this way Network operators that do not want to constrain routers this way
SHOULD configure routers with certificates containing either the null SHOULD configure routers with certificates containing either the
prefix or no prefix extension at all. null prefix or no prefix extension at all.
Upon processing a Prefix Information option within a Router
Advertisement, nodes SHOULD verify that the prefix specified in this
option falls within the range defined by the certificate, if the
certificate contains a prefix extension. Options failing this check
are treated as containing uncertified prefixes.
Nodes SHOULD use one of the certified prefixes for stateless
autoconfiguration. If none of the advertised prefixes match, the
host SHOULD use a different advertising router as its default router,
if available. If the node is performing stateful autoconfiguration,
it SHOULD check the address provided by the DHCP server against the
certified prefixes and SHOULD NOT use the address if the prefix is
not certified.
7.4 Limitations 7.4 Limitations
This specification does not address the protection of NDP packets for This specification does not address the protection of NDP packets for
nodes that are configured with a static address (e.g., PREFIX::1). nodes that are configured with a static address (e.g., PREFIX::1).
Future certificate chain based authorization specifications are Future certificate chain based authorization specifications are
needed for such nodes. needed for such nodes.
It is outside the scope of this specification to describe the use of It is outside the scope of this specification to describe the use of
trust anchor authorization between nodes with dynamically changing trust anchor authorization between nodes with dynamically changing
 End of changes. 

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