Accounting Requirements for IPng
RFC 1672

Document Type RFC - Informational (August 1994; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1672 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        N. Brownlee
Request for Comments: 1672                    The University of Auckland
Category: Informational                                      August 1994

                    Accounting Requirements for IPng

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.


   This document was submitted to the IETF IPng area in response to RFC
   1550.  Publication of this document does not imply acceptance by the
   IPng area of any ideas expressed within.  Comments should be
   submitted to the mailing list.


   This white paper discusses accounting requirements for IPng. It
   recommends that all IPng packets carry accounting tags, which would
   vary in size. In the simplest case a tag would simply be a voucher
   identifying the party responsible for the packet. At other times tags
   should also carry other higher-level accounting information.


   The Internet Accounting Model - described in RFC 1272 - specifies how
   accounting information is structured, and how it is collected for use
   by accounting aplications.  The model is very general, with
   accounting variables being defined for various layers of a protocol
   stack.  The group's work has so far concentrated on the lower layers,
   but the model can be extended simply by defining the variables
   required, e.g., for session and application layers.

   Brian Carpenter [1] suggests that IPng packets should carry
   authenticated (source, destination, transaction) triplets, which
   could be used for policy-based routing and accounting. The following
   sections explain how the transaction field - hereafter called an
   'accounting tag' - could be used.

Lower-layer (Transport) Accounting

   At the lower (network) layers the tag would simply be a voucher. This
   means it is an arbitrary string which identifies the party

Brownlee                                                        [Page 1]
RFC 1672            Accounting Requirements for IPng         August 1994

   responsible, i.e., willing to pay for, a packet. It would initially
   be set by the host which originates the packet, hence at that stage
   the tag would identify the user who sent it.

   A tag could be changed at various points along a packet's path. This
   could be done as part of the routing policy processing so as to
   reflect changes of the party responsible over each section of the
   path. For example:

        user - provider           tag identifies user
        provider A - provider B   tag identifies provider A

   The tag could be used by accounting meters to identify the party
   responsible for a traffic flow, without having to deduce this using
   tables of rules. This should considerably simplify accounting for
   transit traffic across intermediate networks.

Higher-layer (Session and Application) Accounting

   At higher layers there is a clear need to measure accounting
   variables and communicate them to various points along a packet's
   path, for example an application server may wish to inform a client
   about its usage of resources. A tag containing this information could
   be read by meters at any point along the packet's path for charging
   purposes, and could also be used by the client to inform the user of
   charges incurred.

   It would make the collection of accounting data much simpler if this
   information was carried in a standard tag within each packet, rather
   than having different protocols provide this service in differing

   For 'old' applications which remain unaware of the tag field, a meter
   could be placed at a gateway for the application's host. This
   'gateway' meter could determine what the application is by watching
   its streams of packets, then set an appropriate value in thir tag

Structure of the accounting tag

   The two uses of tags outlined above must be able to coexist. Since
   many - indeed most - of the packets will only carry a voucher, it
   seems simplest to keep this as part of the routing tuple (see below).

   For the application variables, a separate tag seems sensible. This
   would simply contain a list of the variables.  Having two tags in
   this way would keep separate the management of routers and meters.

Brownlee                                                        [Page 2]
RFC 1672            Accounting Requirements for IPng         August 1994

   If the encryption/digital signature overhead of the second tag proves
   to be too high, it should be possible to combine this with the

   The fine detail of this, or at least the way variables are packed
Show full document text