One document matched: draft-ietf-v6ops-ipv6-discard-prefix-00.xml

<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/rfc2629.dtd"[
  <!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC2629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
  <!ENTITY RFC3552 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
  <!ENTITY RFC3640 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3640.xml">
]>
<?xml-stylesheet type='text/xsl' 

href="http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info"
     docName="draft-ietf-v6ops-ipv6-discard-prefix-00"
     ipr="trust200902"
     obsoletes=""
     updates=""
     submissionType="IETF"
     xml:lang="en">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->
  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="IPv6 Discard Prefix">
      A Discard Prefix for IPv6
    </title>

    <author initials="N" surname="Hilliard" fullname="Nick Hilliard">
      <organization>INEX</organization>
      <address>
        <postal>
          <street>4027 Kingswood Road</street>
          <city>Dublin</city> 
          <code>24</code>
          <country>IE</country>
        </postal>
        <email>nick@inex.ie</email>
      </address>
    </author>

    <date month="October" year="2011" />
    <area>Operations and Management</area>
    <workgroup>v6ops Working Group</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>v6ops</keyword>

    <abstract>
      <t>
	    Remote triggered black hole filtering describes a method of mitigating
        against denial-of-service attacks by selectively discarding traffic
        based on source or 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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        Remote triggered black hole (RTBH) filtering describes a class of
        methods of blocking IP traffic to or from a specific destination on a
        network. These methods operate by setting the next-hop address of an
        IP packet with a specified source or destination address to be a
        unicast prefix which is wired locally or remotely to a router's
        discard or null interface. Typically, this information is propagated
        throughout an autonomous system using a dynamic routing protocol. By
        deploying RTBH systems across a network, traffic to or from specific
        destinations may be selectively black-holed in a manner which is
        efficient, scalable and straightforward to implement. For IPv4, some
        networks configure RTBH installations using <xref target="RFC1918"/>
        address space or the address blocks reserved for documentation in
        <xref target="RFC5737"/>.
      </t>
      <t>
        However RTBH configurations are not documentation, but operationally
        important features of many public-facing production networks.
        Furthermore, <xref target="RFC3849" /> specifies that the IPv6
        documentation prefix should be filtered in both local and public
        contexts. On this basis, it is suggested that both private network
        address blocks and documentation prefixes described in <xref
        target="RFC5737"/> are inappropriate for the purpose of RTBH
        configurations.
      </t>
      <t>
        While it could be argued that there are other addresses and address
        prefixes which could be used for this purpose (e.g. ::/128), or that
        an operator could assign an address block from their own address space
        for this purposes, there is currently no operational clarity on what
        address block would be appropriate or inappropriate to use for this
        purpose. By creating an assigned discard prefix for IPv6, the IETF
        will introduce operational clarity and good practice for
        implementation of IPv6 RTBH configurations.
      </t>
      <section title="Conventions">
        <t>
 	      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
          "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
          document are to be interpreted as described in <xref
          target="RFC2119" />.
        </t>
      </section>
    </section>

    <section title="A Discard Prefix for IPv6">
      <t>
		For the purposes of implementing an IPv6 remote triggered black hole
        filter, a unicast address block is required. There are currently no
        IPv6 unicast address blocks which are specifically nominated for the
        purposes of implementing RTBH filters.
      </t>
      <t>
		As <xref target="RFC5635" /> describes situations where more than one
        discard address may be used for implementing multiple remote triggered
        black holes, a single assigned prefix is not sufficient to cover all
        likely RTBH filtering situations. Consequently, an address block is
        required in preference to a single address.
      </t>
    </section>

    <section title="Operational Implications">
      <t>
		This assignment MAY be carried in a dynamic routing protocol within
        an autonomous system. The assignment SHOULD NOT be announced to third
        party autonomous systems and IPv6 traffic with an destination address
        within this prefix SHOULD NOT be forwarded to third party autonomous
        systems.
      </t>
      <t>
		On networks which implement IPv6 remote triggered black holes, some or
        all of this network block MAY be configured with a destination of a
        discard or null interface on any or all IPv6 routers within the
        autonomous system.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>
		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.
      </t>
    </section>

    <section title="Security Considerations">
      <t>
        As the prefix specified in this document should not normally be
        transmitted or accepted over inter-domain BGP sessions, it is
        appropriate to label the prefix as a Martian (<xref target="RFC3704"
        />) for inclusion in inter-domain BGP prefix filters.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.5635"?> <!-- RTBH Filtering -->
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.1881"?> <!-- IPv6 Address Allocation Management -->
      <?rfc include="reference.RFC.1918"?> <!-- Private IPv4 address space -->
      <?rfc include="reference.RFC.2119"?> <!-- Key words for use in RFCs to Indicate Requirement Levels -->
      <?rfc include="reference.RFC.3704"?> <!-- Ingress Filtering for Multihomed Networks -->
      <?rfc include="reference.RFC.3849"?> <!-- IPv6 Documentation Prefix -->
      <?rfc include="reference.RFC.5226"?> <!-- IANA Considerations Section Guidelines -->
      <?rfc include="reference.RFC.5737"?> <!-- IPv4 Documentation Prefixes -->
    </references>
  </back>

</rfc>