On 1/6/2011 2:47 PM, William Allen Simpson wrote:
Google tells me that draft-ietf-sip-discovery-03.txt is still on-line. I've not found my -04, -05, or -06 on-line, so I've occasionally been looking through old backups lately as time allows. Sadly, those systems are long dead, and finding actual systems to read my old data makes the recovery process rather slow.
" When a host or router needs the location of a target host on the local media, it sends a media multicast solicitation for the location of the host, followed by a media multicast of the original data packet. The target node issues an advertisement which indicates its current reachability. " Umm, so it sends a data packet to everyone instead of waiting and sending a unicast packet? Seems rather insecure if that packet wasn't encrypted, not to mention noisy. In addition, I'd hate to see what happens when more than one packet arrives prior to the target node's advertisement being received. Contrary to my last email (where I didn't consider mobile devices and similar which do have memory restrictions), I agree with the as-needed basis, except for routers. A router should have all necessary information and not just as-needed. One could argue that routers can't process that much data, but given the trends I've seen in IOS and other vendors of refreshing arp every 10s or less, I'm pretty sure they can handle it. To streamline the process and since we are using multicast, hosts can just tell the router multicast address who they are to quickly update all local router ND caches, and could just as easily expire an address from the cache. The usual options we use for securing ARP could still apply in this scenario. Jack