Network Working Group B. Stevant Internet-Draft L. Toutain Expires: August 14, 2006 GET/ENST Bretagne F. Dupont CELAR D. Binet FT R&D February 10, 2006 Accounting on Softwires draft-stevant-softwire-accounting-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 August 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 August 14, 2006 [Page 1] Internet-Draft Accounting on Softwires February 2006 1. Motivation The Softwires WG is working on a solution to bring IPvX connectivity over an IPvY network [ID.problemstatement]. 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 (ref radius-accounting). 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 comparative usage 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 discern for which version of IP such information are relevant. This differentiation may become important if such operator offers 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 (ref draft-problem-statement). 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. Stevant, et al. Expires August 14, 2006 [Page 2] Internet-Draft Accounting on Softwires February 2006 /---------------------------\ CPEv6 | +--------------+ | DHVPv6 +-----+ | /....>| 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: Service Architecture 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. 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. 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, Stevant, et al. Expires August 14, 2006 [Page 3] Internet-Draft Accounting on Softwires February 2006 o Dual stack IPv4 and IPv6 access: Values for both protocols should be provided. 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 statistics about the usage of each version of the IP protocol. 3. Security Considerations The Point6Box approach and the proposed extension of RADIUS only use already existing protocols and add supplementary attributes. No new security should be introduced. 4. References 4.1. 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 2866, June 2000. 4.2. Informative References [ID.problemstatement] Li, X., Durand, A., Miyakawa, S., Palet, J., Parent, F., and D. Ward, "Softwire Problem Statement", draft-ietf-softwire-problem-statement-00.txt (work in progress), December 2005. Stevant, et al. Expires August 14, 2006 [Page 4] Internet-Draft Accounting on Softwires February 2006 Authors' Addresses Bruno Stevant GET/ENST Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: Bruno.Stevant@enst-bretagne.fr Laurent Toutain GET/ENST Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: Laurent.Toutain@enst-bretagne.fr Francis Dupont CELAR Email: Francis.Dupont@point6.net David Binet FT R&D Email: David.Binet@francetelecom.com Stevant, et al. Expires August 14, 2006 [Page 5] Internet-Draft Accounting on Softwires February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Stevant, et al. Expires August 14, 2006 [Page 6]