Network Working Group B. Stevant Internet-Draft L. Toutain Intended status: Standards Track Telecom Bretagne Expires: October 22, 2009 F. Dupont ISC D. Binet FT R&D April 20, 2009 Accounting on Softwires draft-stevant-softwire-accounting-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 22, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Stevant, et al. Expires October 22, 2009 [Page 1] Internet-Draft Accounting on Softwires April 2009 Abstract 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. Stevant, et al. Expires October 22, 2009 [Page 2] Internet-Draft Accounting on Softwires April 2009 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. Stevant, et al. Expires October 22, 2009 [Page 3] Internet-Draft Accounting on Softwires April 2009 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 Architecture Stevant, et al. Expires October 22, 2009 [Page 4] Internet-Draft Accounting on Softwires April 2009 3. 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. Stevant, et al. Expires October 22, 2009 [Page 5] Internet-Draft Accounting on Softwires April 2009 4. Proposed solutions 4.1. Summing accounting informations In the Point6Box solution, the PPP negociation only initiates the IPV6CP protocol on the tunnel. The PPP statistics handling requires some modifications to get IPv6-specific accounting information in Radius attributes. A minor modification of the code may consist in filling the RADIUS attributes with the sum of both IPCP and IPV6CP values. But still no differentiation is made on the version of IP used. Such solution do not match the requirements stated before. 4.2. Differentiation based on context A RADIUS accounting entry, as defined in [RFC2867] and updated by [RFC3162], also includes the NAS-IP-Address and NAS-IPv6-Address attributes, which gives the IP address of the NAS used as the softwire endpoint. Based on this information, an operator can decide if this softwire is based on IPv4 or IPv6. In the case of provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires, the nature of the traffic reported in the accounting information depends of which attribute between NAS-IP-Address and NAS-IPv6-Address is set. If NAS-IP-Address is set in the accounting entry, accounted traffic is IPv6. If NAS-IPv6-Address is set in the accounting entry, accounted traffic is IPv4. However, this solution requires extra checking when building accounting report and obviously does not work in case of IPvX over IPvX softwires. 4.3. Differentiation based on Attributes Another solution is to have separate accounting attributes for IPv4 and IPv6. The accounting information should then be provided depending on the softwire access: o IPv4-only access: Only IPv4 accounting values are provided. IPv6 accounting values should be filled as null, o IPv6-only access: Only IPv6 accounting values are provided. IPv4 accounting values should be filled as null, o Dual stack IPv4 and IPv6 access: Values for both protocols should be provided. Stevant, et al. Expires October 22, 2009 [Page 6] Internet-Draft Accounting on Softwires April 2009 5. Security Considerations The Point6Box approach and the proposed extension of RADIUS only use already existing protocols and add supplementary attributes. No new security issue should be introduced. Stevant, et al. Expires October 22, 2009 [Page 7] Internet-Draft Accounting on Softwires April 2009 6. Normative References [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. Stevant, et al. Expires October 22, 2009 [Page 8] Internet-Draft Accounting on Softwires April 2009 Appendix A. Revision History Changes between -01 and -02: o Fix section "Differentiation based on context" by introducing NAS- IPv6-Address from RFC3162. Thanks to D.Romascanu for pointing that during the review of the Softwires Hub-and-spoke framework document. o Update some authors new employers Changes between -00 and -01: o Add new solution in Section 4.2. o Moved paragraph about system MIBs in Section 3. Stevant, et al. Expires October 22, 2009 [Page 9] Internet-Draft Accounting on Softwires April 2009 Authors' Addresses Bruno Stevant Telecom Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Bruno.Stevant@telecom-bretagne.eu Laurent Toutain Telecom Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@telecom-bretagne.eu Francis Dupont ISC Email: Francis.Dupont@fdupont.fr David Binet FT R&D Email: David.Binet@francetelecom.com Stevant, et al. Expires October 22, 2009 [Page 10]