| base.txt | issue63b.txt | |
|---|---|---|
| Skipping to change at page 35, line 6: | ||
| When the Cert Type field is set to 1, the Certificate field | When the Cert Type field is set to 1, the Certificate field | |
| contains an X.509v3 certificate [10], as described in Section | contains an X.509v3 certificate [10], as described in Section | |
| 6.1.1. | 6.1.1. | |
| 6.2.5 Processing Rules for Routers | 6.2.5 Processing Rules for Routers | |
| Routers SHOULD possess a key pair and a certificate from at least one | Routers SHOULD possess a key pair and a certificate from at least one | |
| certificate authority. | certificate authority. | |
| A router MUST silently discard any received Delegation Chain | A router MUST silently discard any received Delegation Chain | |
| Solicitation messages that do not satisfy all of the requirements | Solicitation messages that do not conform to the message format | |
| listed in Section 6.2.1. | defined in Section 6.2.1. The contents of the Reserved field, and of | |
| any unrecognized options, MUST be ignored. Future, | ||
| The contents of the Reserved field, and of any unrecognized options, | backward-compatible changes to the protocol may specify the contents | |
| MUST be ignored. Future, backward-compatible changes to the protocol | of the Reserved field or add new options; backward-incompatible | |
| may specify the contents of the Reserved field or add new options; | changes may use different Code values. The contents of any defined | |
| backward-incompatible changes may use different Code values. The | options that are not specified to be used with Router Solicitation | |
| contents of any defined options that are not specified to be used | messages MUST be ignored and the packet processed in the normal | |
| with Router Solicitation messages MUST be ignored and the packet | manner. The only defined option that may appear is the Trust Anchor | |
| processed in the normal manner. The only defined option that may | option. A solicitation that passes the validity checks is called a | |
| appear is the Trust Anchor option. A solicitation that passes the | "valid solicitation". | |
| validity checks is called a "valid solicitation". | ||
| Routers SHOULD send advertisements in response to valid solicitations | Routers SHOULD send advertisements in response to valid solicitations | |
| received on an advertising interface. If the source address in the | received on an advertising interface. If the source address in the | |
| solicitation was the unspecified address, the router MUST send the | solicitation was the unspecified address, the router MUST send the | |
| response to the link-scoped All-Nodes multicast address. If the | response to the link-scoped All-Nodes multicast address. If the | |
| source address was a unicast address, the router MUST send the | source address was a unicast address, the router MUST send the | |
| response to the Solicited-Node multicast address corresponding to the | response to the Solicited-Node multicast address corresponding to the | |
| source address, except when under load, as specified below. Routers | source address, except when under load, as specified below. Routers | |
| SHOULD NOT send Delegation Chain Advertisements more than | SHOULD NOT send Delegation Chain Advertisements more than | |
| MAX_DCA_RATE times within a second. When there are more | MAX_DCA_RATE times within a second. When there are more | |
| Skipping to change at page 36, line 7: | ||
| solicited. | solicited. | |
| 6.2.6 Processing Rules for Hosts | 6.2.6 Processing Rules for Hosts | |
| Hosts SHOULD possess the public key and trust anchor name of at least | Hosts SHOULD possess the public key and trust anchor name of at least | |
| one certificate authority, they SHOULD possess their own key pair, | one certificate authority, they SHOULD possess their own key pair, | |
| and they MAY possess a certificate from the above mentioned | and they MAY possess a certificate from the above mentioned | |
| certificate authority. | certificate authority. | |
| A host MUST silently discard any received Delegation Chain | A host MUST silently discard any received Delegation Chain | |
| Advertisement messages that do not satisfy all of the requirements | Advertisement messages that do not conform to the message format | |
| listed in Section 6.2.2. | defined in Section 6.2.2. The contents of the Reserved field, and of | |
| any unrecognized options, MUST be ignored. Future, | ||
| The contents of the Reserved field, and of any unrecognized options, | backward-compatible changes to the protocol may specify the contents | |
| MUST be ignored. Future, backward-compatible changes to the protocol | of the Reserved field or add new options; backward-incompatible | |
| may specify the contents of the Reserved field or add new options; | changes may use different Code values. The contents of any defined | |
| backward-incompatible changes may use different Code values. The | options that are not specified to be used with Delegation Chain | |
| contents of any defined options that are not specified to be used | Advertisement messages MUST be ignored and the packet processed in | |
| with Delegation Chain Advertisement messages MUST be ignored and the | the normal manner. The only defined options that may appear are the | |
| packet processed in the normal manner. The only defined options that | Certificate and Trust Anchor options. An advertisement that passes | |
| may appear are the Certificate and Trust Anchor options. An | the validity checks is called a "valid advertisement". | |
| advertisement that passes the validity checks is called a "valid | ||
| advertisement". | ||
| Hosts SHOULD store certificate chains retrieved in Delegation Chain | Hosts SHOULD store certificate chains retrieved in Delegation Chain | |
| Discovery messages if they start from an anchor trusted by the host. | Discovery messages if they start from an anchor trusted by the host. | |
| The certificate chains SHOULD be verified, as defined in Section 6.1, | The certificate chains SHOULD be verified, as defined in Section 6.1, | |
| before storing them. Routers MUST send the certificates one by one, | before storing them. Routers MUST send the certificates one by one, | |
| starting from the trust anchor end of the chain. Except for | starting from the trust anchor end of the chain. Except for | |
| temporary purposes to allow for message loss and reordering, hosts | temporary purposes to allow for message loss and reordering, hosts | |
| SHOULD NOT store certificates received in a Delegation Chain | SHOULD NOT store certificates received in a Delegation Chain | |
| Advertisement unless they contain a certificate which can be | Advertisement unless they contain a certificate which can be | |
| immediately verified either to the trust anchor or to a certificate | immediately verified either to the trust anchor or to a certificate | |
| End of changes. | ||
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ | ||