Internet Engineering Task Force T. Taylor
Internet-Draft PT Taylor Consulting
Updates: 6733 (if approved) July 25, 2014
Intended status: Standards Track
Expires: January 26, 2015
The AddressOrPrefix Derived AVP Data Format For Diameter
draft-taylor-dime-addressorprefix-00
Abstract
Section 4.3.1 of the Diameter base specification [RFC6733] defines a
number of derived AVP data formats. This collection includes the
Address format, which is suitable for encoding complete addresses.
In some potential applications, however, there is a requirement to
encode a prefix rather than a complete address. This document
defines the AddressOrPrefix derived AVP data format, modelled after
the Address format defined in [RFC6733], but allowing the same AVP to
represent a prefix of any length up to a full address. This document
updates RFC 6733.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 26, 2015.
Copyright Notice
Copyright (c) 2014 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) in effect on the date of
publication of this document. Please review these documents
Taylor Expires January 26, 2015 [Page 1]
Internet-Draft AddressOrPrefix AVP Data Format July 2014
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Derived AVP Data Formats . . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. Normative References . . . . . . . . . . . . . . . . . . . . 3
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction
AVP data formats are used in Diameter [RFC6733] to specify AVP syntax
for non-grouped AVPs. Section 4.3.1 of [RFC6733] defines the Address
data format for the encoding of full addresses. However, no AVP data
format has been defined to encode prefixes, which are required in
some potential applications. This document defines the
AddressOrPrefix derived AVP data format, which is modelled on the
Address format but provides for a prefix length varying from zero to
a full address.
Section 4.3 of [RFC6733] introduces the topic of derived AVP data
formats, and provides direction for specifying additional such
formats. The present document conforms to the stated requirements.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Derived AVP Data Formats
This section defines a new derived AVP data format, AddressOrPrefix,
according to the rules given in Section 4.3 of [RFC6733].
AddressOrPrefix
The AddressOrPrefix data format is an extension of the Address
data format defined in Section 4.3.1 of [RFC6733]. Like the
Address data format, it is derived from the OctetString basic AVP
Taylor Expires January 26, 2015 [Page 2]
Internet-Draft AddressOrPrefix AVP Data Format July 2014
format. As well as an AddressType, it contains a PrefixLength
field. The detailed specification is as follows:
* As with the Address AVP, the first two octets represent the
AddressType, which contains an Address Family, defined in
[IANAADFAM].
* The next two octets are interpreted as a 16-bit unsigned
integer representing the PrefixLength. Valid values of
PrefixLength are from 0 to 32 for IPv4 and from 0 to 128 for
IPv6. The value 0 is included in each range to allow for
presentation of a "null prefix", the meaning of which MUST be
defined by applications that use AVPs based on the
AddressOrPrefix data format.
* The remaining octets present the prefix or address, most
significant octet first. If the prefix does not extend to an
octet boundary, the low-order bits of the final octet MUST be
padded with zeroes.
3. IANA Considerations
This memo contains no actions for IANA.
4. Security Considerations
The definition of the AddressOrPrefix AVP data format has no security
implications in itself. AVPs defined using this format may be
sensitive and require security anaqlysis.
5. Normative References
[IANAADFAM]
IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
Author's Address
Taylor Expires January 26, 2015 [Page 3]
Internet-Draft AddressOrPrefix AVP Data Format July 2014
Tom Taylor
PT Taylor Consulting
Ottawa
Canada
Email: tom.taylor.stds@gmail.com
Taylor Expires January 26, 2015 [Page 4]