<?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 strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="std" docName="draft-templin-6man-lla-type-01" ipr="trust200902"
     updates="">
  <front>
    <title abbrev="IPv6 Link-Local Address Type Field">The IPv6 Link-Local
    Address Type Field</title>

    <author fullname="Fred L. Templin" initials="F. L." role="editor"
            surname="Templin">
      <organization>The Boeing Company</organization>

      <address>
        <postal>
          <street>P.O. Box 3707</street>

          <city>Seattle</city>

          <region>WA</region>

          <code>98124</code>

          <country>USA</country>
        </postal>

        <email>fltemplin@acm.org</email>
      </address>
    </author>

    <date day="23" month="November" year="2020"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>IPv6 link-local addresses are formed from the prefix fe80::/10 which
      is followed by 54 "zero" bits, then followed by a 64-bit Interface
      Identifier. There are multiple methods for generating link-local
      addresses, and multiple may be in use by nodes on the same link (and
      sometimes even the same interface) at the same time. This document
      defines an IPv6 link-local address "Type" field that identifies the type
      of link-local address being used.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The IPv6 link-local address prefix is defined in <xref
      target="RFC4291"/> as the prefix fe80::/10 followed by 54 "zero" bits,
      then followed by a 64-bit interface identifier. There are multiple
      methods for generating link-local addresses, and multiple may be in use
      on the same link (and sometimes even the same interface) at the same
      time.</t>

      <t>For example, <xref target="I-D.ietf-6man-rfc4941bis"/>, <xref
      target="RFC7217"/>, <xref target="RFC4291"/>, <xref target="RFC3972"/>,
      <xref target="I-D.templin-6man-omni-interface"/> and possibly others
      define diverse methods for generating interface identifiers for
      constructing link-local addresses on a given interface. Administrative
      configuration (e.g., manually setting the interface ID) is also an
      option available to all interfaces.</t>

      <t>IPv6 multi-addressing allows each interface to assign multiple IPv6
      addresses, and even multiple IPv6 link-local addresses. On some
      interfaces, it may even be the case that multiple link-local addresses
      of different types would be configured at the same time. But, since the
      diverse methods for generating interface identifiers are not coordinated
      with one another, some interfaces may need a way to differentiate the
      types of link-local addresses as well as to avoid collisions and
      duplication.</t>

      <t>This document defines a Type field in the link-local address prefix
      for differentiating link-local address construction types. The Type
      field also has a companion Function field which can be used to perform
      Type-specific functions such as Prefix Delegation (PD).</t>

      <t>This document updates <xref target="RFC4291"/>.</t>
    </section>

    <section anchor="terminology" title="Terminology">
      <t>The terminology in the normative references applies.</t>
    </section>

    <section anchor="interface" title="The IPv6 Link-Local Address Type Field">
      <t><xref target="RFC4291"/> defines the IPv6 link-local address format
      as the prefix fe80::/10, followed by 54 zero bits, then followed by a
      64-bit Interface Identifier as shown in <xref target="llaov6"/>:</t>

      <t><figure anchor="llaov6" title="IPv6 Link-Local Address Format">
          <artwork><![CDATA[   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+
]]></artwork>
        </figure>In this format, there is currently no use for the 54 bits of
      0s, and existing IPv6-over-(foo) documents such as <xref
      target="RFC2464"/> expect them always to be zero regardless of the
      method used in generating the Interface ID.</t>

      <t>However, new IPv6-over-(foo) documents could benefit from having a
      coded indication of the link-local address construction type. This would
      not only allow the interface to differentiate between the address
      construction methods used by the sender in packets received with
      link-local addresses, but it would also provide a means for avoiding
      address duplication between diverse address autoconfiguration methods
      used on the same link.</t>

      <t>This document defines a new Type field in the IPv6 link-local address
      prefix. The Type field and a companion Function field occupy the least
      significant 16 bits of the 64-bit link-local address prefix as shown in
      <xref target="llwithtype"/>:<figure anchor="llwithtype"
          title="IPv6 Link-Local Prefix with Type Field">
          <artwork><![CDATA[      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|1|1|1|1|1|1|0|1|0|            zeros (22 bits)                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       zeros (16 bits)         |    Function   |     Type      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>In this format, Type is an 8-bit field that identifies the
      link-local address type on IPv6-over-(foo) interfaces that recognize the
      field, and Function is an 8-bit Type-specific field. The Type and
      Function fields are present only when preceded by the prefix fe80::/48,
      and are not present when preceded by any other prefix. The values for
      Type that are currently defined are:</t>

      <t><figure anchor="type-values" title="">
          <artwork><![CDATA[     Link-Local Format              Type
     *****************              ****
     Unspecified (default)             0
     Administratively Configured       1
     RFC4941bis                        2
     RFC7217                           3
     RFC4291                           4
     RFC3972                           5
     OMNI                              6
]]></artwork>
        </figure>For example, on IPv6-over-(foo) interface types that
      recognize the Type field, an IPv6 link-local address formed according to
      <xref target="RFC7217"/> would be written as: fe80:0:0:3::[Interface
      ID], while one formed according to <xref target="RFC3972"/> would be
      written as: fe80:0:0:5::[Interface ID]. For some link types, it is
      possible that multiple types would be assigned on the same link and
      possibly even on the same interface.</t>

      <t>For Types '2' (RFC4941bis) and '6' (OMNI), PD clients set the
      Function field to a non-zero prefix length value between 1 and 64 in the
      source addresses of messages used to request a PD. For 'Type 6' (OMNI),
      PD servers set the Function field to a non-zero prefix length value
      between 1 and 64 in the destination addresses of messages used to
      deliver a PD. For all other cases, the Function field is set to the
      value 0 unless otherwise specified in a new link-local address format
      specification, or in an update to this document.</t>

      <t>Note that for existing IPv6-over-(foo) link types, the Type and
      Function fields are always set to the value 0 (unspecified) and the link
      local address format fe80::/64 still applies as it always has.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document defines a Type field for IPv6 link-local addresses, for
      which IANA is instructed to create and maintain a new registry entitled
      "IPv6 Link-Local Address Type values". Initial values are given below;
      future assignments are to be made through Expert Review <xref
      target="RFC8126"/>:</t>

      <figure anchor="type-values-iana"
              title="IANA IPv6 Link-Local Address Type Registry">
        <artwork><![CDATA[     Link-Local Format              Type
     *****************              ****
     Unspecified (default)             0
     Administratively Configured       1
     RFC4941bis                        2
     RFC7217                           3
     RFC4291                           4
     RFC3972                           5
     OMNI                              6
]]></artwork>
      </figure>
    </section>

    <section anchor="secure" title="Security Considerations">
      <t>Security considerations for IPv6 <xref target="RFC8200"/> apply.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>This document is aligned with the IETF 6man (IPv6) working group.</t>

      <t>.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc include="reference.RFC.8200"?>

      <?rfc include="reference.I-D.ietf-6man-rfc4941bis"?>

      <?rfc include="reference.I-D.templin-6man-omni-interface"?>

      <?rfc include="reference.RFC.8126"?>

      <?rfc include="reference.RFC.4291"?>

      <?rfc include="reference.RFC.7217"?>

      <?rfc include="reference.RFC.3972"?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.2464"?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>
    </references>
  </back>
</rfc>
