<?xml version="1.0" encoding="utf-8"?>
<!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-mishra-6man-variable-iids-01"
     ipr="trust200902"
     updates="RFC2464, RFC4291, RFC4861, RFC4862, RFC7136, RFC8273">

  <!-- 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="Variable IID">
      SLAAC Prefixes with Variable Interface ID (IID)
    </title>

    <author fullname="Gyan Mishra" initials="G. " surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>
 
     <author fullname="Dmytro Shytyi" initials="D." surname="Shytyi">
      <organization>6WIND</organization>
      <address>
        <postal>
	    <street></street>
		  <city>Paris</city>
		  <code></code>
          <country>France</country>
        </postal>
        <email>dmytro@shytyi.net</email>
      </address>
    </author>
 
    <author fullname="Alexandre 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>Alexandre.Petrescu@cea.fr</email>
      </address>
    </author>

    <author fullname="Naveen Kottapalli" initials="N. " surname="Kottapalli">
      <organization>Ciena</organization>
      <address>
        <postal>
          <street> 300 Concord Road</street>
          <city>Billerica</city>
          <code>MA 01821</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 978 223 4700</phone>
        <email>nkottapalli@benu.net</email>
      </address>
    </author>
         
    <author fullname="Dusan Mudric" initials="D." surname="Mudric">
      <organization>Ciena</organization>
      <address>
        <postal>
	    <street></street>
          <city></city>
          <code></code>
          <country>Canada</country>
        </postal>
        <phone>+1-613-670-2425</phone>
        <email>dmudric@ciena.com</email>
      </address>
    </author>





    <date year='2024'/>

    <!-- 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>
      keywords
    </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>
	This draft proposes the use of a longer prefixes in
	PIO for SLAAC allowing a maximum prefix length of /80 with an IID of 48 bits.  
	This would eliminate the race to the bottom concerns.  
      </t>
      <t>
	This implementation uses the RA/PIO bits to carry the variable IID to ensure backwards compatibility.  
      </t>
      <t>
	In the past, various IPv6 addressing models have been proposed
	based on a subnet hierarchy embedding a 64-bit prefix.  The
	last remnant of IPv6 classful addressing is a inflexible interface
	identifier boundary at /64.  This document proposes flexibility
	to the fixed position of that boundary for interface addressing.
      </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"
	     anchor="introduction">

	 <t>     
   The Variable IID problem statement document <xref target="I-D.mishra-v6ops-variable-iids-problem-statement"/> goes into detail surrounding the problem we are trying to solve with this document.
   There are many reasons that have come up as to why the fixed boundary must be changed and the two leading issues are firstly parity between addressing mechanisms SLAAC, DHCPv6 and Static, 
   and secondly that Access Networks (AN) Wireless Mobile Broadband (MBB) and Wireline Fixed Broadband (FBB) provisioning systems are fixed at /64 and cannot be changed and thus shorter prefixes as a solution is not possible. 
   Thus the only solution is variable IID.   It is recommended to read the problem statement document before this solutions space document.  
     </t>
	     
	 <t>     
   The lowest common denominator method of configuration for IPv6 nodes is SLAAC <xref target="RFC4862"/>, which is carefully designed to allow any 
   prefix length and any interface identifier (IID) length, provided that they do not total more than 128 bits. Until now, specifications of 
   "IPv6 over foo" mappings, starting with <xref target="RFC2464"/>, have specified an IID length of 64 bits, consistent with the value specified by <xref target="RFC4291"/>.     
     </t>	     

	 <t>     
   This document allows a router to announce an IID length other than 64 on a given link, and updates RFC <xref target="RFC4291"/>, <xref target="RFC2464"/> (and numerous other "IPv6 over foo" documents TBD), 
   and <xref target="RFC4862"/> accordingly. It extends <xref target="RFC4861"/> by defining a new "IID length" mechanism in RA messages. 
     </t>
     
	 <t>     
   This document proposes longer prefixes in PIO for SLAAC allowing a maximum prefix lenght of /80 and an IID for 48 bits.  The recommendation would eliminate the race to the bottom.
   The implementaion for backwards compatibility leverages the use of 6 LSB bits of the 32 bit Reserved2 field in the PIO options header which today per RFC 4861 is initialized to 0 and
   is ignored by the receiver.  Since the PIO Reserved2 field is initialized to 0 by the sender and is ignored by the receiver, it allows for backwards compatibility for Unmodified hosts.    
     </t>     


     
 	</section> 

    <section anchor="termo" title="Terminology">
	<t>	
	Terminolgoy used in defining the IPv6-Only Edge specification.  
	</t>
	
	  <t>Modified Host: Supports this specification</t>
	  
	  <t>Unmodified Host: Does not support this specification</t>
	  
 	</section>    


    <section title="Modified Procedures"
	     anchor="mod">
	     
      <t>
    The predefined IID length specified by <xref target="RFC4291"/>, <xref target="RFC2464"/>, etc. is used to configure the link-local IPv6 address of a node exactly as described in <xref target="RFC4862"/>.	
      </t>
      
      <t>
	On a link where variable IID length is not supported, the predefined IID length will continue to be used to configure all other addresses using SLAAC.
      </t>
      
      <t>
	On a link where variable IID length is supported, each modified router will include an "IID length" indication in every RA/PIO message with the A bit set. 
	This will override the value defined in <xref target="RFC2464"/> (etc.) and in <xref target="RFC4291"/>, for the prefix concerned.
      </t>
      
      <t>
    In this variable IID specification it is recommended to put the IID length in the 6 LSB bits of the 32 Reserved2 field of the PIO for signaling to Modified hosts supporting
    variable IID that the prefix being advertised is not 64 bits.  
    </t>
    
    <t> 
    00000000 would mean 64, i.e. no change and backwards compatible. 
    Any other value would define an IID length in bits. Values less than 48 (00110000) are NOT RECOMMENDED. Values greater than 64 are impossible.    
      </t>                  

     <t> 
    Exmaple of valid IID Length value: "00111011"  /69 with 59 bit IID 
      </t>                  


      <t>
    (Note: Reserved1 is not available - see <xref target="RFC8425"/>.)    
      </t>   
      
      <t>
    When a modified node receives an "IID length" less than 64, it will use that value instead of the default for all unicast address autoconfiguration under that prefix, except link-local.   
      </t>         
 
    </section>
    

    <section title="Operational Considerations"
	       anchor="ops">
	<t>
   - Unmodified hosts and unmodified routers: no change, all use 64-bit IIDs.
	</t>
 
 	<t>
   - Modified hosts and unmodified routers: no change, all use 64-bit IIDs.
	</t>

 	<t>
   - Modified routers and unmodified hosts: no change, all use 64-bit IIDs.
	</t>	


	<t>
   - Modified hosts and modified routers: configure to use longer prefixes and shorter IIDs if desired.
	</t>

      <t>
	<list style="symbols">
	  <t>
	    Modified routers and mixture of modified and unmodified hosts on a link:
	    <list style='hanging'>
	      <t hangText="Modified:">
		<list style="symbols">
		  <t>
		    The modified hosts will use a shorter IID and longer prefix if that is announced.
		  </t>
		</list>
	      </t>
		</list>
	      </t>
	    </list>

	<list style="symbols">
	  <t>
	    The unmodified hosts, according to RFC 4861, MUST ignore the Reserved1 field. So, according to section 5.5.3 clause d) of RFC 4862, 
	    they will ignore any PIO advertising a shorter IID. 	    
	    <list style='hanging'>
	      <t hangText="Unmodified:">		  
		<list style="symbols">
		  <t>			
			Therefore, operators have two choices for Unmodified hosts:
		  </t>			
		  <t>
		    1. Decide that unmodified hosts will not be supported (i.e. will not be able to configure an address using SLAAC).
		  </t>
		  <t>
		    2. Announce (at least) two prefixes on the link - a /64 and a longer one, with a shorter IID. 
		   For that to make sense, we need an extra rule for modified hosts: if a host receives several PIOs from the same router, 
		   it prefers all those with the shortest IID and ignores the others.		   
		  </t>
		</list>
	      </t>
		</list>
	      </t>
	    </list>

      </t>

	  <t>
	    Mixure of Modifiled and Unmodified hosts router on a link is not recommmended. 	      
	  </t>



    </section>
 

    <section anchor="Security" title="Security Considerations">
      <t>
	The administrator should be aware to maintain 64 bit interface
	identifier for privacy when connected directly to the internet
	so that entropy for optimal heuristics are maintained for
	security.
      </t>
      <t>
	Variable length interface identifier shorter than 64 bits
	should be used within networks where there there are
	out-of-band guarantees that the hosts are trusted
	(e.g. corporate intranets and private networks).
      </t>
    </section>    

    <section anchor="IANA" title="IANA Considerations">
      <t>
	IANA Request for RA PIO registry for RESERVE2
      </t>
    </section>

    <section anchor="Contributors"
             title="Contributors">
      <t>
	Brian Carpenter.
      </t>
      
    </section>

    <section anchor="Acknowledgements"
             title="Acknowledgements">

     <t>
     </t>

    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
	   
	      <references title="Normative References">
			  


      
      <?rfc include='reference.I-D.mishra-v6ops-variable-iids-problem-statement'?>

      <?rfc include='reference.I-D.bourbaki-6man-classless-ipv6'?>

      <?rfc include='reference.I-D.templin-aerolink'?>



      <?rfc include='reference.I-D.ietf-6lowpan-btle'?>      


      <?rfc include='reference.I-D.ietf-6lo-6lobac'?>

           
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.2450"?>                             
      <?rfc include="reference.RFC.2464"?>
      <?rfc include="reference.RFC.2467"?>      
      <?rfc include="reference.RFC.2470"?>      
      <?rfc include="reference.RFC.2492"?>            
      <?rfc include="reference.RFC.2497"?>            
      <?rfc include="reference.RFC.2526"?>            
      <?rfc include="reference.RFC.2529"?>            
      <?rfc include="reference.RFC.2590"?>            
      <?rfc include="reference.RFC.2710"?>            
      <?rfc include="reference.RFC.3056"?>            
      <?rfc include="reference.RFC.3146"?>            
      <?rfc include="reference.RFC.3177"?>            
      <?rfc include="reference.RFC.3306"?>
      <?rfc include="reference.RFC.3315"?>                             
      <?rfc include="reference.RFC.3513"?>
      <?rfc include="reference.RFC.3587"?>      
      <?rfc include="reference.RFC.3590"?>      
      <?rfc include="reference.RFC.3627"?>  
      <?rfc include="reference.RFC.3756"?>                 
      <?rfc include="reference.RFC.3775"?>            
      <?rfc include="reference.RFC.3810"?>            
      <?rfc include="reference.RFC.3956"?>            
      <?rfc include="reference.RFC.3972"?>   
      <?rfc include="reference.RFC.4039"?>                          
      <?rfc include="reference.RFC.4086"?>            
      <!-- <?rfc include="reference.RFC.4191"?>             -->
      <?rfc include="reference.RFC.4193"?>            
      <?rfc include="reference.RFC.4213"?>           
      <?rfc include="reference.RFC.4291"?>
      <?rfc include="reference.RFC.4338"?>                             
      <?rfc include="reference.RFC.4380"?>
      <!-- <?rfc include="reference.RFC.4389"?>       -->
      <?rfc include="reference.RFC.4429"?>      
      <?rfc include="reference.RFC.4548"?>   
      <?rfc include="reference.RFC.4692"?>          
      <?rfc include="reference.RFC.4861"?>            
      <?rfc include="reference.RFC.4862"?> 
      <?rfc include="reference.RFC.4887"?>               
      <?rfc include="reference.RFC.4941"?>            
      <?rfc include="reference.RFC.4944"?>            
      <?rfc include="reference.RFC.5072"?>            
      <?rfc include="reference.RFC.5121"?>            
      <!-- <?rfc include="reference.RFC.5175"?>             -->
      <?rfc include="reference.RFC.5214"?>                    
      <?rfc include="reference.RFC.5375"?>
      <?rfc include="reference.RFC.5453"?>                             
      <?rfc include="reference.RFC.5533"?>
      <?rfc include="reference.RFC.5535"?>      
      <?rfc include="reference.RFC.5692"?>      
      <?rfc include="reference.RFC.5942"?>            
      <?rfc include="reference.RFC.5969"?>            
      <?rfc include="reference.RFC.6052"?>            
      <?rfc include="reference.RFC.6126"?>            
      <?rfc include="reference.RFC.6146"?>            
      <?rfc include="reference.RFC.6164"?>            
      <?rfc include="reference.RFC.6177"?>            
      <?rfc include="reference.RFC.6296"?>            
      <?rfc include="reference.RFC.6437"?>     
      <?rfc include="reference.RFC.6583"?>      
      <?rfc include="reference.RFC.6741"?>        
      <?rfc include="reference.RFC.6877"?>                   
      <?rfc include="reference.RFC.7084"?>    
      <?rfc include="reference.RFC.7094"?>      
      <?rfc include="reference.RFC.7217"?>    
      <?rfc include="reference.RFC.7278"?>                              
      <?rfc include="reference.RFC.7296"?>  
      <?rfc include="reference.RFC.7368"?>                   
      <?rfc include="reference.RFC.7421"?>            
      <?rfc include="reference.RFC.7788"?>            
      <?rfc include="reference.RFC.8064"?>            
      <?rfc include="reference.RFC.8084"?>      
      <?rfc include="reference.RFC.8156"?>             
      <?rfc include="reference.RFC.8174"?>  
      <?rfc include="reference.RFC.8425"?>                  

      
    </references>
    

    <references title="Informative References">

      <!-- <?rfc include="reference.I-D.shytyi-opsawg-vysm"?> -->

      <!-- <?rfc include='reference.I-D.ietf-6man-ipv6-address-generation-privacy'?> -->

      <!-- <?rfc include='reference.I-D.ietf-opsec-ipv6-host-scanning'?> -->

      <?rfc include="reference.RFC.8273"?>

    </references>
    
   

  </back>
</rfc>
