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]