One document matched: draft-ietf-v6ops-ipv6-discard-prefix-02.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-02"
     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="January" 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
        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.
      </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.  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
        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.  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 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>
        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>
	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 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.
      </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.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>