Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

[Erik Nordmark <[e-mail]>]

[Sorry about responding to the wrong thread.]


Dan,

Thanks for your review comments.

If MLD-snooping was implemented in every L2 device (not just switches,
but also wireless access points, etc) then the impact of multicast NSs
sent for the purposes of address resolution would be reduced.

But the draft is also addressing the other cases of multicast:
  - periodic RAs
  - multicast NS/NA for the purposes of duplicate address detection
  - a host sending a multicast NS to its peer when the routers already
know the MAC address of the peer; redirect messages solve that without
any multicasts

All of those current uses of multicast are part of the motivation for
the draft. The other part of the motivation is to facilitate sleeping
hosts. If you follow the letter in RFC 4861/62 hosts have to be always
be awake to respond to any DAD probe that might arrive, or the hosts
have to redo multicast DAD each time they wake up. Finally having
registrations in the routers provides a standardized approach of
avoiding ND DoS attacks.

More comments below.

On 11/19/13 5:50 AM, Dan Luedtke wrote:> Hi,
 >
 > I know I am too late to make any significat contribution but I like to
 > express why I think this draft is only the second best solution to the
 > problem.
 >
 > A switch should not send a solicited node multicast packet to all
 > connected devices but only to those which's hardware address matches
 > the last 24 bit. In case of non-EUI64 addresses (e.g. Privacy
 > Extensions), the node has previously joined the solicited node
 > multicast groups matching the last 24 bit of its addresses. A switch
 > should track the corresponding MLD messages and thus be able to
 > transmit the multicast message only to the affected ports. Not every
 > multicast message on network layer has to become a broadcast message
 > on link layer. In fact, most switches just flood out multicast packets
 > on all ports, but I see more of a switch issue here than a protocol
 > flaw in NDP.
 > IMHO this is a problem on the link layer and should not lead to quirks
 > or increase of complexity in network layer protocols.
 >
 > On wireless links the situation is probably very different and the
 > wakeup of nodes heavily depends on how many multicast addresses the
 > hardware can listen to without waking up CPU and driver software. My
 > understanding is that there is some kind of hardware filtering before
 > the OS stack gets notified.

A fair number of existing Ethernets are being turned into wireless by
adding wireless APs. Thus it would seem beneficial to have a common
approach to reducing multicasts and facilitating sleeping hosts.

 > I also dislike the idea of centralizing the network management by
 > using a single instance (the router) for node registration. It's
 > probably more a personal thing but to me a network seems more reliable
 > if the nodes "defend" their addresses themselves via DAD.

As long as there is no packet loss and all the hosts are always awake
and reachable, then the current RFC 4862 DAD is perfect. However, to
make the current peer-to-peer DAD robust in the case of packet loss
would mean multicast more than one initial DAD; periodic DAD packets
would seem needed.

Note that it wouldn't be a single router but the set of routers attached
to the link. We have an outstanding question around VRRP routers - and
resolving that one should improve the distribution of the state across
the routers attached to the link.

 > Here are my comments:
 >
 > Section 1.2:
 >> EUI-64 identifiers are recommended as unique Interface Identifiers,
 >> however if the network is isolated from the Internet, uniqueness of
 >> the identifiers may be obtained by other mechanisms such as a random
 >> number generator with lowest collision rate.
 > Does this collide with
draft-gont-6man-deprecate-eui64-based-addresses-00?

Perhaps the draft needs to be more clear on this, but the use of the
EUI-64 (or some other long-term stable identifier) in the ARO is solely
local between the host and the 1st hop routers. (It is needed to tell
the difference between a re-registration by the same host and a
conflicting registration by some other host.)

That is orthogonal to any use of EUI-64 in IPv6 IIDs and IPv6 addresses
- they do not need to use EUI-64 to use ARO. Hence we can (and IMHO
should) deprecate the EUI-64-based addresses.

But we clearly need to state this in the document - it isn't the first
time the question has come up.

 > Section 3.:
 >> An EUI-64 interface ID required for global
 >> communication.
 > See above.
 >
 > Section 9:
 >> A legacy IPv6 Host compliant EAH SHOULD be able to fall
 >> back to RFC 4861 host behavior if there is no efficiency-aware router
 >> (NEAR) in the link.
 > I would like to see a MUST here instead of a SHOULD. The definition of
 > "legacy compliant" implies being able to fall back. Did I miss the
 > point here?

Perhaps the "legacy compliant" is unfortunate. If we remove those words
I think a "SHOULD" is the proper choice - perhaps with an additional
explanation that such fallback is needed in order to interoperate with
legacy routers. So we'll reword it.

 > Section 10.2:
 >> The new default
 >> router then first sends a NS to its peers with a link scope multicast
 >> message to IPv6 address ff02::2 with the ARO option.
 > Just bikeshedding, sorry, but I would like to see "all link-local
 > routers multicast address" instead of the constant ff02::2.

Thanks - will fix.

 > Section 20:
 >> MIN_DELAY_BETWEEN_RAS(CHANGED)          1 second
 > Wow. I consider this a big change! What is the reason for chosing 1
 > second? We are not speaking of periodic RA, right? Then why wait a
 > second between two unicast RA, it does slow down things. For example
 > massive movement of mobile clients from one wifi to another. Happens
 > on conferences sometimes :)
 > Again, I might miss the point here since I had not the time to get to
 > know this draft earlier.

MIN_DELAY_BETWEEN_RAS is only for multicast RAs (see RFC 4861).
Perhaps we should clarify this in the document.

 >
 > Some possible minor typos?!:
 >> intermediate devices include Wireless Controllers that terminate a
 >> overlay tunnel
 > typo: an overlay

OK

 >> o  In a datacenter, where VM mobility and VM address reslution also
 > typo: resolution

Thanks,
    Erik

 > Regards,
 >
 > Dan
 >
 >