SLAAC Prefixes with Variable Interface ID (IID)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 January 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The lowest common denominator method of configuration for IPv6 nodes is SLAAC [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 [RFC2464], have specified an IID length of 64 bits, consistent with the value specified by [RFC4291].¶

This document allows a router to announce an IID length other than 64 on a given link, and updates RFC [RFC4291], [RFC2464] (and numerous other "IPv6 over foo" documents TBD), and [RFC4862] accordingly. It extends [RFC4861] by defining a new "IID length" mechanism in RA messages.¶

2. Terminology

Terminolgoy used in defining the IPv6-Only Edge specification.¶

Modified Host: Supports this specification¶

Unmodified Host: Does not support this specification¶

3. Modified Procedures

The predefined IID length specified by [RFC4291], [RFC2464], etc. is used to configure the link-local IPv6 address of a node exactly as described in [RFC4862].¶

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.¶

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 [RFC2464] (etc.) and in [RFC4291], for the prefix concerned.¶

In this variable IID specification it is recommended to put the IID length in the 6 bits of the Reserved2 field of the PIO. 0b000000 would mean 64, i.e. no change and backwards compatible. Any other value would define an IID length in bits. Values less than 48 (0b110000) are NOT RECOMMENDED. Values greater than 64 are impossible.¶

(Note: Reserved1 is not available - see [RFC8425].)¶

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.¶

4. Operational Considerations

- Unmodified hosts and unmodified routers: no change, all use 64-bit IIDs.¶

- Modified hosts and unmodified routers: no change, all use 64-bit IIDs.¶

- Modified hosts and modified routers: configure to use longer prefixes and shorter IIDs if desired.¶

• Modified routers and mixture of modified and unmodified hosts on a link:¶

  Modified:

  • The modified hosts will use a shorter IID and longer prefix if that is announced.¶

• 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. Therefore, the operator has two choices:¶

  Unmodified:

  • 1. Decide that unmodified hosts will not be supported (i.e. will not be able to configure an address using SLAAC).¶

  • 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.¶

Mixure of Modifiled and Unmodified hosts router on a link is not recommmended.¶

5. Security Considerations

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.¶

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).¶

6. IANA Considerations

IANA Request for RA PIO registry for RESERVE2¶

7. Contributors

Brian Carpenter.¶

8. Acknowledgements

Authors' Addresses