NIST IPv6 document
jbates at brightok.net
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
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
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