RFC 5872

RFC 5872: IANA Rules for PANA 🦋

Okay bestie, let's get into RFC 5872 ✨ It's a Standards Track doc (ISSN 2070-1721) from May 2010, and it's all about IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA) 🎀 The authors are J. Arkko (Ericsson) and A. Yegin (Samsung). It updates RFC 5191, and the header doesn't list anything it obsoletes. Lowkey a short, sweet little update, but it changes the rules for a bunch of PANA stuff 💅

Abstract

This doc relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA). Slay 🫶

Status of This Memo

This is an Internet Standards Track document. 🌸

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further info on Internet Standards is in Section 2 of RFC 5741 📚

Info about the current status of this document, any errata, and how to send feedback on it can be found at http://www.rfc-editor.org/info/rfc5872 🔗

Copyright Notice

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧚

---

1. Introduction ✨

This doc relaxes the IANA rules for PANA [RFC5191]. These protocol fields, all defined in [RFC5191], are affected:

• Message Types
• Message Flags
• Attribute-Value Pair (AVP) Flags
• Result-Code AVP Values
• Termination-Cause AVP Values

So why change anything? 🤔 There can be situations where it makes sense to hand out an allocation under special circumstances. At the time of writing, the IETF is in the middle of approving one such allocation. By adding IESG Approval [RFC5226] to the current IANA rules, the Internet Engineering Steering Group (IESG) can now consider an allocation request even if it doesn't meet the default rule. For example, an experimental protocol extension could maybe deserve an allocation from a field of reserved bits, as long as enough bits are still left for other purposes, and the PANA community is happy with that allocation 🌈

2. IANA Considerations 💅

IANA has updated the registries for PANA Message Types, Message Flags, AVP Flags, Result-Code AVP Values, and Termination-Cause AVP Values, as laid out below. All other PANA IANA registries stay exactly the same 🎀

2.1. Message Types

The Message Types namespace is used to identify PANA messages. Value 0 is not used and is not assigned by IANA. The range 1 - 65,519 is for permanent, standard Message Types, allocated by IETF Review or IESG Approval [RFC5226]. Before this, the rule for this range was IETF Review only. [RFC5191] defined the range 1 - 4. The same Message Type is used for both the request and the answer messages, except for type 1. The Request bit tells requests apart from answers 🍓

The range 65,520 - 65,535 (hexadecimal values 0xfff0 - 0xffff) is reserved for experimental messages. These codes are only for experimental and testing purposes, so no guarantee is made for interoperability between the communicating PANA Client (PaC) and PANA Authentication Agent (PAA) using experimental commands, as outlined in [RFC3692]. Bestie, read that one twice 🙈

2.2. Message Flags

There are 16 bits in the Flags field of the PANA message header. Section 6.2 of [RFC5191] assigned bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A'), 4 ('P'), and 5 ('I'). Allocations from the remaining free bits in the PANA header Flag field are made via Standards Action or IESG Approval [RFC5226]. Before, the rule for these bits was Standards Action only 🦋

2.3. AVP Flags

There are 16 bits in the AVP Flags field of the AVP header, defined in Section 6.3 of [RFC5191]. That RFC also assigned bit 0 ('V'). The remaining bits are assigned via Standards Action or IESG Approval [RFC5226]. Before, the rule for these bits was Standards Action only 💜

2.4. Result-Code AVP Values

As defined in Section 8.7 of [RFC5191], the Result-Code AVP (AVP Code 7) defines the values 0 - 2 🔥

All remaining values are available for assignment via IETF Review or IESG Approval [RFC5226]. Before, the rule for these values was IETF Review only.

2.5. Termination-Cause AVP Values

As defined in Section 8.9 of [RFC5191], the Termination-Cause AVP (AVP Code 9) defines the values 1, 4, and 8 ⭐

All remaining values are available for assignment via IETF Review or IESG Approval [RFC5226]. Before, the rule for these values was IETF Review only.

3. Security Considerations 🚨

Okay, this part is serious bestie. Please actually read it 😭

This spec does not change the security properties of PANA.

BUT, a few words are needed about using the experimental code points defined in Section 2.1. Potentially harmful side effects from experimental values need to be carefully evaluated before deploying any experiment across networks that the owner of the experiment does not fully control. The guidance in [RFC3692] about experimental values needs to be followed. Non-negotiable 💀

4. References 📚

4.1. Normative References

• [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
• [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

4.2. Informative References

• [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. 🧚

Appendix A. Changes from RFC 5191 🎀

This doc changes the IANA rules for Message Types, Message Flags, AVP Flags, Result-Code AVP Values, and Termination-Cause AVP Values. That's the whole glow-up 💖

Appendix B. Acknowledgments 🫶

The authors would like to thank Yoshihiro Ohba, Ralph Droms, Magnus Westerlund, and Alfred Hoenes for their reviews and comments on this topic. Iconic group project energy 👑

Authors' Addresses

Jari Arkko Ericsson Jorvas 02420 Finland

EMail: jari.arkko@piuha.net

Alper Yegin Samsung Istanbul Turkey

EMail: alper.yegin@yegin.org