idnits 2.17.1 draft-taylor-dime-addressorprefix-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6733]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6733, updated by this document, for RFC5378 checks: 2006-12-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 25, 2014) is 3553 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAADFAM' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Taylor 3 Internet-Draft PT Taylor Consulting 4 Updates: 6733 (if approved) July 25, 2014 5 Intended status: Standards Track 6 Expires: January 26, 2015 8 The AddressOrPrefix Derived AVP Data Format For Diameter 9 draft-taylor-dime-addressorprefix-00 11 Abstract 13 Section 4.3.1 of the Diameter base specification [RFC6733] defines a 14 number of derived AVP data formats. This collection includes the 15 Address format, which is suitable for encoding complete addresses. 16 In some potential applications, however, there is a requirement to 17 encode a prefix rather than a complete address. This document 18 defines the AddressOrPrefix derived AVP data format, modelled after 19 the Address format defined in [RFC6733], but allowing the same AVP to 20 represent a prefix of any length up to a full address. This document 21 updates RFC 6733. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 26, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 59 2. Derived AVP Data Formats . . . . . . . . . . . . . . . . . . 2 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 62 5. Normative References . . . . . . . . . . . . . . . . . . . . 3 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1. Introduction 67 AVP data formats are used in Diameter [RFC6733] to specify AVP syntax 68 for non-grouped AVPs. Section 4.3.1 of [RFC6733] defines the Address 69 data format for the encoding of full addresses. However, no AVP data 70 format has been defined to encode prefixes, which are required in 71 some potential applications. This document defines the 72 AddressOrPrefix derived AVP data format, which is modelled on the 73 Address format but provides for a prefix length varying from zero to 74 a full address. 76 Section 4.3 of [RFC6733] introduces the topic of derived AVP data 77 formats, and provides direction for specifying additional such 78 formats. The present document conforms to the stated requirements. 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Derived AVP Data Formats 88 This section defines a new derived AVP data format, AddressOrPrefix, 89 according to the rules given in Section 4.3 of [RFC6733]. 91 AddressOrPrefix 93 The AddressOrPrefix data format is an extension of the Address 94 data format defined in Section 4.3.1 of [RFC6733]. Like the 95 Address data format, it is derived from the OctetString basic AVP 96 format. As well as an AddressType, it contains a PrefixLength 97 field. The detailed specification is as follows: 99 * As with the Address AVP, the first two octets represent the 100 AddressType, which contains an Address Family, defined in 101 [IANAADFAM]. 103 * The next two octets are interpreted as a 16-bit unsigned 104 integer representing the PrefixLength. Valid values of 105 PrefixLength are from 0 to 32 for IPv4 and from 0 to 128 for 106 IPv6. The value 0 is included in each range to allow for 107 presentation of a "null prefix", the meaning of which MUST be 108 defined by applications that use AVPs based on the 109 AddressOrPrefix data format. 111 * The remaining octets present the prefix or address, most 112 significant octet first. If the prefix does not extend to an 113 octet boundary, the low-order bits of the final octet MUST be 114 padded with zeroes. 116 3. IANA Considerations 118 This memo contains no actions for IANA. 120 4. Security Considerations 122 The definition of the AddressOrPrefix AVP data format has no security 123 implications in itself. AVPs defined using this format may be 124 sensitive and require security anaqlysis. 126 5. Normative References 128 [IANAADFAM] 129 IANA, "Address Family Numbers", 130 . 132 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 133 Requirement Levels", BCP 14, RFC 2119, March 1997. 135 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 136 "Diameter Base Protocol", RFC 6733, October 2012. 138 Author's Address 139 Tom Taylor 140 PT Taylor Consulting 141 Ottawa 142 Canada 144 Email: tom.taylor.stds@gmail.com