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
--------------------------------------------------------------------