base.txt | issue46.txt | |
---|---|---|
Skipping to change at page 22, line 18: | ||
If the message does contain a Nonce option, but the Nonce value is | If the message does contain a Nonce option, but the Nonce value is | |
not recognized, the message MUST be silently dropped. | not recognized, the message MUST be silently dropped. | |
If the message is accepted, the receiver SHOULD store the receive | If the message is accepted, the receiver SHOULD store the receive | |
time of the message and the time stamp time in the message, as | time of the message and the time stamp time in the message, as | |
specified in Section 5.3.4.2 | specified in Section 5.3.4.2 | |
5.3.4.2 Processing all other messages | 5.3.4.2 Processing all other messages | |
Receivers SHOULD be configured with an allowed timestamp Delta value | Receivers SHOULD be configured with an allowed timestamp Delta value, | |
and an allowed clock drift parameter. The recommended default value | a "fuzz factor" for comparisons, and an allowed clock drift | |
for the allowed Delta is 3,600 seconds (1 hour) and for clock drift | parameter. The recommended default value for the allowed Delta is | |
3,600 seconds (1 hour), for fuzz factor 1 second, and for clock drift | ||
1% (0.01). | 1% (0.01). | |
To facilitate timestamp checking, each node SHOULD store the | To facilitate timestamp checking, each node SHOULD store the | |
following information per each peer: | following information per each peer: | |
The receive time of the last received, accepted SEND message. | The receive time of the last received, accepted SEND message. | |
This is called RDlast. | This is called RDlast. | |
The time stamp in the last received, accepted SEND message. This | The time stamp in the last received, accepted SEND message. This | |
is called TSlast. | is called TSlast. | |
Skipping to change at page 23, line 7: | ||
receiver, the receiver MAY respond to the message. However, if it | receiver, the receiver MAY respond to the message. However, if it | |
does respond to the message, it MUST NOT create a neighbor cache | does respond to the message, it MUST NOT create a neighbor cache | |
entry. This allows nodes that have large difference in their | entry. This allows nodes that have large difference in their | |
clocks to still communicate with each other, by exchanging NS/NA | clocks to still communicate with each other, by exchanging NS/NA | |
pairs. | pairs. | |
o When a message is received from a known peer, i.e., one that | o When a message is received from a known peer, i.e., one that | |
already has an entry in the cache, the time stamp is checked | already has an entry in the cache, the time stamp is checked | |
against the previously received SEND message: | against the previously received SEND message: | |
TSnew > TSlast + (RDnew - RDlast) x (1 - drift) | TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz | |
o If TSnew < TSlast, which is possible if packets arrive rapidly and | o If TSnew < TSlast, which is possible if packets arrive rapidly and | |
out of order, TSlast MUST NOT be updated, i.e., the stored TSlast | out of order, TSlast MUST NOT be updated, i.e., the stored TSlast | |
for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD | for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD | |
be updated. Independent on whether TSlast is updated or not, | be updated. Independent on whether TSlast is updated or not, | |
RDlast is updated in any case. | RDlast is updated in any case. | |
5.4 Proxy Neighbor Discovery | 5.4 Proxy Neighbor Discovery | |
The Target Address in Neighbor Advertisement is required to be equal | The Target Address in Neighbor Advertisement is required to be equal | |
End of changes. | ||
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |