Subject: AD review of draft-thaler-v6ops-teredo-extensions (part 2)

From: Jari Arkko <[email-masked]>
Date: Sun, 02 May 2010 23:55:35 +0300

Continuing the review from page 17 to about page 27:

Technical:

This document clarifies the word "consistent" above as follows. The
IPv6 payload length is "consistent" with the length of the UDP
datagram if the IPv6 packet length (i.e., the Payload Length value in
the IPv6 header plus the IPv6 header size) is less than or equal to
the UDP payload length (i.e., the Length value in the UDP header
minus the UDP header size). This allows the use of trailers after
the IPv6 packet, which are defined in the following sections.

I think it would be more honest to say that this updates or extends the
rule from RFC 4380. Consequently, maybe the document needs an "Updates:
RFC 4380" header:

IPv6 Operations Working
Group                                  D. Thaler

Internet-Draft                                                 Microsoft

Expires: August 6, 2010                                 February 2, 2010

8.  IANA Considerations

[RFC Editor: please remove this section prior to publication.]

This document has no IANA Actions.

I do not understand how this can be. The document introduces new
formats and new fields, e.g., DiscoveryType field in Section 4.4. How
are new values allocated?

Editorial:

The Neighbor Discovery Option Trailer is used by the Server Load
Reduction Extension because it allows direct bubbles to encode an
IPv6 Neighbor Solicitation ([RFC4861] section 4.3), in addition to an
IPv6 Neighbor Advertisement ([RFC4861] section 4.4), which prevents
packets from being relayed indirectly through a Teredo server.

Complex sentence. Maybe you should say "... in addition to an IPv6
Neighbor Advertisement ([RFC4861] section 4.4). This allows packets to
be sent without having to relay them through a Teredo server."

In addition to the events specified in [RFC4380], packets equivalent
to those sent for a peer the first time a connection is being
established MAY be generated at other implementation-specific times.

This sentence would benefit from a more exact reference to a section in
RFC 4380. Or at least when I read it as someone who has not had much to
do with Teredo before, I had trouble knowing where to look for.

This document refines the behavior as follows. A Teredo client MAY
choose to send additional router solicitation messages to the server
at other implementation-specific times.

Both here and in the above text excerpt it would be useful to
understand why an implementation might want to do this.

Section 5.1:

This document refines the behavior as follows. A Teredo client MAY
choose to send additional router solicitation messages to the server
at other implementation-specific times.

Section 5.1.1:

This document refines the behavior as follows. A Teredo client MAY
choose to send additional router solicitation messages to the server
at other implementation-specific times.

This text and the quoted text from RFC 4380 appears to be duplicated.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 03 May 2010 23:30:15 +0300

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