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]