RFC 1672

RFC 1672: Accounting Requirements for IPng 💖

okay bestie, title block time 🎀 This one's from the Network Working Group and it's written by Nevil Brownlee of The University of Auckland 🎓. The category is Informational 📘, dated August 1994 📅. It doesn't list anything it obsoletes or updates 🙅‍♀️ So let's get into it ✨

---

Status of this Memo 📋

this bit is the vibe check 💅 This memo provides information for the Internet community. It does not specify an Internet standard of any kind, so it's not trying to be a standard lol 🙈 Distribution of this memo is unlimited 🌈

Abstract ✨

so this doc was submitted to the IETF IPng area in response to RFC 1550 📨 Publishing it doesn't mean the IPng area accepted any of the ideas in here 🫶 Comments should go to the big-internet@munnari.oz.au mailing list 💌

Summary 💜

this white paper is all about accounting requirements for IPng 💸 The big idea is that every IPng packet recommends carrying an accounting tag, and those tags come in different sizes 📏 In the simplest case a tag is just a voucher naming whoever is responsible for the packet 🧾 At other times, tags should also carry other higher-level accounting info ✨

Background 🧚

okay so the Internet Accounting Model (described in RFC 1272) spells out how accounting info is structured and collected for accounting applications 📊 It's super general, with accounting variables defined for the various layers of a protocol stack 🍰 The group has mostly focused on the lower layers so far, but the model can be extended simply by defining whatever variables are needed, 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 next 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 🎟️ That means it's an arbitrary string that identifies the party responsible for a packet, aka the one willing to pay for it 💳 It would first be set by the host that originates the packet, so at that stage the tag identifies the user who sent it 🙋‍♀️

the tag can be changed at various points along a packet's path 🛤️ This could happen as part of routing policy processing, so the tag reflects changes of the responsible party over each section of the path. For example:

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

accounting meters could use the tag to identify the party responsible for a traffic flow, without having to deduce it 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 want to tell a client about its usage of resources. A tag carrying this info could be read by meters at any point along the path for charging purposes, and the client could also use it to tell the user what charges they've incurred 💸

it would make collecting accounting data way simpler if this info was carried in a standard tag within each packet, instead of different protocols each providing this service in their own ways 🙄

for 'old' applications that are still unaware of the tag field, a meter could be placed at a gateway for the application's host 🚪 This 'gateway' meter could figure out what the application is by watching its streams of packets, then set an appropriate value in their tag fields 🕵️‍♀️

Structure of the accounting tag 🎀

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

for the application variables, a separate tag seems sensible 🧩 It would simply contain a list of the variables. Having two tags this way keeps the management of routers and meters separate 🧚

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

the fine detail of this, or at least the way variables are packed into the tags, could be standardised by the Accounting Working Group in due course 📝 For IPng, all that is required is the ability to carry one or two variable-size objects in every packet ✨

References 📚

[1] Carpenter, B., "IPng White Paper on Transition and Other Considerations", RFC 1671, CERN, August 1994.

---

Security Considerations 🔐

🚨 bestie this one is SERIOUS. For IPng to provide reliable transport in a hostile environment, routing and accounting information, i.e., the (source, dest, network-tag) and (application-tag) tuples, must be tamper-proof 🛡️ Routers and meters that need to use the tuples will need to hold appropriate keys for them 🗝️ Network operators will have to plan for this, for example by determining which routers need which sets of keys 📋 This will be necessary in any case for reliable policy-based routing, so the extra work required to set up accounting meters should be acceptable 💅

Author's Address 📮

Nevil Brownlee 🦋

Deputy Director 💼

Computer Centre, The University of Auckland 🏫

Private Bag 92019, Auckland, New Zealand 🌏

Phone: +64 9 373 7599 📞

Fax: +64 9 373 7425 📠

EMail: n.brownlee@auckland.ac.nz 💌