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 |