One document matched: draft-stevant-softwire-accounting-01.txt
Differences from draft-stevant-softwire-accounting-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:22:18 |