Skip to main content

Using Subnet-Specific Link-Local Addresses to Improve SLAAC Robustness
draft-link-v6ops-gulla-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Author Jen Linkova
Last updated 2023-11-06
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-link-v6ops-gulla-00
IPv6 operations                                               J. Linkova
Internet-Draft                                                    Google
Intended status: Informational                           6 November 2023
Expires: 9 May 2024

 Using Subnet-Specific Link-Local Addresses to Improve SLAAC Robustness
                       draft-link-v6ops-gulla-00

Abstract

   This document suggests that a link-local address used by a router as
   a source address for Router Advertisement packets is calculated as a
   function of prefixes listed in the Prefix Information Option of the
   Router Advertisement.  The proposed approach, combined with the Rule
   5.5 of the Default Source Address Selection algorithm (RFC6724)
   improves the robustness of the SLAAC by allowing the hosts to detect
   the IPv6 subnet changes much faster and select the correct source
   address.

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 May 2024.

Copyright Notice

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

Linkova                    Expires 9 May 2024                   [Page 1]
Internet-Draft                    gulla                    November 2023

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Subnet Change Scenarios . . . . . . . . . . . . . . . . . . .   3
     4.1.  Default Address Selection Rule 5.5 and Renumbering  . . .   4
     4.2.  Generating Subnet-Specific Link-Local Addresses for Router
           Interfaces  . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   IPv6 Stateless Address AutoConfugration (SLAAC, [RFC4862] provides
   IPv6 hosts with a mechanism to configure their IPv6 stack based on
   the information (such as an IPv6 prefix and the default router
   address) provided by the on-link routers.  If that information
   changes (e.g. a prefix assigned to the link is changed), the routers
   need to explicitly invalidate the outdated information (e.g. by
   sending a Router Advertisement packet which deprecates the old
   prefix).  In the absense of an explicit signal the host would be
   using the outdated information until its lifetime expires.  Multiple
   documents discusses the SLAAC renumbering problem and proposed
   various improvements to the host and router behaviour (see [RFC9096]
   and draft-ietf-6man-slaac-renum).

Linkova                    Expires 9 May 2024                   [Page 2]
Internet-Draft                    gulla                    November 2023

   This document recommends that the link-local address the router sends
   the router advertisement from should depend on the network prefix(es)
   assigned to the router interface.  As a result, Router Advertisements
   containing different sets of PIOs are sent from different link-local
   addresses.  That allows the hosts to select the source address from
   the prefix advertized by the reachable router.  As a result the host
   would be able to recover from the renyumbering events much faster.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Terminology

   To be added

4.  Subnet Change Scenarios

   There are multiple scenarions when an IPv6 subnet assigned to the
   link can change unexpectedly, leading to outdates and invalid IPv6
   configuration on the host interface.  For example:

   *  A prefix delegated to a CPE router changes, and the router does
      not send RAs to the connected hosts, deprecating the old prefix.
      The hosts would be using addresses from both old and new prefixes
      until the prefix lifetime expires.

   *  A host is connected to a wired port, and a VLAN (and the
      corresponding IPv6 subnet) changed.  This often happens if the
      VLAN is configured as a result of 802.1x or MAC-based
      authentication, so the VLAN is provided by RADIUS.  Some OSes do
      not correctly reset IPv6 stack when the wired interface 802.1x
      state changes from ‘unauthenticated’ to ‘authenticated’ (or vice
      versa).

   In all those scenarions a host might move between networks without
   complete disconnection and without detecting the network change.  As
   a result the following sequence of events may occur, leading to
   broken connectivity:

   *  The host is connected to a network A, receives an RA from the
      router with a PIO containg pref_a, forms IPv6 addresses from that
      prefix using SLAAC.

Linkova                    Expires 9 May 2024                   [Page 3]
Internet-Draft                    gulla                    November 2023

   *  The host attachment changes from network A to network B.  The host
      doesn’t detect the network change and doesn’t clear the IPv6
      stack.

   *  The host receives an RA from the router with a new PIO for pref_b
      and forms new addresses from that prefix.

   *  Now the host has two sets of IPv6 addresses - one from pref_a and
      one from pref_b.  Addresses from pref_a are unusable - the return
      traffic wouldn’t be able to reach the host and outgoing traffic
      might be dropped by anti-spoofing filters.  If the host selects an
      address from pref_a as a source address for outgoing communication
      (as per RFC6724 or by using any other custom algorithms), the
      traffic would be dropped, causing user-visible outages.

4.1.  Default Address Selection Rule 5.5 and Renumbering

   Rule 5.5 of the Default Source Address Selection ([RFC6724]) requires
   the host to prefer addresses in a prefix advertised by the next-hop.
   It allows the multihomed host to select the source address correctly:
   when two routers advertize different prefixes, the host wull be
   sending packets with source address from a given prefix to the router
   the prefix was received from.

   In case of renumbering if both old and new prefixes are advertized by
   the same router (received from a router with the same link-local
   address), then Rule 5.5 doesn't help selecting the correct (working)
   source address.  However if the subnet change also leads to the
   default router address change, then a host implementing Rule 5.5
   could recover from the renumbering quickly:

   *  The host is connected to a network A, receives an RA from the
      router (link-local address LLA_A) with a PIO containg pref_a,
      forms IPv6 addresses from that prefix using SLAAC.

   *  The host attachment changes from network A to network B.  The host
      doesn’t detect the network change and doesn’t clear the IPv6
      stack.

   *  The host receives an RA from the router (link-local address LLA_B)
      with a new PIO for pref_b and forms new addresses from that
      prefix.

   *  Link-local address LLA_A is not reachable anymore, as the host
      changes the network attachement point.  Neighbor Unreachability
      Detection ([RFC4861]) detects it and removes LLA_A from the list
      of default routers.

Linkova                    Expires 9 May 2024                   [Page 4]
Internet-Draft                    gulla                    November 2023

   *  The host is using LLA_B as a next-hop for outgoing traffic, so
      addresses from the pref_b are selected, and addresses from pref_a
      are not used.

4.2.  Generating Subnet-Specific Link-Local Addresses for Router
      Interfaces

   *  The router SHOULD send router advertisement packets from a
      dedicated link-local address.

   *  That dedicated link-local address SHOULD change if the set of
      prefixes advertized in the Router Advertisement changes.  In other
      words, when the set of prefixes advertized on a given interface
      changes, the router SHOULD generate a new link-local address and
      use that address as a source address for Router Advertisements.
      The router SHOULD also send at least one router advertisement as
      soon as it generates a new link-local address.

   Routers which act as DHCPv6-PD clients need to implement some
   algorith to generate the interface ID based on the set of prefixes
   advertised on a given interface.  The exact algorithm is outside of
   scope of this document - it could be some form of hashing function
   which consumes a list of network prefixes and generates a 64-bits
   interface ID.

   At the same time if the interface subnets are configured statically,
   the network administrator can configure link-local addresses
   statically as well.  In some cases it might be possible to just
   utilize the global subnet prefix as an interface ID.  For example, if
   the router has two interfaces configured with 2001:db8:1:1::/64 and
   2001:db8:2:2::/64 subnets respectively, it is sufficient to configure
   f80::2001:db8:1:1 and fe80::2001:db8:2:2 as the link-local addresses
   for those interfaces (if VRRPv3 is used to provide the first-hop
   router redundancy, the virtual link-local address shall be configured
   instead).

5.  Security Considerations

6.  Privacy Considerations

   This document does not introduce any privacy considerations.

7.  IANA Considerations

   This memo does not introduce any requests to IANA.

8.  References

Linkova                    Expires 9 May 2024                   [Page 5]
Internet-Draft                    gulla                    November 2023

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
              <https://www.rfc-editor.org/info/rfc6724>.

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              RFC 6877, DOI 10.17487/RFC6877, April 2013,
              <https://www.rfc-editor.org/info/rfc6877>.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, DOI 10.17487/RFC7050, November 2013,
              <https://www.rfc-editor.org/info/rfc7050>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8781]  Colitti, L. and J. Linkova, "Discovering PREF64 in Router
              Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
              2020, <https://www.rfc-editor.org/info/rfc8781>.

   [RFC8925]  Colitti, L., Linkova, J., Richardson, M., and T.
              Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
              RFC 8925, DOI 10.17487/RFC8925, October 2020,
              <https://www.rfc-editor.org/info/rfc8925>.

8.2.  Informative References

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

Linkova                    Expires 9 May 2024                   [Page 6]
Internet-Draft                    gulla                    November 2023

   [RFC9096]  Gont, F., Žorž, J., Patterson, R., and B. Volz, "Improving
              the Reaction of Customer Edge Routers to IPv6 Renumbering
              Events", BCP 234, RFC 9096, DOI 10.17487/RFC9096, August
              2021, <https://www.rfc-editor.org/info/rfc9096>.

Acknowledgements

   Thanks to Lorenzo Colitti, Fernando Gont, Ole Troan, eric Vyncke for
   the discussions, the input and all contribution.

Author's Address

   Jen Linkova
   Google
   1 Darling Island Rd
   Pyrmont NSW 2009
   Australia
   Email: furry13@gmail.com, furry@google.com

Linkova                    Expires 9 May 2024                   [Page 7]