IPv6 Operations T. Chown Internet-Draft Jisc Intended status: Informational C. Cummings Expires: 25 April 2025 Energy Sciences Network D. Carder ESnet 22 October 2024 IPv6 Address Accountability Considerations draft-ccc-v6ops-address-accountability-latest Abstract Hosts in IPv4 networks typically acquire addresses by use of DHCP, and retain that address and only that address while the DHCP lease remains valid. In IPv6 networks, hosts may use DHCPv6, but may instead autoconfigure their own global address(es), and potentially use many privacy addresses over time. This behaviour places an additional burden on network operators who require address accountability for their users and devices. There has been some discussion of this issue on various mail lists; this text attempts to capture the issues to encourage further discussion. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://timchown.github.io/address-accountability/draft-chown-v6ops- address-accountability.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ccc-v6ops- address-accountability/. Discussion of this document takes place on the IPv6 Operations Working Group mailing list (mailto:v6ops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/v6ops/. Subscribe at https://www.ietf.org/mailman/listinfo/v6ops/. Source for this draft and an issue tracker can be found at https://github.com/timchown/address-accountability. 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 25 April 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 2. Address accountability approaches 2.1. Switch-router polling 2.2. Switch-router streaming 2.3. Record all ND traffic 2.4. Force use of DHCPv6 only 2.5. Using 802.1X 2.6. Use a host-based registration protocol 2.7. Using a prefix per host 2.8. Use SAVI mechanisms 3. Privacy Considerations 4. Conclusions 5. Security Considerations 6. IANA Considerations Acknowledgments References Normative References Informative References Authors' Addresses 1. Introduction Administrators of IPv4 networks are used to an address accountability model where devices acquire a single IPv4 address using DHCP [RFC2131] and then use that address while the DHCP lease is valid. The IPv4 address may be a global address, or a private address [RFC1918] used in conjunction with Network Address Translation (NAT) [RFC2663]. The address obtained by DHCP is typically tied to a specific device MAC address. This model allows an administrator to track back an IP address to a user or device, in the event of some incident or fault requiring investigation. While by no means foolproof, this model, which may include use of DHCP option 82, is one that IPv4 network administrators are generally comfortable with. In IPv6 networks, where hosts may use SLAAC [RFC4862] and Privacy Addresses [RFC8191], it is quite possible and highly likely that a host may use multiple IPv6 addresses over time, possibly changing addresses used frequently, or using multiple addresses concurrently. Where privacy addresses are used, a host may choose to generate and start using a new privacy address at any time, and will also typically generate a new privacy address after rebooting. Clients may use different IPv6 addresses per application, while servers may have multiple addresses configured, one per service offered. There are many reasons why address stability is desirable, e.g., DNS mappings, ACLs using IP addresses, and logging. However, such stability may not typically exist in IPv6 client networks, particularly where clients are not managed by the network provider, e.g., in campus 'Bring Your Own Device' (BYOD) deployments. It is also worth noting that in an IPv4 network, it is more difficult for a user to pick and use an address manually without clashing with an existing device on the network, while in IPv6 networks picking an unused address is simple to do without an address clash. 2. Address accountability approaches The issue of address accountability for IPv6 networks, and thus also for dual-stack IPv4-IPv6 networks, is one that has been raised many times in various discussion fora. This document attempts to capture the various solutions proposed, noting the advantages and disadvantages of each approach. At this stage of the draft's evolution, no single approach is recommended. The best solution may vary depending on the scenario and tools available. The existing approaches to address accountability fall into the following categories. 2.1. Switch-router polling By polling network switch and router devices for IPv4 Address Resolution Protocol (ARP) tables and IPv6 Neighbour Discovery (ND) tables, and correlating the results with switch port MAC tables, it should be possible to determine which IP addresses are in use at any specific point in time and which addresses are being used on which switch ports (and thus users or devices). This is the approach that has been adopted by tools such as NAV (https://nav.uninett.no) and Netdot (https://nav.uninett.no), and that will be found in many other (open source) tools. It is sometimes referred to as "ND cache scraping". Such scraping is mentioned in [RFC9099], Section 2.6.1.4, where approaches to gather the data include SNMP (specifically [RFC4293]), streaming telemetry (where the collector subscribes to updates/ notifications from the device), an Application Programming Interface (API), and using a command line interface (CLI, such as ssh). The downside of this approach is the load that may be placed on devices by frequent Simple Network Management Protocol (SNMP) or other polling. The polling frequency needs to be rapid enough to ensure that cached ND/ARP data on devices is not expired between polling intervals, i.e., the ND/ARP data should not be expired more frequently than the device is polled. RFC 9099 suggests this period may be as low as 30 seconds. 2.2. Switch-router streaming A potentially better alternative to polling-based methods of gathering neighbor table data is to have the network element stream table updates to a central monitoring system or data-collection service. Using [RFC8639] and [RFC8641] YANG-Push style event notifications to stream the ipv6/neighbor list entries defined in [RFC8344] to a network management system allows an operator to receive a notification every time this table is updated on a device. This data can then be stored and used later to understand which addresses were used at any given time. In addition to these standard-based methods, similar information can be gathered by using gNMI and OpenConfig or vendor-provided YANG models. Regardless of the choice in technology for streaming these events, it makes the most sense to use a method that only sends new data when an update is made to the table on the network element. 2.3. Record all ND traffic If all ND traffic observed on a link can be captured, it should be possible for IPv6 address usage to be recorded. This would require appropriate capability on a device on any given subnet, e.g. as is currently achieved for RAmond (https://ramond.sourceforge.net) or NDPmon (https://sourceforge.net/projects/ndpmon), or a reporting mechanism for the subnet router, such as syslog. There may also be mechanisms such as a (filtered) Remote Switch Port Analyser (RSPAN) that may be suitable. A benefit of this approach is that collecting all ND traffic would allow additional accounting and fault detection to be undertaken, e.g. rogue RA detection, or DAD DoS detection. The downside may be the significant volume of traffic to be held, if a lengthy history is desired. 2.4. Force use of DHCPv6 only One approach to accountability is to attempt to force devices to only use DHCPv6, rather than SLAAC, which would in principle give the same address accountability model as exists with DHCP for IPv4 today. [RFC4649] for DHCPv6 appears to give at least some functionality of DHCP option 82. While it is possible to craft IPv6 Router Advertisements that give hints to hosts that DHCPv6 should be used, i.e., the 'M' bit is set, there is no obligation on the host to honour that hint. However, if the Autonomous (A) flag in the Prefix Information option is unset (as discussed in section 5.5.3 of RFC 4862), the Prefix Information option should be ignored. In such cases a user running the device will need to determine the on-link prefix if they wish to manually configure their own address. Not all common operating systems support DHCPv6 for host addressing, Android being the most notable exception. Larger enterprises that are enforcing use of DHCPv6 appear to be operating dual-stack environments, so in those scenarios clients that do not support DHCPv6 will be IPv4-only. 2.5. Using 802.1X It is now quite common practice for research and education sites - university or college campuses and research organisations - to use 802.1X for network authentication as part of the international eduroam [RFC7593] (https://www.eduroam.org) federated authentication system, as deployed at thousands of educational sites across over 70 countries. Use of 802.1X gives the network operator knowledge about their own users authenticating, but would require coordination with remote peers for details of visiting users admitted via eduroam. 802.1X can also be used for wired network access control. 2.6. Use a host-based registration protocol A current I-D, [I-D.ietf-dhc-addr-notification], presents a mechanism for hosts to opt in to registering their self-generated or statically-configured addresses to a DHCPv6 server. While it's an opt-in mechanism, it may be enough in some use cases, e.g., when the enterprise controls the devices that can connect to the network. There is a consideration for address lifetimes when using this approach. 2.7. Using a prefix per host By using a prefix per host, the accountability model shifts from identifying address(es) used by a host, to the prefix from which it is using addresses, whether for itself (e.g., for containers) or for providing tethering. [RFC8273] and [RFC9663] describe approaches for devices being assigned a prefix rather than an address (potentially of many addresses) for their network connectivity. The use of a single prefix per device may simplify accountability but may impose an operational cost that some small to medium-sized environments cannot justify. 2.8. Use SAVI mechanisms The FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses approach could be used as defined in [RFC6620]. In this case the accounting Discussion of appropriateness of SAVI mechanisms to be added here. (In principle, SAVI mechanisms work by observing NDP and DHCP messages, allowing bindings to be set up and recorded.) 3. Privacy Considerations This draft discusses mechanisms for a site or organisation to manage address accountability where IPv6 has been deployed. In most networks there is a requirement to be able to identify which users have been using which addresses or devices at a given point in time. This draft was written in response to requests for improved accountability for IPv6 traffic in university campus sites, but the same rationale is likely to apply elsewhere. While the sources of data that may be used for such purposes (e.g., state on routers or switches) is generally not available to general users of the network, it is available to administrators of the network. The use of privacy mechanisms, e.g., RFC 8191, gives the greatest benefit when the addresses are being observed by external third parties. The introduction of randomised MAC addresses for devices is designed to be privacy-enhancing for users, whether used only in the probing messages when seeking to join a network, or for associating to a network to use it. Such randomisation may have an impact on address accountability models. 4. Conclusions This text is an initial draft attempting to capture the issues related to IPv6 address accountability models. If an all-DHCPv6 model is not viable, IPv6 network administrators will need to deploy management and monitoring tools to allow them to account for hosts that will have multiple IPv6 addresses that may also change rapidly over time. Some of the approaches described do not depend on a specific type of address management being used, and will thus work with other addressing methods if they emerge in the future. Feedback on the issues discussed here is welcomed. 5. Security Considerations There are no extra security consideration for this document. 6. IANA Considerations This document has no IANA actions. Acknowledgments The author would like to thank the following people for comments on and suggestions for this text: Nick Buraglio, Jay Stewart, Lorenzo Colitti, Mark Smith, and James Woodyatt. References Normative References [I-D.ietf-dhc-addr-notification] Kumari, W. A., Krishnan, S., Asati, R., Colitti, L., Linkova, J., and S. Jiang, "Registering Self-generated IPv6 Addresses using DHCPv6", Work in Progress, Internet- Draft, draft-ietf-dhc-addr-notification-13, 16 May 2024, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, April 2006, . [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, DOI 10.17487/RFC4649, August 2006, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, . [RFC8191] Yan, Z., Lee, J., and X. Lee, "Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)", RFC 8191, DOI 10.17487/RFC8191, August 2017, . [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, . [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, August 2021, . Informative References [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, . [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Architecture for Network Roaming", RFC 7593, DOI 10.17487/RFC7593, September 2015, . [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, . [RFC9663] Colitti, L., Linkova, J., Ed., and X. Ma, Ed., "Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks", RFC 9663, DOI 10.17487/RFC9663, October 2024, . Authors' Addresses Tim Chown Jisc Email: Tim.Chown@jisc.ac.uk Chris Cummings Energy Sciences Network Email: chris@cummings.tech Dale W. Carder ESnet Email: dwcarder@es.net