doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc7839.txt b/doc/rfc/rfc7839.txt
new file mode 100644
index 0000000..f4b76c5
--- /dev/null
+++ b/doc/rfc/rfc7839.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       S. Bhandari
+Request for Comments: 7839                                 S. Gundavelli
+Category: Standards Track                                     M. Grayson
+ISSN: 2070-1721                                                  B. Volz
+                                                           Cisco Systems
+                                                             J. Korhonen
+                                                        Broadcom Limited
+                                                               June 2016
+
+
+                Access-Network-Identifier Option in DHCP
+
+Abstract
+
+   This document specifies the format and mechanism that is to be used
+   for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages
+   by defining new Access-Network-Identifier options and sub-options.
+
+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 information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7839.
+
+Copyright Notice
+
+   Copyright (c) 2016 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
+   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.
+
+
+
+
+
+Bhandari, et al.             Standards Track                    [Page 1]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  DHCPv4 Access-Network-Identifier Option . . . . . . . . . . .   5
+     4.1.  DHCPv4 Access-Network-Identifier Sub-options  . . . . . .   5
+     4.2.  DHCPv4 Access-Technology-Type Sub-option  . . . . . . . .   6
+     4.3.  DHCPv4 Network-Identifier Sub-options . . . . . . . . . .   7
+       4.3.1.  DHCPv4 Network-Name Sub-option  . . . . . . . . . . .   7
+       4.3.2.  DHCPv4 Access-Point-Name Sub-option . . . . . . . . .   8
+       4.3.3.  DHCPv4 Access-Point-BSSID Sub-option  . . . . . . . .   9
+     4.4.  DHCPv4 Operator-Identifier Sub-options  . . . . . . . . .   9
+       4.4.1.  DHCPv4 Operator-Identifier Sub-option . . . . . . . .   9
+       4.4.2.  DHCPv4 Operator-Realm Sub-option  . . . . . . . . . .  10
+   5.  DHCPv6 Access-Network-Identifier Options  . . . . . . . . . .  10
+     5.1.  DHCPv6 Access-Technology-Type Option  . . . . . . . . . .  11
+     5.2.  DHCPv6 Network-Identifier Options . . . . . . . . . . . .  11
+       5.2.1.  DHCPv6 Network-Name Option  . . . . . . . . . . . . .  12
+       5.2.2.  DHCPv6 Access-Point-Name Option . . . . . . . . . . .  12
+       5.2.3.  DHCPv6 Access-Point-BSSID Option  . . . . . . . . . .  13
+     5.3.  DHCPv6 Operator-Identifier Options  . . . . . . . . . . .  13
+       5.3.1.  DHCPv6 Operator-Identifier Option . . . . . . . . . .  13
+       5.3.2.  DHCPv6 Operator-Realm Option  . . . . . . . . . . . .  14
+   6.  Relay Agent Behavior  . . . . . . . . . . . . . . . . . . . .  14
+   7.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .  15
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  18
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  18
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                    [Page 2]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+1.  Introduction
+
+   Access-network identification of a network device has a range of
+   applications.  For example, the Local Mobility Anchor (LMA) in a
+   Proxy Mobile IPv6 (PMIPv6) domain is able to provide service
+   treatment for the mobile node's traffic based on the access network
+   to which the mobile node is attached.
+
+   This document specifies the Dynamic Host Configuration Protocol for
+   IPv4 (DHCPv4) [RFC2131] and the Dynamic Host Configuration Protocol
+   for IPv6 (DHCPv6) [RFC3315] options for access-network identification
+   that is added by the relay agent in the DHCPv4 or DHCPv6 messages
+   sent towards the server.  The scope of applicability for this option
+   is between a DHCP relay agent and a mobile access gateway where the
+   same operator typically operates both these functions
+
+   A DHCP relay agent that is aware of the access network and access
+   operator adds this information in the DHCP messages.  This
+   information can be used to provide differentiated services and
+   policing of traffic based on the access network to which a client is
+   attached.  Examples of how this information can be used in mobile
+   networks can be found in [RFC6757].
+
+2.  Motivation
+
+   PMIPv6 [RFC5213] can be used for supporting network-based mobility
+   management in various types of network deployments.  The network
+   architectures, such as service provider Wi-Fi access aggregation or
+   WLAN integrated mobile packet core, are examples where PMIPv6 is a
+   component of the overall architecture.  Some of these architectures
+   require the ability of the LMA [RFC5213] to provide differentiated
+   services and policing of traffic to the mobile nodes based on the
+   access network to which they are attached.  Policy systems in
+   mobility architectures, such as Policy and Charging Control (PCC)
+   [TS23203] and Access Network Discovery and Selection Function (ANDSF)
+   [TS23402] in the 3GPP system, allow configuration of policy rules
+   with conditions based on the access-network information.  For
+   example, the service treatment for the mobile node's traffic may be
+   different when they are attached to an access network owned by the
+   home operator than when owned by a roaming partner.  In the case of
+   access networks based on IEEE 802.11, the service treatment can also
+   be different based on the configured Service Set Identifiers (SSIDs).
+   Other examples of services include the operator's ability to apply
+   tariff based on the location.
+
+   The PMIPv6 extension as specified in [RFC6757] defines PMIPv6 options
+   to carry Access-Network Identifiers in PMIPv6 signaling from the
+   Mobile Access Gateway (MAG) to the LMA.  The MAG can learn this
+
+
+
+Bhandari, et al.             Standards Track                    [Page 3]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+   information from the DHCP options as inserted by the DHCP relay agent
+   in the access network.  If the MAG relays the DHCP messages to the
+   LMA as specified in [RFC5844], this information can be inserted by
+   the MAG towards the LMA in the forwarded DHCP messages.
+
+   Figure 1 illustrates an example of PMIPv6 deployment.  In this
+   example, the access network is based on IEEE 802.11 technology, the
+   DHCP relay agent function is located on the Access Point (AP), and
+   the DHCP server function is located on the MAG.  The MAG delivers the
+   information elements related to the access network to the LMA over
+   PMIPv6 signaling messages.  The MAG obtains these information
+   elements from the DHCP relay agent as per this specification.  The
+   information elements related to the access network include the SSID
+   of the used IEEE 802.11 network, the geo-location of the access
+   network to which the mobile node is attached, and the identity of the
+   operator running the IEEE 802.11 access-network infrastructure.
+
+          SSID: IETF-1
+          Operator-Identifier: provider1.example
+
+          +--+
+          |AP|-----------.                    {Access-Specific Policies)
+          +--+           | (DHCP Server)   _-----_             |
+          (DHCP Relay) +-----+           _(       )_        +-----+
+                       | MAG |-=========(   PMIPv6  )======-| LMA |-
+                       +-----+           (_ Tunnel_)        +-----+
+          +--+           |                 '-----'
+          |AP|-----------'
+          +--+
+          (DHCP Relay)
+
+          SSID: IETF-2
+          Operator-Identifier: provider2.example
+
+                      Access Networks Attached to MAG
+
+3.  Terminology
+
+   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].
+
+   All the DHCP-related terms used in this document are to be
+   interpreted as defined in DHCPv4 [RFC2131] and DHCPv6 [RFC3315]
+   specifications.  "DHCP message" refers to both DHCPv4 and DHCPv6
+   messages throughout this document.
+
+
+
+
+
+Bhandari, et al.             Standards Track                    [Page 4]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+   All the mobility-related terms used in this document are to be
+   interpreted as defined in the PMIPv6 specifications [RFC5213] and
+   [RFC5844].  Additionally, this document uses the following
+   abbreviations:
+
+   Service Set Identifier (SSID)
+
+      The Service Set Identifier (SSID) identifies the name of the IEEE
+      802.11 network.  The SSID differentiates from one network to the
+      other.
+
+   Operator-Identifier
+
+      The Operator-Identifier is the Structure of Management Information
+      (SMI) Network Management Private Enterprise Code of the IANA-
+      maintained "Private Enterprise Numbers" registry [SMI].  It
+      identifies the operator running the access network where the
+      client is attached.
+
+4.  DHCPv4 Access-Network-Identifier Option
+
+   The Access-Network Identifier (ANI) carries information related to
+   the identity of the access network to which the client is attached.
+   This information includes access-technology type, network identifier,
+   and access network operator identifiers.
+
+   Relay agents that include ANI information include one or more sub-
+   options (see Section 4.1) in the Relay Agent Information option
+   [RFC3046].
+
+4.1.  DHCPv4 Access-Network-Identifier Sub-options
+
+   The Access-Network-Identifier information will be defined in multiple
+   sub-options allocated from the "DHCP Relay Agent Sub-Option Codes"
+   registry.
+
+   ANI Sub-options: The ANI sub-options consist of a sequence of Sub-
+   Option Code, Length, and Value tuples for each sub-option, encoded in
+   the following manner:
+
+       Subopt  Len     Sub-option Data
+      +------+------+------+------+------+------+--...-+------+
+      | code |   N  |  s1  |  s2  |  s3  |  s4  |      |  sN  |
+      +------+------+------+------+------+------+--...-+------+
+
+   Subopt code
+      The 1-octet code for the sub-options defined in the following
+      sections.
+
+
+
+Bhandari, et al.             Standards Track                    [Page 5]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+   Len
+      An unsigned 8-bit integer giving the length of the Sub-option Data
+      field in this sub-option in octets.
+
+   Sub-option Data (s1 to sN)
+      The data area for the sub-option.
+
+   The initial assignment of the DHCP Access-Network-Identifier sub-
+   options is as follows:
+
+      +=================+=======================================+
+      | SUB-OPTION CODE |      SUB-OPTION DESCRIPTION           |
+      +=================+=======================================+
+      |       13        | Access-Technology-Type Sub-option     |
+      +=========================================================+
+      |       14        | Access-Network-Name Sub-option        |
+      +=========================================================+
+      |       15        | Access-Point-Name Sub-option          |
+      +=========================================================+
+      |       16        | Access-Point-BSSID Sub-option         |
+      +=========================================================+
+      |       17        | Operator-Identifier Sub-option        |
+      +=========================================================+
+      |       18        | Operator-Realm Sub-option             |
+      +=========================================================+
+
+4.2.  DHCPv4 Access-Technology-Type Sub-option
+
+   This sub-option is used for exchanging the type of the access
+   technology of the network to which the client is attached.  Its
+   format is as follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Subopt Code  |     Length    |   Reserved    |      ATT      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Subopt Code
+      13
+
+   Length
+      2
+
+   Reserved
+      An 8-bit field that is unused for now.  The value MUST be
+      initialized to 0 by the sender and MUST be ignored by the
+      receiver.
+
+
+
+Bhandari, et al.             Standards Track                    [Page 6]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+   Access-Technology-Type (ATT)
+      An 8-bit field that specifies the access technology through which
+      the client is connected to the access link from the IANA name
+      space "Access Technology Type Option type values" registry defined
+      in [RFC5213].
+
+4.3.  DHCPv4 Network-Identifier Sub-options
+
+   These sub-options are used for carrying the name of the access
+   network (e.g., an SSID in the case of an IEEE 802.11 access network
+   or a Public Land-based Mobile Network (PLMN) Identifier [TS23003] in
+   the case of a 3GPP access network) and the Access-Point Name to which
+   the client is attached.  The format of these sub-options is defined
+   in the following sections.  The Network-Identifier sub-options are
+   only for the currently known access-technology types.
+
+4.3.1.  DHCPv4 Network-Name Sub-option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Subopt Code  |     Length    |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+      .                                                               .
+      .                     Network-Name (e.g., SSID or PLMNID)       .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Subopt Code
+      14
+
+   Length
+      The length of the Network-Name field.
+
+   Network-Name
+      The name of the access network to which the mobile node is
+      attached.  The encoding MUST be UTF-8 as described in [RFC3629].
+
+      The type of the Network-Name is dependent on the access technology
+      to which the mobile node is attached.  For networks based on IEEE
+      802.11, the Network-Name will be the SSID of the network.  For
+      3GPP access-based networks, it is the PLMN Identifier of the
+      access network, and for 3GPP2 access, the Network-Name is the ANI
+      [ANI].
+
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                    [Page 7]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+      When encoding the PLMN Identifier, both the Mobile Network Code
+      (MNC) [TS23003] and Mobile Country Code (MCC) [TS23003] MUST be
+      three digits.  If the MNC in use only has two digits, then it MUST
+      be preceded with a '0'.
+
+4.3.2.  DHCPv4 Access-Point-Name Sub-option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Subopt Code  |     Length    |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+      .                                                               .
+      .                        Access-Point-Name                      .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Subopt Code
+      15
+
+   Length
+      The length of the Access-Point-Name field.
+
+   Access-Point-Name
+      The name of the access point (physical device name) to which the
+      mobile node is attached.  This is the identifier that uniquely
+      identifies the access point.  While the Network-Name (e.g., SSID)
+      identifies the operator's access network, the Access-Point-Name
+      identifies a specific network device in the network to which the
+      mobile node is attached.  In some deployments, the Access-Point-
+      Name can be set to the string representation of the Media Access
+      Control (MAC) address of the device as specified in [RFC6991] (see
+      mac-address typedef) or some unique identifier that can be used by
+      the policy systems in the operator network to unambiguously
+      identify the device.  The encoding MUST be UTF-8 as described in
+      [RFC3629].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                    [Page 8]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+4.3.3.  DHCPv4 Access-Point-BSSID Sub-option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Subopt Code  |     Length    |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+      |                        Access-Point-BSSID                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Subopt Code
+      16
+
+   Length
+      6
+
+   Access-Point-BSSID
+      The 48-bit Basic SSSID (BSSID) of the access point to which the
+      mobile node is attached.
+
+4.4.  DHCPv4 Operator-Identifier Sub-options
+
+   The Operator-Identifier sub-options can be used for carrying the
+   Operator-Identifiers of the access network to which the client is
+   attached.  The format of these sub-options is defined below.
+
+4.4.1.  DHCPv4 Operator-Identifier Sub-option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Subopt Code  |     Length    |                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .      Operator-Identifier      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Subopt Code
+      17
+
+   Length
+      4
+
+   Operator-Identifier
+      The Operator-Identifier is a variable-length Private Enterprise
+      Number (PEN) [SMI] encoded in a network byte order.  Please refer
+      to Section 3.1.3 of [RFC6757] for additional details.
+
+
+
+
+
+Bhandari, et al.             Standards Track                    [Page 9]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+4.4.2.  DHCPv4 Operator-Realm Sub-option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Subopt Code  |     Length    |                               |
+      |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+      .                                                               .
+      .                        Operator-Realm                         .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Subopt Code
+      18
+
+   Length
+      The length of the Operator-Realm field.
+
+   Operator-Realm
+      Realm of the operator (e.g., EXAMPLE.COM).  Please refer to
+      Section 3.1.3 of [RFC6757] for additional details.
+
+5.  DHCPv6 Access-Network-Identifier Options
+
+   The Access-Network-Identifier options defined here may be added by
+   the DHCPv6 relay agent in Relay-forward messages.
+
+      +=================+=======================================+
+      |    OPTION CODE  |      OPTION DESCRIPTION               |
+      +=================+=======================================+
+      |       105       | OPTION_ANI_ATT                        |
+      +=========================================================+
+      |       106       | OPTION_ANI_NETWORK_NAME               |
+      +=========================================================+
+      |       107       | OPTION_ANI_AP_NAME                    |
+      +=========================================================+
+      |       108       | OPTION_ANI_AP_BSSID                   |
+      +=========================================================+
+      |       109       | OPTION_ANI_OPERATOR_ID                |
+      +=========================================================+
+      |       110       | OPTION_ANI_OPERATOR_REALM             |
+      +=========================================================+
+
+
+
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 10]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+5.1.  DHCPv6 Access-Technology-Type Option
+
+   This option is used for exchanging the type of access technology the
+   client uses to attach to the network.  Its format is as follows:
+
+        0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |         OPTION_ANI_ATT        |           Option-Len          |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |   Reserved    |       ATT     |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option-Code
+      OPTION_ANI_ATT (105)
+
+   Option-Len
+      2
+
+   Reserved
+      An 8-bit field that is unused for now.  The value MUST be
+      initialized to 0 by the sender and MUST be ignored by the
+      receiver.
+
+   Access-Technology-Type (ATT):
+      The contents of this field are the same as the ATT field described
+      in Section 4.2.
+
+5.2.  DHCPv6 Network-Identifier Options
+
+   These options can be used for carrying the name of the access network
+   (e.g., an SSID in the case of an IEEE 802.11 access network or a PLMN
+   Identifier [TS23003] in the case of a 3GPP access network) and an
+   Access-Point Name to which the client is attached.  The format of
+   these options is defined below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 11]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+5.2.1.  DHCPv6 Network-Name Option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    OPTION_ANI_NETWORK_NAME    |           Option-Len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                     Network-Name (e.g., SSID or PLMNID)       .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option-Code
+      OPTION_ANI_NETWORK_NAME (106)
+
+   Option-Len
+      The length of the Network-Name field.
+
+   Network-Name
+      The contents of this field are the same as the Network-Name field
+      described in Section 4.3.1.
+
+5.2.2.  DHCPv6 Access-Point-Name Option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       OPTION_ANI_AP_NAME      |           Option-Len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                        Access-Point-Name                      .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option-Code
+      OPTION_ANI_AP_NAME (107)
+
+   Option-Len
+      The length of the Access-Point-Name field.
+
+   Access-Point-Name
+      The contents of this field are the same as the Access-Point-Name
+      field described in Section 4.3.2.
+
+
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 12]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+5.2.3.  DHCPv6 Access-Point-BSSID Option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       OPTION_ANI_AP_BSSID     |           Option-Len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Access-Point-BSSID                     |
+      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option-Code
+      OPTION_ANI_AP_BSSID (108)
+
+   Option-Len
+      6
+
+   Access-Point-BSSID
+      The contents of this field are the same as the Access-Point-BSSID
+      field described in Section 4.3.3.
+
+5.3.  DHCPv6 Operator-Identifier Options
+
+   The Operator-Identifier options can be used for carrying the
+   Operator-Identifier of the access network to which the client is
+   attached.  The format of these options is defined below.
+
+5.3.1.  DHCPv6 Operator-Identifier Option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     OPTION_ANI_OPERATOR_ID    |           Option-Len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      Operator-Identifier                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option-Code
+      OPTION_ANI_OPERATOR_ID (109)
+
+   Option-Len
+      4
+
+   Operator-Identifier
+      The contents of this field are the same as the DHCPv4 Operator-
+      Identifier Sub-option field described in Section 4.4.1.
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 13]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+5.3.2.  DHCPv6 Operator-Realm Option
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   OPTION_ANI_OPERATOR_REALM   |           Option-Len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                        Operator-Realm                         .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Option-Code
+      OPTION_ANI_OPERATOR_REALM (110)
+
+   Option-Len
+      The length of the Operator-Realm field.
+
+   Operator-Realm
+      The contents of this field are the same as the Operator-Realm
+      field described in Section 4.4.2.
+
+6.  Relay Agent Behavior
+
+   DHCPv4 relay agents MAY include sub-options as defined in Section 4.2
+   through 4.4 of [RFC3046] in the Relay Agent Information option for
+   providing information about the access network over which DHCP
+   messages from the client are received.
+
+   The DHCPv4 relay agent MUST include the DHCPv4 Access-Technology-Type
+   Sub-option (Section 4.2) when including any of these sub-options in
+   the DHCP message: DHCPv4 Network-Name Sub-option (Section 4.3.1),
+   DHCPv4 Access-Point-Name Sub-option (Section 4.3.2), and DHCPv4
+   Access-Point-BSSID Sub-option (Section 4.3.3).
+
+   DHCPv6 Relay Agents MAY include options (defined in Section 5) in the
+   Relay-forward message when forwarding any DHCPv6 message type from
+   clients to the servers to provide information about the access
+   network over which DHCPv6 messages from the client are received.
+
+   The DHCPv6 relay agent MUST include the DHCPv6 Access-Technology-Type
+   Option (Section 5.1) when including any of these options in the DHCP
+   message: DHCPv6 Network-Name Option (Section 5.2.1), DHCPv6 Access-
+   Point-Name Option (Section 5.2.2), and DHCPv6 Access-Point-BSSID
+   Option (Section 5.2.3).
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 14]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+7.  Server Behavior
+
+   The DHCPv4 base specification [RFC2131] requires that the DHCPv4
+   server ignore the DHCPv4 Access-Network-Identifier Option if it does
+   not understand the option.
+
+   If the DHCPv4 server does not understand the received sub-option
+   defined in Sections 4.1 through 4.4 of [RFC3046], the DHCPv4 Relay-
+   Agent-Information Option, it MUST ignore those sub-options only.  If
+   the DHCPv4 server is able to process the DHCPv4 Access-Network-
+   Identifier sub-options defined in Sections 4.1 through 4.4 of
+   [RFC3046], the DHCPv4 Relay-Agent-Information Option, it MAY use this
+   information obtained from the sub-option for address pool selection
+   or for policy decisions as per its configured policy.  This
+   information obtained from the sub-option SHOULD NOT be stored unless
+   it is absolutely needed.  However, if it is stored, the information
+   MUST be deleted as quickly as possible to eliminate any possibility
+   of the information getting exposed to an intruder.
+
+   The DHCPv4 server MUST ignore the received DHCPv4 Access-Network-
+   Identifier Option and process the rest of the message as per the base
+   DHCPv4 specifications if the received DHCPv4 message does not include
+   the DHCPv4 Access-Technology-Type Sub-option (Section 4.2) but does
+   include any one of these other options: DHCPv4 Network Name Sub-
+   option (Section 4.3.1), DHCPv4 Access-Point-Name Sub-option
+   (Section 4.3.2), or DHCPv4 Access-Point-BSSID Sub-option
+   (Section 4.3.3).
+
+   DHCPv6 base specification [RFC3315] requires that the DHCPv6 server
+   ignore the DHCPv6 Access-Network-Identifier Option if it does not
+   understand the option.
+
+   If the DHCPv6 server receives the options defined in Section 5 and is
+   configured to use the options defined in Section 5, it SHOULD look
+   for the DHCPv6 Access-Network-Identifier options in the Relay-forward
+   message of the DHCPv6 relay agent(s) based on its configured policy.
+   The server MAY use received ANI options for its address pool
+   selection policy decisions as per its configured policy.  This
+   information obtained from the options SHOULD NOT be stored unless it
+   is absolutely needed.  However, if it is stored, the information MUST
+   be deleted as quickly as possible to eliminate any possibility of the
+   information getting exposed to an intruder.
+
+   The DHCPv6 server MUST ignore the received DHCPv6 Access-Network-
+   Identifier Option and process the rest of the message as per the base
+   DHCPv6 specifications if the received DHCPv6 message does not include
+   the DHCPv6 Access-Technology-Type Option (Section 5.1) but it does
+   includes any one of these other options: DHCPv6 Network-Name Option
+
+
+
+Bhandari, et al.             Standards Track                   [Page 15]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+   (Section 5.2.1), DHCPv6 Access-Point-Name Option (Section 5.2.2), or
+   DHCPv6 Access-Point-BSSID Option (Section 5.2.3).
+
+8.  IANA Considerations
+
+   IANA has assigned sub-option codes for the following DHCPv4 sub-
+   options from the "DHCP Relay Agent Sub-Option Codes" registry,
+   <http://www.iana.org/assignments/bootp-dhcp-parameters>:
+
+      +=================+=======================================+
+      | SUB-OPTION CODE |     SUB-OPTION DESCRIPTION            |
+      +=================+=======================================+
+      |       13        | Access-Technology-Type Sub-option     |
+      +=========================================================+
+      |       14        | Access-Network-Name Sub-option        |
+      +=========================================================+
+      |       15        | Access-Point-Name Sub-option          |
+      +=========================================================+
+      |       16        | Access-Point-BSSID Sub-option         |
+      +=========================================================+
+      |       17        | Operator-Identifier Sub-option        |
+      +=========================================================+
+      |       18        | Operator-Realm Sub-option             |
+      +=========================================================+
+
+   IANA has assigned option codes for the following DHCPv6 options from
+   the "Option Codes" registry for DHCPv6,
+   <http://www.iana.org/assignments/dhcpv6-parameters>, as specified in
+   [RFC3315]:
+
+      +=================+=======================================+
+      |   OPTION CODE   |      OPTION DESCRIPTION               |
+      +=================+=======================================+
+      |       105       | OPTION_ANI_ATT                        |
+      +=========================================================+
+      |       106       | OPTION_ANI_NETWORK_NAME               |
+      +=========================================================+
+      |       107       | OPTION_ANI_AP_NAME                    |
+      +=========================================================+
+      |       108       | OPTION_ANI_AP_BSSID                   |
+      +=========================================================+
+      |       109       | OPTION_ANI_OPERATOR_ID                |
+      +=========================================================+
+      |       110       | OPTION_ANI_OPERATOR_REALM             |
+      +=========================================================+
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 16]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+9.  Security Considerations
+
+   Since there is no privacy protection for DHCP messages, an
+   eavesdropper who can monitor the link between the DHCP server and
+   relay agent can discover access-network information.
+
+   [RFC3118] and [RFC3315] describe many of the threats in using DHCP.
+   [RFC3118] and [RFC3315] each provide a solution; the Authentication
+   Option for DHCPv4 and DHCPv6 (respectively).  However, neither of
+   these options are in active use and therefore are not a viable
+   mitigation option.  DHCP itself is inherently insecure and thus link-
+   layer confidentiality and integrity protection SHOULD be employed to
+   reduce the risk of disclosure and tampering.
+
+   It is possible for a rogue DHCP relay agent to insert or overwrite
+   with incorrect Access-Network-Identifier options for malicious
+   purposes.  A DHCP client can also pose as a rogue DHCP relay agent by
+   sending incorrect Access-Network-Identifier options.  While the
+   introduction of fraudulent DHCP relay agent information options can
+   be prevented by a perimeter defense that blocks these options unless
+   the DHCP relay agent is trusted, a deeper defense using the
+   authentication sub-option for the DHCPv4 Relay-Agent-Information
+   Option [RFC4030] SHOULD be deployed as well.  Administrators SHOULD
+   configure DHCP servers that use this option to communicate with their
+   relay agents using IPsec, as described in Section 21.1 of [RFC3315].
+
+   The information elements that this document is exposing are the
+   client's access-network information.  These pertain to the access
+   network to which the client is attached, such as Access-Technology
+   Type (e.g., WLAN, Ethernet, etc.), Access-Point Identity (Name,
+   BSSID), and Operator-Identifier and Operator-Realm.  In deployments
+   where this information cannot be secured using IPsec [RFC4301] or
+   other security protocols, administrators SHOULD disable the
+   capability specified in this document on the DHCP entities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 17]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, DOI 10.17487/RFC2131, March 1997,
+              <http://www.rfc-editor.org/info/rfc2131>.
+
+   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
+              RFC 3046, DOI 10.17487/RFC3046, January 2001,
+              <http://www.rfc-editor.org/info/rfc3046>.
+
+   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+              C., and M. Carney, "Dynamic Host Configuration Protocol
+              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
+              2003, <http://www.rfc-editor.org/info/rfc3315>.
+
+10.2.  Informative References
+
+   [ANI]      "Interoperability Specification (IOS) for High Rate Packet
+              Data (HRPD) Radio Access Network Interfaces with Session
+              Control in the Access Network", 3GPP2 A.S0008-C v4.0,
+              April 2011.
+
+   [RFC3118]  Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
+              DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
+              <http://www.rfc-editor.org/info/rfc3118>.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+              2003, <http://www.rfc-editor.org/info/rfc3629>.
+
+   [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
+              the Dynamic Host Configuration Protocol (DHCP) Relay Agent
+              Option", RFC 4030, DOI 10.17487/RFC4030, March 2005,
+              <http://www.rfc-editor.org/info/rfc4030>.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+              December 2005, <http://www.rfc-editor.org/info/rfc4301>.
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 18]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
+              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
+              RFC 5213, DOI 10.17487/RFC5213, August 2008,
+              <http://www.rfc-editor.org/info/rfc5213>.
+
+   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
+              Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010,
+              <http://www.rfc-editor.org/info/rfc5844>.
+
+   [RFC6757]  Gundavelli, S., Ed., Korhonen, J., Ed., Grayson, M.,
+              Leung, K., and R. Pazhyannur, "Access Network Identifier
+              (ANI) Option for Proxy Mobile IPv6", RFC 6757,
+              DOI 10.17487/RFC6757, October 2012,
+              <http://www.rfc-editor.org/info/rfc6757>.
+
+   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
+              RFC 6991, DOI 10.17487/RFC6991, July 2013,
+              <http://www.rfc-editor.org/info/rfc6991>.
+
+   [SMI]      IANA, "PRIVATE ENTERPRISE NUMBERS, SMI Network Management
+              Private Enterprise Codes", March 2016,
+              <https://www.iana.org/assignments/enterprise-numbers>.
+
+   [TS23003]  3GPP, "Numbering, addressing and identification", 3GPP
+              TS 23.003 13.4.0, December 2015.
+
+   [TS23203]  3GPP, "Policy and charging control architecture", 3GPP
+              TS 23.203 13.6.0, December 2015.
+
+   [TS23402]  3GPP, "Architecture enhancements for non-3GPP accesses",
+              3GPP TS 23.402 13.4.0, December 2015.
+
+Acknowledgements
+
+   The authors would like to thank Kim Kinnear, Ted Lemon, Gaurav
+   Halwasia, Hidetoshi Yokota, Sheng Jiang, and Francis Dupont for their
+   valuable input.  Also, thank you to Tomek Mrugalski for a thorough
+   review of the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 19]
+
+RFC 7839            ANI Options for DHCPv4 and DHCPv6          June 2016
+
+
+Authors' Addresses
+
+   Shwetha Bhandari
+   Cisco Systems
+   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
+   Bangalore, KARNATAKA  560 087
+   India
+
+   Phone: +91 80 4426 0474
+   Email: shwethab@cisco.com
+
+
+   Sri Gundavelli
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA  95134
+   United States
+
+   Email: sgundave@cisco.com
+
+
+   Mark Grayson
+   Cisco Systems
+   11 New Square Park
+   Bedfont Lakes, FELTHAM  TW14 8HA
+   England
+
+   Email: mgrayson@cisco.com
+
+
+   Bernie Volz
+   Cisco Systems
+   1414 Massachusetts Ave
+   Boxborough, MA  01719
+   United States
+
+   Email: volz@cisco.com
+
+
+   Jouni Korhonen
+   Broadcom Limited
+   3151 Zanker Rd
+   San Jose, CA  95134
+   United States
+
+   Email: jouni.nospam@gmail.com
+
+
+
+
+
+Bhandari, et al.             Standards Track                   [Page 20]
+