<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-boucadair-6man-prefix-routing-reco-02"
     ipr="trust200902" updates="">
  <front>
    <title abbrev="">IPv6 Prefix Length Recommendation for Forwarding</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Alexandru Petrescu" initials="A." surname="Petrescu">
      <organization>CEA, LIST</organization>

      <address>
        <postal>
          <street>CEA Saclay</street>

          <city>Gif-sur-Yvette</city>

          <region>Ile-de-France</region>

          <code>91190</code>

          <country>France</country>
        </postal>

        <phone>+33169089223</phone>

        <email>Alexandru.Petrescu@cea.fr</email>
      </address>
    </author>

    <date day="24" month="September" year="2014" />

    <workgroup>6man Working Group</workgroup>

    <abstract>
      <t>The length of IP prefixes is an information used by forwarding and
      routing processes is policy-based. As such, no maximum length must be
      assumed by design.</t>

      <t>Discussions on the 64-bit boundary in IPv6 addressing revealed a need
      for a clear recommendation on which bits must be used by forwarding
      decision-making processes. This document sketches a recommendation to be
      followed by forwarding and routing designs with regards to the prefix
      length. The aim is to avoid hard-coded routing and forwarding designs
      that exclude some IP prefix lengths.</t>
    </abstract>

    <note title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Recent discussions on the 64-bit boundary in IPv6 addressing (<xref
      target="I-D.ietf-6man-why64"></xref>) revealed a need for a clear
      recommendation on which bits must be used by forwarding decision-making
      processes.</t>

      <t>A detailed analysis of the 64-bit boundary in IPv6 addressing, and
      the implication for end-site prefix assignment, is documented in <xref
      target="I-D.ietf-6man-why64"></xref>. No recommendation is included in
      <xref target="I-D.ietf-6man-why64"></xref>.</t>

      <t>It is fundamental to not link routing and forwarding to the IPv6
      prefix/address semantics <xref target="RFC4291"></xref>. This document
      includes a recommendation for that aim.</t>

      <t>Forwarding decisions made by routers primarily rely upon a longest
      prefix-match algorithm. Like in IPv4, the IPv6 prefix-match algorithms
      involve one critical operation which is the comparison of a destination
      address with a prefix present in a routing table (e.g., compare the
      2001:db8::1 address with the 2001:db8::/64 prefix). The recommendation
      of this document is to be followed by that critical operation.</t>

      <t>It is important that the compare operation be a bit-wise comparison,
      and not a byte-wise comparison.</t>
    </section>

    <section title="Recommendation">
      <t>Forwarding decision-making processes MUST NOT restrict by design the
      length of IPv6 prefixes. In particular, forwarding processes MUST be
      designed to process prefixes of any length up to /128, by increments of
      1.</t>

      <t>Obviously, policies can be enforced to restrict the length of IP
      prefixes advertised within a given domain or in a given interconnection
      link. These policies are deployment-specific and/or driven by
      administrative (interconnection) considerations.</t>

      <t>This recommendation does not conflict with the 64-bit boundary for
      IPv6 stateless address autoconfiguration (SLAAC) <xref
      target="RFC4862"></xref>.</t>

      <t>Some lookup algorithm implementations (find the prefix matching a
      given destination address) may be affected by this recommendation, even
      more so for IPv6 than IPv4. The performance of some implementations may
      be degraded when prefix lengths are longer than /64.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document does not introduce security issues in addition to what
      is discussed in <xref target="RFC4291"></xref>.</t>
    </section>

    <section title="Acknowledgements">
      <t>Thanks to Eric Vyncke and Christian Jacquenet for their comments.</t>

      <t>Special thanks to Randy Bush and Brian Carpenter for their
      support.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.4291'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-6man-why64'?>

      <?rfc include='reference.RFC.4862'?>
    </references>
  </back>
</rfc>
