On 10/11/12 11:23 PM, Carsten Bormann wrote:
Two quick comments:

-- this still uses 10 seconds as a scaler for the ARO registration lifetime. 
6LoWPAN-ND used to use 10, but now uses 60 seconds.

Oops - we'll fix.

-- I'm not too wild about the E-bit.  Maybe we should extract the 6CIO from 
draft-bormann-6lowpan-ghc and use this?

I don't understand the relationship.
The E-bit is there to specify that the router supports AROs. That way the hosts can tell whether it makes sense to try ARO.
How does this relate to compression context?

The two areas in which I think this proposal can benefit from some more 
discussion:

Clearly, mitigating the external ND table DoS is one of the major pain points 
addressed by this.  Thinking point: Is there any way to structure the 
transition from legacy ND to efficient ND in such a way that it becomes easier 
to reap this benefit?

If not all the hosts on the link do explicit registration, then the routers need to be able to send multicast NS messages to find those that didn't register. As noted in RFC 6583, draft-gashinsky-6man-v6nd-enhance-02.txt, and draft-ietf-6man-impatient-nud-05.txt, things can be improved if the routers don't discard NCEs too quickly, and potentially interpret unsolicited NS messages as a registration attempt.

The last part is a bit problematic in general, but if a router has sufficient memory it can definitely track which hosts it has ever heard from on the link and thereby significantly reduce the rate at which is needs to send multicast NS to look for previously unknown hosts.

For DC applications, the assumption of uniqueness of the EUI-64 probably 
requires some more thinking.  VMs get copied all the time, and it is way too 
easy to copy this kind of config info in the process.

I don't think the EUI-64 is different than the IEEE-48 MAC address. In fact the for Ethernet the EUI-64 is derived from the MAC address.

And if cloning a VM results in keeping the same MAC address then things will not work well even for IPv4.

Regards,
   Erik

Grüße, Carsten

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to