Skip to main content

Teredo Extensions
RFC 6081

Revision differences

Document history

Date Rev. By Action
2020-01-21
08 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
08 (System) Notify list changed from dthaler@microsoft.com, draft-thaler-v6ops-teredo-extensions@ietf.org, fred@cisco.com to fred@cisco.com
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2011-01-14
08 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2011-01-14
08 Cindy Morgan [Note]: changed to 'RFC 6081'
2011-01-14
08 (System) RFC published
2010-10-11
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-10-11
08 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-10-11
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-10-04
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-10-04
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-10-04
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-10-04
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-10-01
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-09-28
08 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-09-27
08 (System) IANA Action state changed to In Progress
2010-09-27
08 Amy Vezza IESG state changed to Approved-announcement sent
2010-09-27
08 Amy Vezza IESG has approved the document
2010-09-27
08 Amy Vezza Closed "Approve" ballot
2010-09-24
08 (System) Removed from agenda for telechat - 2010-09-23
2010-09-23
08 Cindy Morgan State changed to Approved-announcement to be sent from IESG Evaluation::External Party by Cindy Morgan
2010-09-23
08 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-09-23
08 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-09-17
08 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-09-16
08 Jari Arkko Placed on agenda for telechat - 2010-09-23 by Jari Arkko
2010-09-16
08 Jari Arkko [Note]: 'On the agenda to get more votes!!!<br>Fred Baker (fred@cisco.com) is the document shepherd.' added by Jari Arkko
2010-09-16
08 Russ Housley
[Ballot discuss]
Roni Even raises two concerns in his Gen-ART Review.  Please respond
  to both of the concerns.  The review can be found at: …
[Ballot discuss]
Roni Even raises two concerns in his Gen-ART Review.  Please respond
  to both of the concerns.  The review can be found at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-thaler-v6ops-teredo-extensions-07-even.txt
2010-09-16
08 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2010-09-10
08 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2010-09-10
08 Jari Arkko Waiting for Russ to clear.
2010-09-10
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-09-10
08 (System) New version available: draft-thaler-v6ops-teredo-extensions-08.txt
2010-08-26
08 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-08-26
08 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-08-26
08 Alexey Melnikov [Ballot comment]
Trailer type field might benefit from having an IANA registry.
2010-08-26
08 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2010-08-26
08 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-08-25
08 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2010-08-25
08 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner
2010-08-25
08 Sean Turner
[Ballot discuss]
This isn't my area of expertise, but IDnits is throwing two errors for non-RFC3849-compliant IPv6 addresses:

  ** There are 2 instances of …
[Ballot discuss]
This isn't my area of expertise, but IDnits is throwing two errors for non-RFC3849-compliant IPv6 addresses:

  ** There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses
    in the document.  If these are example addresses, they should be changed.

In verbose mode it says:

Found possible IPv6 address '2001:0:CB00:7178:0:EFFF:3FFF:FDFE' in position 1325 in the paragraph; this doesn't match RFC 3849's suggested 2001:DB8::/32 address range or RFC 4193's Unique Local Address range FC00::/7.

Found possible IPv6 address '2001:0:CB00:7178:0:F000:39CC:9B89' in position 1203 in the paragraph; this doesn't match RFC 3849's suggested 2001:DB8::/32 address range or RFC 4193's Unique Local Address range FC00::/7.

Is it okay for these to not be from the examples range?
2010-08-25
08 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner
2010-08-24
08 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2010-08-24
08 Russ Housley
[Ballot discuss]
Roni Even raises two concerns in his Gen-ART Review.  Please respond
  to both of the concerns.  The review can be found at: …
[Ballot discuss]
Roni Even raises two concerns in his Gen-ART Review.  Please respond
  to both of the concerns.  The review can be found at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-thaler-v6ops-teredo-extensions-07-even.txt
2010-08-24
08 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2010-08-17
08 Jari Arkko State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko
2010-08-12
08 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-08-09
08 Jari Arkko Placed on agenda for telechat - 2010-08-26 by Jari Arkko
2010-07-15
08 Amanda Baber IANA comments:

We understand that this document does not require any IANA actions.
2010-07-15
08 Cindy Morgan Last call sent
2010-07-15
08 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2010-07-14
08 Jari Arkko Last Call was requested by Jari Arkko
2010-07-14
08 Jari Arkko State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko
2010-07-14
08 Jari Arkko Ballot has been issued by Jari Arkko
2010-07-14
08 Jari Arkko
Responses from Dave Thaler look good, so does the new document version. I do want to change the IANA considerations section, but that is a …
Responses from Dave Thaler look good, so does the new document version. I do want to change the IANA considerations section, but that is a small thing that we can deal with later.
2010-07-14
08 Cindy Morgan [Note]: 'Fred Baker (fred@cisco.com) is the document shepherd.' added by Cindy Morgan
2010-07-14
08 Cindy Morgan
> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in …
> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

The document shepherd is Fred Baker. Yes, I believe that it is ready for publication.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

The document has had extensive review in the working group and among users of the technology.

> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?

No

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of?

No.

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

The working group accepts the recommendations.

> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See the
> Internet-Drafts Checklist
>
> and
> http://tools.ietf.org/tools/idnits/
> ). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?

The author has recently addressed the idnits issues (lines too long); I don't believe it requires other reviews.

> (1.h) Has the document split its references into normative and
> informative?

The references are to stable documents - RFCs or a stable output of the UPnP forum.

> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document?

The document makes no request of IANA.

> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

The document contains tables, but no formal grammar.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up? Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:
>
> Technical Summary

This document specifies a set of extensions to the Teredo protocol.
These extensions provide additional capabilities to Teredo, including
support for more types of Network Address Translations (NATs), and
support for more efficient communication.

> Working Group Summary

The working group had no problem with the document.

> Document Quality

The document clearly has at least one normative implementation, by Microsoft. There are also open source implementations.
2010-07-14
08 Cindy Morgan State Change Notice email list have been change to dthaler@microsoft.com, draft-thaler-v6ops-teredo-extensions@tools.ietf.org, fred@cisco.com from dthaler@microsoft.com, draft-thaler-v6ops-teredo-extensions@tools.ietf.org
2010-07-12
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-07-12
07 (System) New version available: draft-thaler-v6ops-teredo-extensions-07.txt
2010-06-27
08 Jari Arkko
Dave says the document is on his to do list:

(22.28.25) jariarkko@jabber.org/Gaim: any news on teredo-extensions?
(22.28.48) Dave Thaler: it's on my TODO list …
Dave says the document is on his to do list:

(22.28.25) jariarkko@jabber.org/Gaim: any news on teredo-extensions?
(22.28.48) Dave Thaler: it's on my TODO list
(22.29.04) Dave Thaler: I'm having one of the other MS guys generate proposed diffs for me to review
(22.29.06) jariarkko@jabber.org/Gaim: ok. i just wanted to make sure you knew about it.
(22.29.11) Dave Thaler: absolutely
(22.29.15) Dave Thaler: it's one of 2 docs on my plate
(22.29.31) Dave Thaler: the other one is the uni-based-mcast doc from mboned that also went through IETF LC
(22.30.09) Dave Thaler: at least I think it was IETF LC... it got genart review etc
(22.30.45) jariarkko@jabber.org/Gaim: i'm not sure i remember without checking  from the tracker. but I know teredo-update was approved couple of weeks ago.
(22.31.05) Dave Thaler: yes, suresh was taking care of that one
(22.31.29) Dave Thaler: I was just acking stuff on that one
(22.31.58) Dave Thaler: I think I did the previous submission on that one so it was his turn :)
(22.32.55) jariarkko@jabber.org/Gaim: it went surprisingly smoothly. lets see if the other one does. I know remi had some issues at least, and he hasn't done a recent review (I was trying to push him but maybe the IETF LCs etc will wake him up)
(22.33.38) Dave Thaler: ok
2010-06-22
08 Jari Arkko reminder sent to the authors
2010-05-13
08 Amanda Baber IANA comments:

We understand this document to have NO IANA actions.
2010-05-03
08 Jari Arkko
I am reviewing this document, and even though the review is not complete yet, I decided to post the comments that I have so far. …
I am reviewing this document, and even though the review is not complete yet, I decided to post the comments that I have so far. I have reviewed roughly until page 17. I will continue reading the document tomorrow.

Technical:

> Nonce: A time-variant counter used in the connection setup phase to
> prevent message replay and other types of attacks.


Nonces are typically defined as time-variant random values or values used only once. A counter may be sufficient for this, but was this really what you meant? The document says later:

  When a Teredo client sends an
  indirect bubble, it MUST generate a random 4-byte value, and include
  it in the Nonce field of a Nonce Trailer (section 2.2.1) appended to
  the indirect bubble, and also store it in the Nonce Sent field of its
  Peer Entry for that Teredo peer.

which seems to indicate you really did mean a random value. I think it is important in this application that others are unable to guess it.

> Teredo Client: A node that has access to the IPv4 Internet and wants
> to gain access to the IPv6 Internet.


... using the Teredo protocol? (Otherwise, there are plenty of Teredo devices in the world according to this definition...)

Editorial:

Idnits reports:

>  == No 'Intended status' indicated for this document; assuming Proposed
>      Standard
>
>
>  Checking nits according to http://www.ietf.org/id-info/checklist :
>  ----------------------------------------------------------------------------
>
>  ** There are 15 instances of too long lines in the document, the longest
>      one being 3 characters in excess of 72.


These should be corrected.

>  == There are 6 instances of lines with non-RFC3330-compliant IPv4 addresses
>      in the document.  If these are example addresses, they should be changed.


The document does seem to be using non-RFC3330 addresses as examples, 207.x.x.x and 157.x.x.x and maybe others. Please change them. (AFAICT, the use of IPv6 and private addresses is correct in the document, however, despite warnings from idnits.)

>  Miscellaneous warnings:
>  ----------------------------------------------------------------------------
>
>  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
>      first submitted before 10 November 2008.  Should you add the disclaimer?
>      (See the Legal Provisions document at
>      http://trustee.ietf.org/license-info for more information.) -- however,
>      there's a paragraph with a matching beginning. Boilerplate error?


You may want to check this.

>  == Missing Reference: 'RFC 4380' is mentioned on line 962, but not defined


Section 5.1.1 gets the reference identifier wrong (it has an extra space).

>  -- Obsolete informational reference (is this intentional?): RFC 2463
>      (Obsoleted by RFC 4443
It seems that the new RFC should be used instead, AFAICT.
2010-05-03
08 Jari Arkko
Continuing the review from page 17 to about page 27:

Technical:

>    This document clarifies the word "consistent" above as follows.  The
>    …
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.
2010-05-03
08 Jari Arkko State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko
2010-05-03
08 Jari Arkko
Continuing the review from page 27 to the end:

Technical:

> o  Connection Refresh Count: This field contains the number of direct
>    bubbles …
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.
2010-04-27
08 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2010-04-27
08 Jari Arkko Ballot has been issued by Jari Arkko
2010-04-27
08 Jari Arkko Created "Approve" ballot
2010-04-27
08 (System) Ballot writeup text was added
2010-04-27
08 (System) Last call text was added
2010-04-27
08 (System) Ballot approval text was added
2010-02-19
08 Jari Arkko State Changes to AD Evaluation from Publication Requested by Jari Arkko
2010-02-19
08 Jari Arkko Area acronymn has been changed to int from gen
2010-02-19
08 Jari Arkko Intended Status has been changed to Proposed Standard from None
2010-02-02
08 Cindy Morgan State Changes to Publication Requested from AD is watching by Cindy Morgan
2010-02-02
08 Cindy Morgan
PROTO writeup for:
draft-thaler-v6ops-teredo-extensions-06.txt and
draft-krishnan-v6ops-teredo-update-06.txt

  (1.a)  Who is the Document Shepherd for this document?

These are individual AD-sponsored submissions.  RFC 4858 only specifies …
PROTO writeup for:
draft-thaler-v6ops-teredo-extensions-06.txt and
draft-krishnan-v6ops-teredo-update-06.txt

  (1.a)  Who is the Document Shepherd for this document?

These are individual AD-sponsored submissions.  RFC 4858 only specifies
document shepherds for WG documents.  Per Jari's suggestion, I'm
answering these questions as if I were the shepherd.

          Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Yes.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

These documents were discussed within and reviewed by the V6OPS WG
(being the successor to NGTRANS which published RFC 4380, which these
update/extend), and went through two pseudo-WGLCs:
http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00007.html
http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01408.html

Comments were received on the public list from Remi Denis:
http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01183.html
http://ops.ietf.org/lists/v6ops/v6ops.2008/msg01415.html
and from a bunch of others privately to the authors.

These drafts are I-D versions of a document [MS-TERE] that has been
hosted on a Microsoft site
(http://msdn.microsoft.com/en-us/library/cc247482(PROT.13).aspx)
where it has been subject to detailed review by:

* The Technical Committee (thetc.org) which is an independent
  organization tasked by the US government with reviewing and quality
  checking/reporting of Microsoft protocol documents, and

* compliance test suite developers who developed tests from the
  document and verified that the widely deployed implementation
  matches the spec, and

* by network sniffer developers who have written parsers for it. 

Much feedback from those communities has also been addressed before and
during the WGLCs.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No concerns.

draft-krishnan-v6ops-teredo-update is a result of detailed security
reviews of RFC 4380, independently by both Symantec and Microsoft.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.

No concerns.

          Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

Yes.

The base Teredo RFC (RFC 4380) was in the same position when it was
approved as a Proposed Standard:
  https://datatracker.ietf.org/ipr/129/
where the declaration states it's RAND-Z for standards-track IETF documents.

The intent is that the extensions and security updates have the same
status as RFC 4380.  The disclosure on draft-thaler-v6ops-teredo-extensions
is:
  https://datatracker.ietf.org/ipr/1022/

The disclosures on draft-krishnan-v6ops-teredo-update is:
  https://datatracker.ietf.org/ipr/1042/

The declarations are again RAND-Z for standards track.

As such, the V6OPS WG saw no issues with the extensions and the security
update having the same status as the base protocol, and it being
Proposed Standard.


  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There were not V6OPS WG documents, but the V6OPS WG reviewed them due
to the original Teredo protocol being an NGTRANS output.  Within V6OPS,
they represent the strong concurrence of a few knowledgeable individuals,
with others being silent.  Both drafts are also widely deployed.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No such threats or appeals.


  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)

          Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?

Yes.  (And there is no MIB, media type, or URI type.)

          If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Intended Status:  Proposed Standard


  (1.h)  Has the document split its references into normative and
          informative?

Yes.

          Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

All normative references are upward references, and all are RFCs.


  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?

Yes.

          If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?

No reservations are necessary.

          Are the IANA registries clearly identified?

N/A.

          If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?

The documents do not create a new IANA registry.

          Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

N/A.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no sections written in a formal language.


  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

draft-thaler-v6ops-teredo-extensions specifies a set of extensions to
the Teredo protocol.  These extensions provide additional capabilities
to Teredo, including support for more types of NATs, and support for
more efficient communication (fewer signaling packets).

draft-krishnan-v6ops-teredo-update specifies a set of security updates
for Teredo that mitigate a number of security concerns.  Specifically,
the Teredo protocol defines a set of flags that are embedded in every
Teredo IPv6 address, and this document modifies the use of this flags
field in a backwards compatible way.

Microsoft's own spec [MS-TERE] combined teredo-update and
teredo-extensions, and the same IPR (RAND-Z) declaration
applies to both.  However, the teredo-update and teredo-extensions
docs are now separate to reflect V6OPS consensus that they should be separate:

1) The former addresses the security concerns raised with
  the original RFC, while the latter adds new functionality

2) Hence teredo-update needs to UPDATE 4380, the latter
  need not be listed as such once published as an RFC.

It's also worth noting that a third document
(draft-ietf-v6ops-tunnel-security-concerns, which is not part of this
publication request) discusses security issues and potential mitigations
regarding tunneling more generally, which were identified in the security
reviews of Teredo and other protocols, and is informatively referenced
by draft-krishnan-v6ops-teredo-update. 
draft-ietf-v6ops-tunnel-security-concerns has undergone SECDIR review,
and can be treated as further elaboration on the security considerations
sections of any tunneling protocol document.  Hence the security
considerations sections of the two documents being put forward for
publication now were deemed sufficient for those documents, given this
informative reference.

The third document was originally a V6OPS WG document because it
specifies no protocol behavior, just discusses issues, and because it
was about IPv6 tunneling.  However, the scope of the document was then
broadened to apply to any types of tunneling (not just IPv6), and
that's why it was since moved to (and was reviewed in) INTAREA, where
the discussion was about whether to merge it with Joe Touch's draft
on tunneling issues unrelated to security.  Based on INTAREA discussion,
the consensus was that the community had no preference and it was up to
the authors.  Neither the authors nor Joe Touch had a preference either,
and so the decision was made to keep them separate in the interests of
avoiding useless work in merging them.


          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

No rough areas.

draft-krishnan-v6ops-teredo-update is closely related to
draft-thaler-v6ops-teredo-extensions.  The "Teredo update"
is a set of simple security fixes to the base Teredo protocol
to reflect what actually got implemented and deployed.
(The history is that Symantec originally wrote the security concerns
document and made a number of security recommendations, which mostly
match what Vista and Windows 7 actually do, and the recommendations
were what then became teredo-update.  When the WG reviewed the
recommendations, the only ones that had WG consensus turned out to
be the same ones that Vista and Windows 7 did, and the other things
were either removed or made MAY's to reflect WG consensus.)


          Document Quality
            Are there existing implementations of the protocol?

Yes.

            Have a
            significant number of vendors indicated their plan to
            implement the specification?

Only one "full" implementation is known to exist - Windows 7 includes
all extensions specified, and Vista includes almost all of them.  However,
separate partial implementations were done by test suite compliance
developers and parser developers.


            Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?

Remi Denis made very useful comments publically during the WGLCs.  In addition, the TC previously did thorough reviews.


            If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

N/A

          Personnel
            Who is the Document Shepherd for this document?

These are individual AD-sponsored submissions.  RFC 4858 only specifies
document shepherds for WG documents.  Per Jari's suggestion, I'm
answering these questions as if I were the shepherd.


            Who is the
            Responsible Area Director?

Jari Arkko, jari.arkko@piuha.net


            If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are <TO BE ADDED BY THE AD>.'


The documents don't require IANA experts as there are no IANA actions.



  The Document Shepherd MUST send the Document Shepherd Write-Up to the
  Responsible Area Director and iesg-secretary@ietf.org together with
  the request to publish the document.  The Document Shepherd SHOULD
  also send the entire Document Shepherd Write-Up to the working group
  mailing list.  If the Document Shepherd feels that information which
  may prove to be sensitive, may lead to possible appeals, or is
  personal needs to be written up, it SHOULD be sent in direct email to
  the Responsible Area Director, because the Document Shepherd Write-Up
  is published openly in the ID Tracker.  Question (1.f) of the
  Write-Up covers any material of this nature and specifies this more
  confidential handling.
2010-02-02
06 (System) New version available: draft-thaler-v6ops-teredo-extensions-06.txt
2009-11-09
05 (System) New version available: draft-thaler-v6ops-teredo-extensions-05.txt
2009-09-04
04 (System) New version available: draft-thaler-v6ops-teredo-extensions-04.txt
2009-09-02
08 Jari Arkko Responsible AD has been changed to Jari Arkko from Mark Townsley
2009-03-08
03 (System) New version available: draft-thaler-v6ops-teredo-extensions-03.txt
2008-11-14
(System) Posted related IPR disclosure: Microsoft Corporation's Statement about IPR related to draft-thaler-v6ops-teredo-extensions-02
2008-11-03
02 (System) New version available: draft-thaler-v6ops-teredo-extensions-02.txt
2008-08-06
08 Samuel Weiler Request for Early review by SECDIR is assigned to Larry Zhu
2008-08-06
08 Samuel Weiler Request for Early review by SECDIR is assigned to Larry Zhu
2008-08-05
08 Mark Townsley Draft Added by Mark Townsley in state AD is watching
2008-07-30
(System) Posted related IPR disclosure: Microsoft Corporation's Statement about IPR related to draft-thaler-v6ops-teredo-extensions-01
2008-07-14
01 (System) New version available: draft-thaler-v6ops-teredo-extensions-01.txt
2008-07-07
00 (System) New version available: draft-thaler-v6ops-teredo-extensions-00.txt