Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt

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