[ntp:hackers] IPv6 and autokey

David L. Mills mills at udel.edu
Thu Aug 21 11:31:22 PDT 2003


Danny,

Apparently due to some twitch in the I/O interface code, the
findbcastinter() was not being called in broadast modes. Doing that
seems to make everything work. However, I'm not completely convinced
things are exactly right:

1. When a persistent non-broadcast association is first mobilized, the
findinterface() routine finds the interface associated with the remote
address and thus the local address. Then, the first packet sent has both
remote and local addresses for the cryptosum.

2. When a persistent broadcast (IPv4/6 broadcast, IPv4 multicast)
association is first mobilized, the findbcastinter() routine does the
same thing. Note the local interface can be different for different IPv4
multicast addresses. I don't know if the same thing applies to IPv6. Do
all IPv6 group addresses land/depart on the same interface?

3. When an ephemeral association is mobilized as the result of a
received broadcast (broadcast/muliticast/anycast modes) or unicast
(symmetric modes), it is necessary to find the local interface (unicast)
to send the unicast volley for crypto/delay functions.

4. When an epheral association is not mobilized, as in the usual case
where a server processes a client packet in RPC mode, the inteface left
on the inbound packet is used for the outbound one, and no special case
exists.

I think this stuff needs a gropethink. Certainly, the interfaces for
persistent (configured) associations is clear.

The issues as far as I can see are confined to the ntp_peer.c file. My
brain fries here, since I don't know the real details of Unix socket
semantics. You may have better advice as how to wrangle these things.

Dave



More information about the hackers mailing list