[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]