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

<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc PUBLIC '' "http://xml.resource.org/authoring/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-03"
     ipr="trust200902"
     obsoletes=""
     updates="5156"
     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="March" year="2012" />
    <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 the effects of 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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        Remote triggered black hole (RTBH) filtering describes a class of
        methods of blocking IP traffic either from a specific source (<xref
        target="RFC5635"/>) or to a specific destination (<xref
        target="RFC3882"/>) on a network. RTBH routing describes a class of
        methods of re-routing IP traffic destined to the attacked/targeted
        host to a special path (tunnel) where a sniffer could capture the
        traffic for analysis. Both 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 connected locally
        or remotely to a router's discard, null or tunnel interface.
        Typically, reachability information for this prefix is propagated
        throughout an autonomous system using a dynamic routing protocol such
        as BGP (<xref target="RFC3882"/>). By deploying RTBH systems across a
        network, traffic to or from specific destinations may be selectively
        black-holed or re-routed to a sinkhole device in a manner which is
        efficient, scalable and straightforward to implement. 
      </t>
      <t>
        On some networks, operators configure RTBH installations using <xref
        target="RFC1918"/> address space or the address blocks reserved for
        documentation in <xref target="RFC5737"/>. This approach is inadequate
        because RTBH configurations are not documentation, but rather
        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 the documentation prefixes described in <xref
        target="RFC5737"/> are inappropriate for RTBH configurations, and that
        a dedicated IPv6 prefix should be assigned instead.
      </t>
      <t>
        This document updates <xref target="RFC5156"/>.
      </t>
      <section title="Notational 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
	configuration, a unicast address block is required. There are
	currently no IPv6 unicast address blocks which are specifically
	nominated for the purposes of implementing such RTBH systems.
      </t>
      <t>
        While it could be argued that there are other addresses and address
        prefixes which could be used for this purpose (e.g. documentation
        prefixes, private address space), 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 assigning a
        globally unique discard prefix for IPv6, the IETF will introduce good
        practice for the implementation of IPv6 RTBH configurations and will
        facilitate operational clarity by allowing operators to implement
        consistent and deterministic inter-domain prefix and traffic filtering
        policies for black-holed traffic.
      </t>
      <t>
        As <xref target="RFC3882" /> and <xref target="RFC5635" /> describe
        situations where more than one discard address may be used for
        implementing multiple remote triggered black hole scenarios, a single
        address is not sufficient to cover all likely RTBH situations.
        Consequently, an address block is required.
      </t>
    </section>

    <section title="Operational Implications" anchor="implications">
      <t>
        This assignment MAY be carried in a dynamic routing protocol within an
        autonomous system. The assignment SHOULD NOT be announced to or
        accepted from third party autonomous systems and IPv6 traffic with a
        destination address within this prefix SHOULD NOT be forwarded to or
        accepted from third party autonomous systems. If the prefix or a
        subnet of the prefix is inadvertently announced to or accepted from a
        third party autonomous system, this may cause excessive volumes of
        traffic to pass unintentionally between the the two networks, which
        would aggravate the effect of a denial-of-service attack.
      </t>
      <t>
        On networks which implement IPv6 remote triggered black holes, some or
        all of this network block MAY be configured with a next-hop
        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 ought not normally be
        transmitted or accepted over inter-domain BGP sessions for the
        reasons described in <xref target="implications" />, it is
        usually appropriate to include this prefix in inter-domain BGP
        prefix filters <xref target="RFC3704" />.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.3882"?> <!-- Configuring BGP to Block Denial-of-Service Attacks -->
      <?rfc include="reference.RFC.5156"?> <!-- Special-Use IPv6 Addresses -->
      <?rfc include="reference.RFC.5635"?> <!-- RTBH Filtering -->
    </references>

    <references title="Informative References">
      <?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>