Skip to main content

Accounting on Softwires

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Bruno Stevant , Laurent Toutain , Francis Dupont , David Binet
Last updated 2009-04-20
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


For access network operators, accounting information are crucial: they provide information for billing and give an overview of the traffic usage. This document defines the requirements for accounting information needed on Softwires.1. Motivation The Softwires WG is working on a solution to bring IPvX connectivity over an IPvY network [RFC4925]. This solution may be deployed and managed by access network operators to provide for example IPvX continuity of service. Operators should then consider the Softwires solution as an extension of their access network service. For operators, AAA [RFC2865] is the key feature for access network deployment: Authentication verifies user credentials, Authorization ensures access network integrity and Accounting provides information for billing and network management. Information from accounting usually includes measurements of in and out octets and packets [RFC2867]. As an alternative access network, the Softwires solution should provide similar AAA features. For instance accounting on the softwire should gives to the operator measurements of the traffic generated by the user using this access network. In a dual stack (IPvX and IPvY) network, the operator may want to manage information about the comparative usage of both protocols, for example for billing purpose. When the softwire is used to access IPvX over IPvY, accounting information will be specific to IPvX. Operators should be able to differentiate for which version of IP such information are relevant. This differentiation may become important if such operators offer a softwire solution for both IPvX over IPvY and IPvY over IPvX access networks.2. Study case In this section is given an example of IPv6 access over IPv4 network which is similar to the Hub-and-Spokes problem stated in the Softwires WG ([RFC4925]). The Point6box architecture uses L2TP [RFC2661] and PPP for IPv6 tunneling over IPv4 (see Figure 1). Radius manages AAA parameters for the access network created by the tunnel. On the server side, PPP sends to RADIUS accounting information measuring the traffic generated by the customer. /---------------------------\ CPEv6 | +--------------+ | DHCPv6 +-----+ | /....>| DHCPv6 relay |<........................>| P | | . +--------------+ | CPEv4 | o | | | . | L2TP IPv6 | | L2TP +-----+ | i | |-- X | . | server |=======================b=== n B | | | v +--------------+ | @@ @@ | r| | t o | | | +--------+ ^ | @ @@ @ | N i|-| 6 x | |-- Y | | DHCPv6 | | |--@ IPv4 @------| A d| +-----+ | | | server | | | @ @@ @ | T g| | | +--------+ | | @@ @@ PEv4 | e|----------| \-------------|-------------/ +-----+ RA-> |-- Z | PEv6 | +--------+ | clients | RADIUS | | RADIUS | server |<-/ +--------+ IPv4/v6 ISP Customer Figure 1: Point6Box Service Architecture3. Problem statement The accounting information defined for tunnels [RFC2867] includes attributes Acct-{Input,Output}-Octets and Acct-{Input,Output}-Packets for traffic measurements. These attributes do not depend of the version of IP used by the monitored traffic. Operators may not be able to differenciate IPv4 from IPv6 traffic in their accounting statistics. This non-differentiation even leads to mis-usages: In the current PPP implementation from BSD, the values of these attributes are only based on IPv4 statistics collected from IPCP protocol. No statistics are collected for IPv6 from IPV6CP. This proposal should decide which attributes may be candidate for IP- version differentiation. In operating system MIBs, values for in/out octets on a network interface are independent of the IP version. Having such values for each version may be usefull for monitoring and billing purpose. However the differentiation is done for in/out IPv4 and IPv6 packets on a network interface. Operators can extract from these values some hints about the usage of each version of the IP protocol but can not give quantitative report of bandwidth usage.


Bruno Stevant
Laurent Toutain
Francis Dupont
David Binet

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)