Skip to main content

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