<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>

<rfc category="std"
     docName="draft-petrescu-6man-ll-prefix-len-04"
     ipr="trust200902">

  <!-- category values: std, bcp, info, exp, and historic ipr values:
       trust200902, noModificationTrust200902,
       noDerivativesTrust200902, or pre5378Trust200902 you can add the
       attributes updates="NNNN" and obsoletes="NNNN" they will
       automatically be output with "(if approved)" -->

  <front>

    <title abbrev="IPv6-LL-plen">
      The length of the prefix of an IPv6 link-local address ranges
      from 10 to 127
    </title>

    <author initials='A.' surname="Petrescu" fullname='Alexandre 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>
          Alexandre.Petrescu@cea.fr
        </email>
      </address>
    </author>

    <date year='2018'/>

    <!-- Meta-data Declarations -->

    <area>Internet</area>

    <workgroup>6MAN Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc, IETF is fine for
         individual submissions.  If this element is not present, the
         default is "Network Working Group", which is used by the RFC
         Editor as a nod to the history of the IETF. -->

    <keyword>
      IPv6, link-local, subnet, IANA, fe80
    </keyword>

    <!-- Keywords will be incorporated into HTML output files in a
         meta tag but they have no effect on text or nroff output. If
         you submit your draft to the RFC Editor, the keywords will be
         used for the search engine. -->

    <abstract>
      <t>
	A rejected Errata to RFC4291 "IPv6 Addr Archi" on the topic of
	link-local addresses 'needs' a draft.  This is an answer to
	that need.
      </t>
      <t>
	The length of the prefix of an IPv6 link-local address is
	variable.  The minimal value is 10 decimal.  The maximum value
	is 127 decimal.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Definitions and Statements">
      <t>
	The prefix of an IP address is formed by the n leftmost bits
	of the address.  (in a left-to-right writing system).
      </t>
      <t>
	The prefix of an IP address is used for goals such as:
	identify the type of an IPv6 address (link-local, global,
	others), identify the belonging of an IP address to a
	particular subnetwork, assist the forwarding (or not
	forwarding) decisions, and others.
      </t>
      <t>
	The minimal length of the prefix of an IPv6 link-local address
	(the value of n) is equal to 10 decimal.  The maximum is 127.
      </t>
      <t>
	The prefix of an IPv6 link-local address is represented
	textually as "fe80::/n", where n MAY be any value between 10
	and 127.
      </t>
      <t>
	Regardless of the prefix length, the leftmost 10 bits of an
	IPv6 link-local address MUST be set to binary 1111111010
	(hexadecimal fe80).
      </t>
      <t>
	The illustration of an IPv6 link-local address is:
            <figure anchor="fig:ll" 
                    title='The IPv6 link-local address'
                    align="center">
              <artwork align="center">
                <![CDATA[
   | leftmost |         Subnet ID and Interface ID
   | 10 bits  |                 118 bits                             |
   +----------+------------------------------------------------------+
   |1111111010+          Bits that MAY be either 0 or 1              |
   +----------+------------------------------------------------------+
               ]]>
              </artwork>
            </figure>
      </t>
      <t>
	Examples: fe80::1/10, fe80:1::1/32 and fe80::1:1/64 are all
	IPv6 link-local addresses; their prefix lengths are 10, 32 and
	64 respectively. Each such IPv6 address has the leftmost 10
	bits equal to binary 1111111010.
      </t>
      <t>
	The Difficulty: the number binary 1111111010 can not be
	written in hexadecimal without specifying the number of
	significant bits (fe80::/10); yet that does not make it a
	'prefix'.  Converting 1111111010 to hexadecimal leads to 3FA
	(because in a left-to-right writing system the leading 0s
	before comma are irrelevant); yet '3FA' is not commonly known
	to be the leading bits of an IPv6 link-local address,
	fe80::/10 is.
      </t>
    </section>
    
    <section title="Terminology"
	     anchor='terminology'>
      <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>
      <t>
	prefix: a contiguous string of bits valid for forwarding
	operations and for subnet formation.
      </t>
      <t>
	textual representation of a prefix: e.g. fe80::/64.
      </t>
      <t>
	n leading bits: the first n bits in a string of bits read from
	left to right in a writing system that is read left-to-right.
	E.g. the 10 leading bits of the fe80::/64 textual
	representation of the IPv6 link-local prefix are 1111111010.
      </t>
    </section>
    
    <section title='Context'>
      <t>
	The RFC "IPv6 Address Archi" illustrates the format of the
	link-local addresses.  From the illustration it MAY be
	understood that the length of the link-local prefix is 10 bits
	of value 1111111010 and 54 0 bits.
      </t>
      <t>
	IANA lists the "IPv6 prefix", and "Address Block", to be
	"fe80::/10" on its website.  It is possible that in the future
	the IETF could decide to use the bits 11-53.
      </t>
      <t>
	The RFC 2464 "IPv6-over-Ethernet" states that the prefix for
	link-local addresses is "fe80::/64".
      </t>
      <t>
	RFC 6874, "Representing IPv6 Zone Identifiers in Address
	Literals and Uniform Resource Identifiers" specifies the
	link-local addresses to be under prefix "fe80::/10".
      </t>
      <t>
	Several knowledgeable interpretations state that, generally
	speaking, the prefix length of link-local addresses is 10, but
	it is 64 in the particular case of Stateless
	Address-Autoconfiguration (SLAAC).  In this latter case, the
	prefix is named a "subnet prefix", or "prefix on a link", and
	it is "fe80::/64".
      </t>
      <t>
	Implementations of an IPv6 stack in a particular operating
	system allow for the manual configuration of both prefix
	lengths 64 and 10 for link-local addresses.  In another
	operating system the prefix length for link-local addresses
	can not be explicitely specified by the end user, but may be
	indirectly derived from two distinct textual formats by using
	an unspecified rule.
      </t>
      <t>
	Misconfigurations and lack of interoperability MAY arise
	between computers that use mixed prefix lengths for link-local
	addresses.
      </t>
      <t>
	A memo describes the use of IPv6 link-local addresses in
	applications.  The filename of the Internet Draft is
	draft-smith-ipv6-link-locals-apps-00.
      </t>
      <t>
	Historical note: earlier, the link-local prefix fe80::/10 and
	site-local prefix fec0::/10 were grouped into a common
	fe80::/9.  If bits 10-64 were 0 then the prefix was a
	link-local, otherwise a site-local.  The site-local addresses
	were later deprecated by RFC 3879.
      </t>
    </section>

    <section anchor="example" 
	     title="Example of Advantage of LL Prefix Length 32">
      <t>
	This is an example of an advantage of using a prefix length 32
	for link-local addresses: disambiguate the rt table entries
	related to link-local addresses and thus use ping without -I
	parameter.
      </t>
      <t>
	This figure shows two routers each with two interfaces; one
	such interface is connected to the other router; there are two
	interfaces that point elsewhere.
      </t>
      <t> 
            <figure anchor="fig:advantage" 
                    title='Figure'
                    align="center">
              <artwork align="center">
                <![CDATA[
      i1 ------- i2      i3-------i4
      --|Router1|---------|Router2|---
         -------           -------

i2 address is fe80:12::1:1/32 ('12' means subnet between R1 and R2,
                                '1' is R1, 2nd '1' is 'front' interface)
i3 address is fe80:12::2:2/32 
               ]]>
              </artwork>
            </figure>
          </t>
      <t>
	One router's interface (connected to the other router) uses
	address fe80:12::1:1/32 and the other router's corresponding
	interface uses address fe80:12::2:2/32.  With this in place,
	it is possible on one router to ping the other router's
	address without specifying the -I ifacename parameter to ping;
	also it is possible to ssh without using '%' parameter.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>
	The clarification of the definition of the prefix length of
	the IPv6 link-local prefix at IANA is: call it 'leading bits'
	and not 'prefix', or state that the IPv6 prefix length of
	link-local addresses is 10 decimal.  This clarification has
	beneficial impact in the algorithm implementation for
	calculation of the opaque and stable Interface Identifiers for
	IPv6 link-local addresses.  It also positively impacts some
	implementations of IPv6 forwarding.
      </t>
    </section>    

    <section anchor="IANA" title="IANA Considerations">
      <t>
	IANA is requested to change the name of the column head in the
	table that depicts the "Internet Protocol Version 6 Address
	Space".  The name should be "The n leading bits of an address"
	instead of "IPv6 Prefix".
      </t>
      <t>
	The desired effect of this change is that the IPv6 link-local
	prefix be "fe80::/n" and that the 10 leading bits of this
	prefix be 1111111010.  A second effect is that the textual
	representation "fe80::/10" as an IPv6 link-local prefix should
	disappear from that IANA page, because it is wrong.
      </t>
    </section>

    <section anchor="Contributors"
             title="Contributors">
      <t>
	Listed from 6man WG discussion.
      </t>
    </section>

    <section anchor="Acknowledgements"
             title="Acknowledgements">
      <t>
	The following persons are acknowledged for the discussion that
	is reflected in this draft.  Not all points are reflected.
	Some points are copied almost entirely.
      </t>
      <t>
	Ole Troan, Scott Timothy Morizot, Brian Carpenter, Fred Baker,
	Mark Smith, Peter Occil, Philip Homburg, Albert Manfredi,
	_ B (TATUYA Jinmei), Fernando Gont,
	Christian Huitema, Simon Hobson, Matthew Petach, Yucel Guven,
	Sander Steffann, Dennis Ferguson, Musa Stephen Honlue, Philip
	Homburg.
      </t>
      <t>
	Peter Paluch submitted the Errata suggestion to RFC 4291 about
	link-local addresses, and Brian Haberman rejected it, by
	requiring a draft.  Igor Lubashev pointed to that Errata.
      </t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc
        include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119"
      ?>
    </references>

    <!-- <references title="Informative References"> -->
    <!-- </references> -->

    <section anchor='changelog'
             title='ChangeLog'>
      <t>
        The changes are listed in reverse chronological order, most
        recent changes appearing at the top of the list.
      </t>
      <t>
	-04: added an example advantage of using prefix length 32.
      </t>
      <t>
	-03:
      </t>
      <t>
	-02: corrected a typo in "fe80::/1" and added a 7-bit encoding
	for one persons name (in addition to the japanese-shift-jis
	encoding which is not understood by xml2rfc.)
      </t>
    </section>

  </back>
</rfc>
