[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/