A Discard Prefix for IPv6
draft-ietf-v6ops-ipv6-discard-prefix-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-06-26
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-06-20
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2012-06-14
|
05 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-06-14
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-06-13
|
05 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-06-12
|
05 | (System) | IANA Action state changed to In Progress |
2012-06-12
|
05 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-06-12
|
05 | Amy Vezza | IESG has approved the document |
2012-06-12
|
05 | Amy Vezza | Closed "Approve" ballot |
2012-06-12
|
05 | Amy Vezza | Ballot approval text was generated |
2012-06-12
|
05 | Amy Vezza | Ballot writeup was changed |
2012-06-12
|
05 | Ron Bonica | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-06-12
|
05 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
2012-06-09
|
05 | Nick Hilliard | New version available: draft-ietf-v6ops-ipv6-discard-prefix-05.txt |
2012-06-09
|
04 | Stewart Bryant | [Ballot comment] I agree with Pete's DISCUSS on this document. |
2012-06-09
|
04 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss |
2012-06-08
|
04 | Pete Resnick | [Ballot discuss] I am glad the registry has been updated appropriately and that this document will be adding to it directly. As such, I am … [Ballot discuss] I am glad the registry has been updated appropriately and that this document will be adding to it directly. As such, I am fine with this being Informational. However, it sounds like there is a move afoot to deprecate 5156 now that the registry has been updated. (Comments by Brian Haberman on the 7-June telechat.) Given that, and the fact that there is no longer any need to update 5156, all mention of 5156 should be removed from this document. It can and should stand alone. |
2012-06-08
|
04 | Pete Resnick | Ballot comment and discuss text updated for Pete Resnick |
2012-05-22
|
04 | Ralph Droms | [Ballot comment] Thanks for addressing my issue with the Security Considerations section. |
2012-05-22
|
04 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
2012-05-22
|
04 | Nick Hilliard | New version available: draft-ietf-v6ops-ipv6-discard-prefix-04.txt |
2012-04-23
|
03 | Mary Barnes | Request for Last Call review by GENART Completed. Reviewer: Mary Barnes. |
2012-03-28
|
03 | Nick Hilliard | New version available: draft-ietf-v6ops-ipv6-discard-prefix-03.txt |
2012-02-02
|
02 | Cindy Morgan | Removed from agenda for telechat |
2012-02-02
|
02 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation. |
2012-02-02
|
02 | Cindy Morgan | Ballot writeup text changed |
2012-02-02
|
02 | Ralph Droms | [Ballot discuss] I think the single sentence in the Security Considerations is pretty tightly focused on one specific situation, and the implications from the first … [Ballot discuss] I think the single sentence in the Security Considerations is pretty tightly focused on one specific situation, and the implications from the first phrase: As the prefix specified in this document should not normally be transmitted or accepted over inter-domain BGP session should be made explicit and expanded. |
2012-02-02
|
02 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded |
2012-02-02
|
02 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-02
|
02 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-01
|
02 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded |
2012-02-01
|
02 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2012-02-01
|
02 | Adrian Farrel | [Ballot comment] A bit like Stephen's Comment... Section 3 contains to "SHOULD NOT" directives. This is an implication that these directives can be varied. Do … [Ballot comment] A bit like Stephen's Comment... Section 3 contains to "SHOULD NOT" directives. This is an implication that these directives can be varied. Do you want to describe how and why, or do you want to change to "MUST NOT"? Obviously, these "SHOULD NOTs" also impact the security discussion. |
2012-02-01
|
02 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-31
|
02 | Ron Bonica | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2012-01-31
|
02 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-31
|
02 | Stewart Bryant | [Ballot discuss] I agree with Pete's DISCUSS on the status of this document. I am similarly confused as to why the special addresses are not … [Ballot discuss] I agree with Pete's DISCUSS on the status of this document. I am similarly confused as to why the special addresses are not in the special purposes registry with this document adding to that registry. This document should surely just add a value to the registry and cite itself as the reference. |
2012-01-31
|
02 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded |
2012-01-30
|
02 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-30
|
02 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-30
|
02 | Wesley Eddy | [Ballot comment] I think "militating" should be "mitigating" in the abstract. |
2012-01-30
|
02 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-29
|
02 | Stephen Farrell | [Ballot comment] Hi Nick, I don't get why the 3rd party AS stuff is SHOULD NOT and not MUST NOT. I think it'd be better … [Ballot comment] Hi Nick, I don't get why the 3rd party AS stuff is SHOULD NOT and not MUST NOT. I think it'd be better to s/should not/ought not/ in section 5 to avoid possible 2119 confusion. S |
2012-01-29
|
02 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-28
|
02 | Pete Resnick | [Ballot comment] Though it is true that this document adds a new special use address, it does seem a bit odd to say that this … [Ballot comment] Though it is true that this document adds a new special use address, it does seem a bit odd to say that this document updates 5156. It seems to me that all of the special use addresses listed in 5156 would be better documented by listing them in the IANA special use registry. I wonder why they're not. |
2012-01-28
|
02 | Pete Resnick | [Ballot discuss] I'd like to hear a lot more about the intended status of this document. As a formal IANA allocation for a specific purpose, … [Ballot discuss] I'd like to hear a lot more about the intended status of this document. As a formal IANA allocation for a specific purpose, it seems like this document should be at least a BCP. It could be argued that because this document is specifying how to use RTBH with a particular address, this is actually more appropriately Standards Track. There is certainly protocol in this document. (Of course 5635 is also Informational, but I don't really understand that either.) In addition, I find it telling that this document updates 5156. 5156 collects together special use IPv6 addresses from assorted other documents. Almost all of those documents (4193, 4291, 4380, etc.) are themselves Standards Track or Experimental. This seems to me further evidence that this document should be something more than Informational. (Of course, I would have thought 3330 and 4773 should have been BCP as well, but consistency does not seem to be our forte in this area.) It's not obvious what the correct status is, but I think this is worth a discussion. |
2012-01-28
|
02 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded |
2012-01-23
|
02 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Chris Lonvick. |
2012-01-23
|
02 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2012-01-17
|
02 | Amanda Baber | IANA has a question about the actions in this document. IANA notes that in Section 4 of this document, the IANA Considerations section, the authors … IANA has a question about the actions in this document. IANA notes that in Section 4 of this document, the IANA Considerations section, the authors call for a /64 from the IPv6 Address Space Registry. IANA believes that it is more appropriate for this /64 to come from the IANA IPv6 Special Purpose Address Registry, as per RFC 4773. As such, the assignment would be made from 2001::/23, rather than the more vague ::/3. IANA believes that2001:0003::/64 could be used for the purposes in this document, but we wonder if there are any operational concerns or preference issues related to this choice. |
2012-01-13
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Mary Barnes |
2012-01-13
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Mary Barnes |
2012-01-12
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2012-01-12
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2012-01-09
|
02 | Amy Vezza | Last call sent |
2012-01-09
|
02 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (A Discard Prefix for IPv6) to Informational RFC The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'A Discard Prefix for IPv6' as an 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 2012-01-23. 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 Remote triggered black hole filtering describes a method of militating against denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates RFC5156 by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-discard-prefix/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-discard-prefix/ No IPR declarations have been submitted directly on this I-D. |
2012-01-09
|
02 | Ron Bonica | Placed on agenda for telechat - 2012-02-02 |
2012-01-09
|
02 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica |
2012-01-09
|
02 | Ron Bonica | Ballot has been issued |
2012-01-09
|
02 | Ron Bonica | Created "Approve" ballot |
2012-01-09
|
02 | Ron Bonica | Last Call was requested |
2012-01-09
|
02 | Ron Bonica | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2012-01-09
|
02 | (System) | Ballot writeup text was added |
2012-01-09
|
02 | (System) | Last call text was added |
2012-01-09
|
02 | Ron Bonica | Last Call text changed |
2012-01-09
|
02 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2012-01-09
|
02 | (System) | New version available: draft-ietf-v6ops-ipv6-discard-prefix-02.txt |
2011-12-26
|
02 | Ron Bonica | State changed to AD Evaluation::Revised ID Needed from AD Evaluation. |
2011-12-26
|
02 | Ron Bonica | State changed to AD Evaluation from Publication Requested. |
2011-12-26
|
02 | Ron Bonica | Ballot writeup text changed |
2011-12-26
|
02 | Ron Bonica | Ballot writeup text changed |
2011-12-08
|
02 | Amy Vezza | This is the document Shepherd writeup for draft-ietf-v6ops-ipv6-discard-prefix version 01. The document is I believe ready for advancement to the IESG. it's ready to go … This is the document Shepherd writeup for draft-ietf-v6ops-ipv6-discard-prefix version 01. The document is I believe ready for advancement to the IESG. it's ready to go to the iesg. Prepared November 16, 2011 1.a Joel Jaeggli v6ops co-chair, is the document shepherd for draft-ietf-v6ops-ipv6-discard-prefix. The shepherd has personally read the document, and offered review feedback prior to WG last call. The shepherd believes that the document is prepared for publication subject to concurrence from the IESG regarding advice provided by IANA detailed in section 1.d. 1.b The document has received extensive review both prior to and during WG LC. As the document allocates ipv6 address space for a special purpose application, review was sought and obtained from IANA during the process of WG last call. 1.c The document shepherd has no concerns with the document review so far. 1.d During the germination of the discard prefix request some debate as to the the nature and use of the prefix and therefore what range the prefix should be allocated from ensued. The consensus view represented in the document is that the prefix should probably not be allocated out of the 2000::/3 global unicast address range. this is described in section 4 IANA considerations. This document directs IANA to record the allocation of the IPv6 address prefix xxxx/64 as a discard-only prefix in the IPv6 Address Space registry. No end party is to be assigned this prefix. The prefix should be allocated from ::/3. IANA provided the following advice during the WG last period. 3. The IC section currently states that "The prefix should be allocated from ::/3" and as we would be taking it from 2001:0000::/23 that sentence is probably superfluous. If the author takes a shine to a specific /64 from there he could let us know. Otherwise, I propose we just take the numerically lowest /64, which would be immediately after the TEREDO assignment. We could discuss this with the author in case he has operational concerns with that. Principle consideration guiding allocation out of a unicast but not global unicast prefix is to deliberately limit the scopes in which discard routes can be used. e.g. the prefix should be filtered by default, within a narrow scope e.g. a deliberately confined routing domain such filtering might be relaxed to describe more fine-grained semantics involving discard destinations. Special use assignment out of ::/8 or the broader ::/3 has precedent in rfc 4291 and earlier. It is clear that the alternative to allocation out of ::/3 is allocation from the rfc 4773 2001::/23 special use prefix. 1.e Test for WG consensus was performed at adoption of proposal as a WG document at and after IETF80. A two week last call concluded on 10/25 with no opposition recorded in either case. 1.f No appeal is expected, nor has any participant to date recorded serious discontent with the document in it's present state. 1.g Idnits reports aninformative reference as unused, it is included to support ipv6 address assignment. No other nits are noted. 1.h Normative and informative references are correctly identified. There are no normative references to unpublished documents. Section 2 makes downward reference to the informational RFC 5635 in which the procedure in which a discard route would be used is described. 1.i The IANA considerations section is present. Feedback on the assignment request was solicited and received from IANA. Further details on that feedback are described in section 1.d. 1.j No text in formal language is present. 1.k Technical Summary: Remote triggered black hole filtering describes a method of militating against denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document explains why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. Working group Summary: Milestones 07/05/11 - draft-hilliard-v6ops-ipv6-discard-prefix-00.txt 08/03/11 - Accepted as a working group document 10/10/11 - draft-ietf-v6ops-ipv6-discard-prefix-00 10/11/11 - WG last call begins 10/25/11 - WG last call completed Document quality: Field reports from operators suggested multiple solutions for an appropriate address range were already in use at the time of the inception of this document. A defined prefix will facilitate proper designation of the address range and facilitate the creation of default filters. The request has been relatively simple and uncontroversial as a proposal, and therefore advancement of the document towards the publication has so far encountered few obstacles. |
2011-12-08
|
02 | Amy Vezza | Draft added in state Publication Requested |
2011-12-08
|
02 | Amy Vezza | [Note]: 'Joel Jaeggli, (joelja@bogus.com) v6ops co-chair, is the document shepherd.' added |
2011-10-26
|
01 | (System) | New version available: draft-ietf-v6ops-ipv6-discard-prefix-01.txt |
2011-10-10
|
00 | (System) | New version available: draft-ietf-v6ops-ipv6-discard-prefix-00.txt |