One document matched: draft-ietf-v6ops-ipv6-discard-prefix-01.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-01"
     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
        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.
      </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 or to a
        specific destination on a network.  Remote triggered black hole
        (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.  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, null or
        tunnel 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 or re-routed to
        a sinkhole device 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="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>
	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 assigned prefix is not sufficient to cover all likely RTBH
        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
        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.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>