Network Working Group B. Stevant Internet-Draft L. Toutain Intended status: Informational GET/ENST Bretagne Expires: April 14, 2007 F. Dupont CELAR D. Binet FT R&D October 11, 2006 Accounting on Softwires draft-stevant-softwire-accounting-01.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 April 14, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Stevant, et al. Expires April 14, 2007 [Page 1] Internet-Draft Accounting on Softwires October 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 April 14, 2007 [Page 2] Internet-Draft Accounting on Softwires October 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 [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 April 14, 2007 [Page 3] Internet-Draft Accounting on Softwires October 2006 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 ([ID.problemstatement]). 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 April 14, 2007 [Page 4] Internet-Draft Accounting on Softwires October 2006 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 April 14, 2007 [Page 5] Internet-Draft Accounting on Softwires October 2006 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], also includes the NASIPAddress attribute, 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 the address family of NASIPAddress (if NASIPAddress is IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, 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 April 14, 2007 [Page 6] Internet-Draft Accounting on Softwires October 2006 5. 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. Stevant, et al. Expires April 14, 2007 [Page 7] Internet-Draft Accounting on Softwires October 2006 6. References 6.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. 6.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 April 14, 2007 [Page 8] Internet-Draft Accounting on Softwires October 2006 Appendix A. Revision History 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 April 14, 2007 [Page 9] Internet-Draft Accounting on Softwires October 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@fdupont.fr David Binet FT R&D Email: David.Binet@francetelecom.com Stevant, et al. Expires April 14, 2007 [Page 10] Internet-Draft Accounting on Softwires October 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stevant, et al. Expires April 14, 2007 [Page 11]