SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments
draft-ietf-v6ops-siit-dc-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-02-16
|
03 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-01-25
|
03 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-01-20
|
03 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-10-26
|
03 | (System) | RFC Editor state changed to EDIT |
2015-10-26
|
03 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-10-26
|
03 | (System) | Announcement was received by RFC Editor |
2015-10-26
|
03 | (System) | IANA Action state changed to No IC |
2015-10-26
|
03 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-10-26
|
03 | Cindy Morgan | IESG has approved the document |
2015-10-26
|
03 | Cindy Morgan | Closed "Approve" ballot |
2015-10-26
|
03 | Cindy Morgan | Ballot approval text was generated |
2015-10-23
|
03 | Joel Jaeggli | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-10-15
|
03 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2015-10-15
|
03 | Cindy Morgan | Changed consensus to Yes from Unknown |
2015-10-15
|
03 | Stephen Farrell | [Ballot comment] I would have thought that the BR and ER would be new targets for DoS attack, however, I'm not sure those are really … [Ballot comment] I would have thought that the BR and ER would be new targets for DoS attack, however, I'm not sure those are really different in this respect compared to other existing routers in a data centre - did the wg consider if there are any such differences that are worth noting? (I thought about it for 2 minutes, without finding any;-) |
2015-10-15
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-10-15
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-10-14
|
03 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-10-14
|
03 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-10-14
|
03 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-10-14
|
03 | (System) | Notify list changed from fred.baker@cisco.com, draft-ietf-v6ops-siit-dc.shepherd@ietf.org, v6ops-chairs@ietf.org, draft-ietf-v6ops-siit-dc.ad@ietf.org, draft-ietf-v6ops-siit-dc@ietf.org to (None) |
2015-10-14
|
02 | Kathleen Moriarty | [Ballot comment] I didn't see a response to the SecDir review, so maybe you didn't see it: https://www.ietf.org/mail-archive/web/secdir/current/msg06071.html In particular, it would be good to … [Ballot comment] I didn't see a response to the SecDir review, so maybe you didn't see it: https://www.ietf.org/mail-archive/web/secdir/current/msg06071.html In particular, it would be good to see a response on the following: 2.2.1. e.g. we might want to expand more on the risk that the DC does by design not see that we translate this down to V4 at the edge and thereby loose some of the capabilities of V6 beyond the edge. Therefore the DC may assume a fully V6 conformant client, which is not the case. This may lead to the need of further filtering or protection mechanisms at the edge. 2.2.2. the authors should expand more on architecture requirements not to put two of these translators in sequence (see possibly conflicts with 2.2.3. the authors should expand more on restrictions of putting this in a mixed environment with NAT64 For this one, I was mostly fine with the text, but are there security considerations that need to be spelled out? 7. section 4.9. "MTU and Fragmentation": it is good that we spell out the series of key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one needs to consider when deploying SIIT-DC. I am not sure a "should" is sufficient here. Furthermore, it would be good to consider whether we need to specify and mandate the specific behaviour when encountering these limitations to avoid inconsistent behaviour from the BR if these parameters are encountered and this might be exploited as an attack vector. Thanks! I think you already address his concern for 2.1 in the Security Considerations. |
2015-10-14
|
02 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-10-14
|
02 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-10-13
|
02 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-10-13
|
02 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-10-12
|
02 | Tore Anderson | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-10-12
|
03 | Tore Anderson | New version available: draft-ietf-v6ops-siit-dc-03.txt |
2015-10-05
|
02 | Joel Jaeggli | Placed on agenda for telechat - 2015-10-15 |
2015-10-05
|
02 | Joel Jaeggli | IESG state changed to IESG Evaluation from Waiting for Writeup |
2015-10-05
|
02 | Joel Jaeggli | Ballot has been issued |
2015-10-05
|
02 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2015-10-05
|
02 | Joel Jaeggli | Created "Approve" ballot |
2015-10-05
|
02 | Joel Jaeggli | Ballot writeup was changed |
2015-09-24
|
02 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Tobias Gondrom. |
2015-09-22
|
02 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-09-17
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Qin Wu. |
2015-09-17
|
02 | Christer Holmberg | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg. |
2015-09-11
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2015-09-11
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2015-09-11
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Qin Wu |
2015-09-11
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Qin Wu |
2015-09-11
|
02 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-09-11
|
02 | Michelle Cotton | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-v6ops-siit-dc-02.txt, which is currently in Last Call, and has the following comments: We understand that this … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-v6ops-siit-dc-02.txt, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object. If this assessment is not accurate, please respond as soon as possible. |
2015-09-10
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2015-09-10
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
2015-09-08
|
02 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-09-08
|
02 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (SIIT-DC: Stateless IP/ICMP Translation for … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments) to Informational RFC The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the use of the Stateless IP/ICMP Translation (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilisation of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feel that dual stack causes undesirable operational complexity. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-09-08
|
02 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-09-08
|
02 | Amy Vezza | Last call announcement was changed |
2015-09-07
|
02 | Joel Jaeggli | Last call was requested |
2015-09-07
|
02 | Joel Jaeggli | Last call announcement was generated |
2015-09-07
|
02 | Joel Jaeggli | Ballot approval text was generated |
2015-09-07
|
02 | Joel Jaeggli | Ballot writeup was generated |
2015-09-07
|
02 | Joel Jaeggli | IESG state changed to Last Call Requested from AD Evaluation |
2015-08-25
|
02 | Joel Jaeggli | IESG state changed to AD Evaluation from Publication Requested |
2015-08-24
|
02 | Amy Vezza | Notification list changed to fred.baker@cisco.com, draft-ietf-v6ops-siit-dc.shepherd@ietf.org, v6ops-chairs@ietf.org, draft-ietf-v6ops-siit-dc.ad@ietf.org, draft-ietf-v6ops-siit-dc@ietf.org from draft-ietf-v6ops-siit-dc.all@tools.ietf.org |
2015-08-23
|
02 | Fred Baker | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Informational. It is essentially a white paper describing how existing technologies including draft-ietf-v6ops-siit-eam may be deployed in an operational setting. 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 describes the use of the Stateless IP/ICMP Translation (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilisation of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feel that dual stack causes undesirable operational complexity. Working Group Summary The only real question was whether it belonged in the WG. The WG, in discussion, determined that it constituted an operational procedure comparable to 464xlat, and was therefore within charter. Document Quality The document describes something that is in fact implemented in at least four products from three vendors, and is in use in the author's networks and in other networks, as discussed at IETF 93. Personnel Fred Baker is the document shepherd. The AD is Joel Jaeggli. Briefly describe the review of this document that was performed by the Document Shepherd. I have read the document and commented on it. As one of the authors of RFC 6145, which it builds on, I understand the technology pretty well. Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? Not really. Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? No Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Yes Has an IPR disclosure been filed that references this document? No How solid is the WG consensus behind this document? The working group clearly supports it. Has anyone threatened an appeal or otherwise indicated extreme discontent? No Identify any ID nits the Document Shepherd has found in this document. There are a couple of places where a defined address is used in accordance with the definition, and the RFC in question is identified. Have all references within this document been identified as either normative or informative? Yes Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No Are there downward normative references references (see RFC 3967)? No Will publication of this document change the status of any existing RFCs? No Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. It is correct |
2015-08-23
|
02 | Fred Baker | Responsible AD changed to Joel Jaeggli |
2015-08-23
|
02 | Fred Baker | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2015-08-23
|
02 | Fred Baker | IESG state changed to Publication Requested |
2015-08-23
|
02 | Fred Baker | IESG process started in state Publication Requested |
2015-08-23
|
02 | Fred Baker | IETF WG state changed to WG Document from In WG Last Call |
2015-08-23
|
02 | Fred Baker | Notification list changed to draft-ietf-v6ops-siit-dc.all@tools.ietf.org from "Fred Baker" <fred.baker@cisco.com> |
2015-08-11
|
01 | Fred Baker | Changed document writeup |
2015-08-10
|
02 | Tore Anderson | New version available: draft-ietf-v6ops-siit-dc-02.txt |
2015-08-05
|
01 | Fred Baker | Changed document writeup |
2015-07-24
|
01 | Fred Baker | Notification list changed to "Fred Baker" <fred.baker@cisco.com> |
2015-07-24
|
01 | Fred Baker | Document shepherd changed to Fred Baker |
2015-07-24
|
01 | Fred Baker | Intended Status changed to Informational from None |
2015-07-07
|
01 | Fred Baker | IETF WG state changed to In WG Last Call from WG Document |
2015-06-28
|
01 | Tore Anderson | New version available: draft-ietf-v6ops-siit-dc-01.txt |
2014-12-26
|
00 | Fred Baker | This document now replaces draft-anderson-v6ops-siit-dc instead of None |
2014-12-18
|
00 | Tore Anderson | New version available: draft-ietf-v6ops-siit-dc-00.txt |