Dave Thaler writes: 10) 7.1.4 says: > source address. A packet that has already been seen from the same > source with the same Timestamp field value MUST be silently > discard. Since the granularity of the field is in milliseconds, you need to specify that a node must not send two SEND messages during the same millisecond. However, this restriction may be problematic in some scenarios. ----------- Jari Arkko responds to Dave Thaler: Hmm... Yes, I agree that this could be problematic. Is a better granularity needed, say microsecond? ----------- IETF-57 minutes: May be future high-speed link where this is problematic. Can decide this is not an issue (1000 messages/s is enough), or change rule that you can still receive during same 1-ms interval, but monotonically increasing. Normally we try to prevent replays, but for ND & RD, replay "attacks" in short amount of time may not be a problem. Pekka: slight difference in semantics of timestamp between ND options and CGA header. In the CGA header approach, the timestamp is a kind of lifetime for the security association, but in ND options, it's just a timestamp. Michael: I would prefer you put 16 bits of decimal-point seconds. So seconds / 64k (50 us). Monotonically increasing seems simpler. Do you really need to produce thousands or millions of ND messages per second? May be a question to mobile phone operators, for rate of movement from one BS to another. Or how fast are trains moving in the future. Jari: Large # of nodes on the same link may cause this. But currently limits on how fast routers respond to router discovery. But I like your suggestion about 64k. Dave: What is resolution? James: Jari will make a suggestion to the list. ----------- Jari Arkko writes: Issue 6 is about the granularity of timestamps in the SEND protocol. This is relevant for unsolicited advertisements, as I think we'll be using nonces for the others. If the granularity is coarse, the sender might have to delay sending the advertisement until real time advances into a new value within the given granularity. This is not a practical problem right now. OTOH it would be good to design the protocol so that we won't hit a hard limit, should something change in the future. Michael Richardsson made a suggestion in Vienna that we move to fixed point binary scheme, perhaps allocating 16 bits for the fractions of the second. This would be about 20 microseconds granularity. (Clearly, if you clocks don't have this granularity, you can advance them in bigger steps.) I like Michael's suggestion. It seems simple to implement. Lets do it. Any objections? ----------- James Kempf: Sounds fine to me. -----------