[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

IPv6 Operations                                                 T. Chown
Internet-Draft                                 University of Southampton
Intended status: Informational                             July 12, 2011
Expires: January 13, 2012


               IPv6 Address Accountability Considerations
              draft-chown-v6ops-address-accountability-01

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 addresses, 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.

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 http://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 January 13, 2012.

Copyright Notice

   Copyright (c) 2011 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
   (http://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



Chown                   Expires January 13, 2012                [Page 1]


Internet-Draft         IPv6 Address Accountability             July 2011


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Accountability Approaches . . . . . . . . . . . . . . . . . . . 3
     2.1.  Switch-router polling . . . . . . . . . . . . . . . . . . . 3
     2.2.  Record all ND traffic . . . . . . . . . . . . . . . . . . . 4
     2.3.  Force use of DHCPv6 only  . . . . . . . . . . . . . . . . . 4
     2.4.  Use SAVI mechanisms . . . . . . . . . . . . . . . . . . . . 4
   3.  Privacy Considerations  . . . . . . . . . . . . . . . . . . . . 4
   4.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Informative References  . . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6






























Chown                   Expires January 13, 2012                [Page 2]


Internet-Draft         IPv6 Address Accountability             July 2011


1.  Introduction

   Administrators of IPv4 networks are used to an address accountability
   model where devices acquire a single global address using DHCP and
   then use that address while the DHCP lease is valid.  The 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.

   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 user managed.

   In IPv6 networks, where hosts may use SLAAC [RFC4862] and Privacy
   Addresses [RFC4941], 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.

   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.  Thus
   picking an unused IP address becomes as simple as picking an unused
   Layer 2 address.  Continuing that comparison, some virtualised OSes
   may pick randomly generated link layer addresses, and may change
   these upon virtual host reboot.


2.  Accountability Approaches

   There are various approaches to address accountability, which have
   different costs, benefits and trade-offs.

2.1.  Switch-router polling

   By polling network switch and router devices for IPv4 ARP tables and
   IPv6 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).



Chown                   Expires January 13, 2012                [Page 3]


Internet-Draft         IPv6 Address Accountability             July 2011


   This is the approach adopted by tools such as NAV and Netdot, but
   there is some concern expressed at the load that may be placed on
   devices by frequent 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.

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 or NDPmon, or a reporting mechanism for
   the subnet router.  There may also be mechanisms such as a (filtered)
   RSPAN that may be suitable; at least one implementation of this has
   been published.

   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.

2.3.  Force use of DHCPv6 only

   One approach to accountability is to attempt to force devices to only
   use DHCPv6, which would in principle give the same address
   accountability model as exists 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 ('M' bit 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 Preifx Information
   option should be ignored.  A user running the device will need to
   determine the on-link prefix if they wish to manually configure their
   own address.

2.4.  Use SAVI mechanisms

   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



Chown                   Expires January 13, 2012                [Page 4]


Internet-Draft         IPv6 Address Accountability             July 2011


   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 (mainly) UK academic 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 4941, gives the
   greatest benefit when the addresses are being observed by external
   third parties.


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

   There are no extra IANA consideration for this document.


7.  Acknowledgments

   The author would like to thank the following people for comments on
   this text: Mark Smith, and James Woodyatt.







Chown                   Expires January 13, 2012                [Page 5]


Internet-Draft         IPv6 Address Accountability             July 2011


8.  Informative References

   [RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
              August 2006.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.


Author's Address

   Tim Chown
   University of Southampton
   Highfield
   Southampton, Hampshire  SO17 1BJ
   United Kingdom

   Email: tjc@ecs.soton.ac.uk




























Chown                   Expires January 13, 2012                [Page 6]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/