Continuing the review from page 27 to the end:
o Connection Refresh Count: This field contains the number of direct bubbles that have been sent to the peer since the last time data was communicated between the two peers.
... last time data was sent to the peer, received from the peer, or that we have proof (e.g, via TCP) that there is bidirectional communication?
These MUSTs seem to be in conflict with Section 5.1.1 which relaxed the refresh from 30 seconds to also other values.When the refresh timer expires, the Teredo client MUST go through its list of peers and for each peer to which the Teredo client is communicating through the random port, the Teredo client MUST check the Last Data Packet Sent Timestamp to determine if data has been sent to the peer in the last 30 seconds, and check the Connection Refresh Count field to determine if the count has reached the maximum allowed value of 20. If both checks are false, the Teredo client MUST send a direct bubble (as specified in Section 188.8.131.52) to the peer and increment the Connection Refresh Count. This direct bubble is sent as an attempt to keep the port mappings on all the intermediate NATs alive while the application/user may be temporarily inactive. If on the other hand, data has been sent to the peer in the last 30 seconds, the Connection Refresh Count MUST be reset to zero. The refresh timer MUST then be rescheduled to expire in 30 seconds
Or is the Refresh Timer different from Refresh Interval timer? Perhaps the relationship needs to be explained.
Same as above.
184.108.40.206. Receiving a Direct Bubble
I tried to make a table of the conditions in this section. From my understanding the conditions can be summarized as follows:
Now, I don't know what to do for the no-yes-TRUE condition. Is that not a possible situation?
Also, item 5 only handles the sub-case where Direct Receive on Random Port flag is set to TRUE. What happens when it is set to FALSE?
Is there a need to reference some RFC on what requirements there are for this randomness. E.g., RFC 4086?The router solicitation MUST include an authentication encapsulation with a randomly-generated Nonce field, as specified in [RFC4380] section 5.1.1.
I'm not sure why you say that the communication is only possible from A to B. Packet 5 was just sent from B to A...
Section 3 should discuss how Teredo and its extensions deal with NAT configurations that are unsupported ("No") or outside the scope of this document. I think the answer is that the extended qualification process and the various connectivity tests are guaranteed to terminate in finite time, and that if no successful connectivity can be established, Teredo simply gives up and falls back to plain IPv4.
This draft is very complex and it has been tough to review it in detail. I am still uncertain, if, say, examples are in perfect synchrony with the behaviour descriptions, or if NAT terminology fully agrees with documents from BEHAVE. In any case, the specific issues that I raised in my review should be looked at and a new draft be issued. Once we have corrected these issues we will move forward to IETF Last Call. My hope is that we'll get some additional review at that stage and can ensure that no additional issues remain.