NIST IPv6 document

Jack Bates jbates at
Thu Jan 6 15:14:24 CST 2011

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.


More information about the NANOG mailing list