Reviewer: Pascal Thubert
Review result: Ready with comments
Review Date: Sept 10th, 2020.
Dear Jen,
I am assigned the IOT-DIR (https://trac.ietf.org/trac/int/wiki/IOTDirWiki) IETF LAST CALL review for draft-ietf-v6ops-nd-cache-init.
The review below is based on draft-ietf-v6ops-nd-cache-init-05. Please treat these comments just like any other last call comments.
I found the draft very readable and informative. In particular, the sections 3.x contain valuable information on why other possible variations of exchanges with the router (sending NS, RS, snooping, etc...) are less appropriate. Clearly I stay convinced that RFC 8505 is a better way for modern networks, but this proposal certainly helps - in the meantime.
Please find my comments below:
===========================================================================================================
Major
===========================================================================================================
Section 3 lists a number of approaches, but that list does not match the sections 3.x coming next.
In particular there is no section that explains why we are not " Making the probing logic on hosts more robust."
It seems that if the host sends just one probe to start with, the problem goes away. There must be a reason why this is not done today.
---------------------------------------------------------------------------------------------------------------------------------------------
"
Implementing such functionality is much more complicated than all
other solutions as it would involve complex data-control planes
interaction."
As it goes, reactive ND as it stands involve complex data-control planes interactions, the hardware needs to interrupt its process and tell the software in case of a cache miss.
This process is not only complicated but subject to DoS attacks and all prone to bugs. The solution eliminates that activity for a new address and that is a major plus for the router. Sadly it does not fix the problem permanently as the cache may be flushed. I believe it is important to mention both early in the draft to better position its value (great) and limits (the Neighbor cache is still a cache so the problem is not eliminated).
===========================================================================================================
Minor
==========================================================================================================="
1. A host joins the network and receives a Router Advertisement (RA)
packet from the first-hop router (either a periodic unsolicited
RA or a response to a Router Solicitation sent by the host).
"
Maybe clarify that this is a multicast RA sent to all hosts
---------------------------------------------------------------------------------------------------------------------------------------------
"
The
RA contains information the host needs to perform Stateless
Address Autoconfiguration ([RFC4862]) and to configure its
network stack.
"
You could say "SLAAC and/or DHCPv6" for completeness.
---------------------------------------------------------------------------------------------------------------------------------------------
"
As in most cases the RA also contains the link-
layer address of the router, the host can populate its Neighbor
Cache with the router's link-local and link-layer addresses.
"
Maybe also clarify in before that sentence that the source IPv6 address of the RA is a link local address of the router (section 4.2 of RFC 4861)
---------------------------------------------------------------------------------------------------------------------------------------------
"
Most router
implementations buffer only one data packet while
"
Is that something you know for sure? Else, you may indicate instead that the standard only requires the router to hold one data packet.
For memory, RFC 4861 section 7.2.2. "Sending Neighbor Solicitations" says:
"
...
While waiting for address resolution to complete, the sender MUST,
for each neighbor, retain a small queue of packets waiting for
address resolution to complete. The queue MUST hold at least one
packet, and MAY contain more. However, the number of queued packets
per neighbor SHOULD be limited to some small value. When a queue
overflows, the new arrival SHOULD replace the oldest entry. Once
address resolution completes, the node transmits any queued packets.
...
"
---------------------------------------------------------------------------------------------------------------------------------------------
"If the host sends multiple probes in parallel"
See my Major comment above. With the description above it seems that the host is shooting itself in the foot doing this.
Could you justify why the host needs to send multiple probes as opposed to wait for one to succeed?
---------------------------------------------------------------------------------------------------------------------------------------------
"connects to the network for the first time or after a timeout long"
Maybe "inactivity time" is more suitable than "timeout"
---------------------------------------------------------------------------------------------------------------------------------------------
" This option
requires some investigation and discussions and seems to be excessive
for the problem described in this document. "
The option itself is not "excessive", it is a technical solution. Maybe you could clarify what is excessive, e.g., the complexity to migrate, to implement and deploy, or the time till a solution is available commercially on all devices.
===========================================================================================================
Nits
===========================================================================================================
"if a host A has an neighbor": an -> a
"same sequence of events happen": happen -> happens
Voila!
Take care,
Pascal
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
