[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AD review of draft-thaler-v6ops-teredo-extensions (part 3)


Continuing the review from page 27 to the end:

Technical:

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?

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 5.4.4.3) 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
These MUSTs seem to be in conflict with Section 5.1.1 which relaxed the refresh from 30 seconds to also other values.

Or is the Refresh Timer different from Refresh Interval timer? Perhaps the relationship needs to be explained.

5.4.3.  Initialization
In addition to the behavior specified in [RFC4380], the Port-
Preserving NAT flag and Symmetric NAT flag MUST be set to FALSE when
the Teredo client is started.  The Refresh Timer MUST be started and
scheduled to expire in 30 seconds.
Same as above.

5.4.4.5. 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:

Received on Primary Port
 Peer is Trusted
 Direct Receive on Primary Port flag
 Perform actions from the list item
yes
 no
 n.a.
 Item 1
yes
 yes
 TRUE
 Item 2
yes
 yes
 FALSE
 Item 3
no
 no
 n.a.
 Item 4
no
 yes
 FALSE
 Item 5

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?
The router solicitation MUST include an authentication encapsulation with a
randomly-generated Nonce field, as specified in [RFC4380] section 5.1.1.
Is there a need to reference some RFC on what requirements there are for this randomness. E.g., RFC 4086?

6.5.  Hairpinning Extension

   Teredo             Teredo                      Client A's  Client B's
   Client     NAT     Client        NAT      NAT    Teredo      Teredo
      A        F         B           G        E     Server      Server
  ...
      |        |         |           |        |        |           |
      |        |         |  Direct   |        |        |           |
      |        |         |Bubble to A|        |        |           |
    5 |        |         |---------->|        |        |           |
      |<-----------------------------|        |        |           |
      |        |         |           |        |        |           |
      |        |         |    Indirect Bubble to A     |           |
    6 |        |         |---------------------------->|           |
      |<-----------------------------------------------|           |
      |        |         |           |        |        |           |
      |Direct Bubble to B|           |        |        |           |
    7 |----------------->|           |        |        |           |
      |        |         |           |        |        |           |

                     Hairpinning-based Packet Exchange

 ...
8.   The next direct bubble (Packet 5) is sent by B destined to A's
     UPnP mapped address/port, which is the second mapping in the
     Alternate Address Trailer sent by A.
9.   The aforementioned direct bubble is received by A because A's
     UPnP-mapped address is reachable from B. A stores the source
     address from which the direct bubble was received in the mapped
     address/port fields of the Peer Entry, as defined in [RFC4380]
     section 5.2.  Also, the mapped address status field (as
     specified in [RFC4380] section 5.2.3) is changed to "trusted."
     At this point, communication in one direction is now possible (A
     to B, but not vice versa).
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...

Editorial:

-

Missing:

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.

Overall conclusion:

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.

Jari