IPv6 Address Accountability Considerations
draft-ccc-v6ops-address-accountability-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tim Chown , Chris Cummings , Dale W. Carder | ||
| Last updated | 2024-10-22 (Latest revision 2024-10-21) | ||
| Replaces | draft-chown-v6ops-address-accountability | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-ccc-v6ops-address-accountability-00
IPv6 Operations T. Chown
Internet-Draft Jisc
Intended status: Informational C. Cummings
Expires: 24 April 2025 Energy Sciences Network
D. Carder
ESnet
21 October 2024
IPv6 Address Accountability Considerations
draft-ccc-v6ops-address-accountability-00
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.
Chown, et al. Expires 24 April 2025 [Page 1]
Internet-Draft IPv6 Address Accountability Consideratio October 2024
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 24 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Address accountability approaches . . . . . . . . . . . . . . 3
2.1. Switch-router polling . . . . . . . . . . . . . . . . . . 4
2.2. Record all ND traffic . . . . . . . . . . . . . . . . . . 4
2.3. Force use of DHCPv6 only . . . . . . . . . . . . . . . . 5
2.4. Using 802.1X . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Use a host-based registration protocol . . . . . . . . . 5
2.6. Using a prefix per host . . . . . . . . . . . . . . . . . 6
2.7. Use SAVI mechanisms . . . . . . . . . . . . . . . . . . . 6
3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Normative References . . . . . . . . . . . . . . . . . . . . . 7
Informative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Chown, et al. Expires 24 April 2025 [Page 2]
Internet-Draft IPv6 Address Accountability Consideratio October 2024
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 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.
Chown, et al. Expires 24 April 2025 [Page 3]
Internet-Draft IPv6 Address Accountability Consideratio October 2024
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) 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. 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.
Chown, et al. Expires 24 April 2025 [Page 4]
Internet-Draft IPv6 Address Accountability Consideratio October 2024
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.3. 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 of the
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 ones running dual-stack, so
in those scenarios clients that do not support DHCPv6 will be
IPv4-only.
2.4. 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.5. 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.
Chown, et al. Expires 24 April 2025 [Page 5]
Internet-Draft IPv6 Address Accountability Consideratio October 2024
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.6. 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.
2.7. 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.
Chown, et al. Expires 24 April 2025 [Page 6]
Internet-Draft IPv6 Address Accountability Consideratio October 2024
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: Lorenzo Colitti, Mark Smith, and James
Woodyatt.
References
Normative References
Chown, et al. Expires 24 April 2025 [Page 7]
Internet-Draft IPv6 Address Accountability Consideratio October 2024
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
addr-notification-13>.
[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, <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/rfc/rfc2131>.
[RFC4293] Routhier, S., Ed., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293,
April 2006, <https://www.rfc-editor.org/rfc/rfc4293>.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
DOI 10.17487/RFC4649, August 2006,
<https://www.rfc-editor.org/rfc/rfc4649>.
[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/rfc/rfc4862>.
[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,
<https://www.rfc-editor.org/rfc/rfc6620>.
[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,
<https://www.rfc-editor.org/rfc/rfc8191>.
[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey,
"Operational Security Considerations for IPv6 Networks",
RFC 9099, DOI 10.17487/RFC9099, August 2021,
<https://www.rfc-editor.org/rfc/rfc9099>.
Informative References
Chown, et al. Expires 24 April 2025 [Page 8]
Internet-Draft IPv6 Address Accountability Consideratio October 2024
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/rfc/rfc2663>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/rfc/rfc7593>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/rfc/rfc8273>.
[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,
<https://www.rfc-editor.org/rfc/rfc9663>.
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
Chown, et al. Expires 24 April 2025 [Page 9]