Access-Network-Identifier Option in DHCP
RFC 7839
| Document | Type | RFC - Proposed Standard (June 2016) Errata | |
|---|---|---|---|
| Authors | Shwetha Bhandari , Sri Gundavelli , Mark Grayson , Bernie Volz , Jouni Korhonen | ||
| Last updated | 2022-07-13 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Brian Haberman | |
| Send notices to | (None) |
RFC 7839
Delay-Tolerant Networking B. Sipos
Internet-Draft RKF Engineering
Intended status: Standards Track M. Demmer
Expires: 7 June 2021 UC Berkeley
J. Ott
Aalto University
S. Perreault
4 December 2020
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-24
Abstract
This document describes a TCP-based convergence layer (TCPCL) for
Delay-Tolerant Networking (DTN). This version of the TCPCL protocol
resolves implementation issues in the earlier TCPCL Version 3 of
RFC7242 and updates to the Bundle Protocol (BP) contents, encodings,
and convergence layer requirements in BP Version 7. Specifically,
the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit
being transported and provides a reliable transport of such bundles.
This version of TCPCL also includes security and extensibility
mechanisms.
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 https://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 7 June 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sipos, et al. Expires 7 June 2021 [Page 1]
Internet-Draft DTN TCPCLv4 December 2020
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 5
3. General Protocol Description . . . . . . . . . . . . . . . . 9
3.1. Convergence Layer Services . . . . . . . . . . . . . . . 9
3.2. TCPCL Session Overview . . . . . . . . . . . . . . . . . 12
3.3. TCPCL States and Transitions . . . . . . . . . . . . . . 13
3.4. PKIX Environments and CA Policy . . . . . . . . . . . . . 19
3.5. Session Keeping Policies . . . . . . . . . . . . . . . . 20
3.6. Transfer Segmentation Policies . . . . . . . . . . . . . 21
3.7. Example Message Exchange . . . . . . . . . . . . . . . . 22
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 24
4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 24
4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 25
4.3. Contact Validation and Negotiation . . . . . . . . . . . 26
4.4. Session Security . . . . . . . . . . . . . . . . . . . . 28
4.4.1. Entity Identification . . . . . . . . . . . . . . . . 28
4.4.2. Certificate Profile for TCPCL . . . . . . . . . . . . 29
4.4.3. TLS Handshake . . . . . . . . . . . . . . . . . . . . 30
4.4.4. TLS Authentication . . . . . . . . . . . . . . . . . 31
4.4.5. Policy Recommendations . . . . . . . . . . . . . . . 33
4.4.6. Example TLS Initiation . . . . . . . . . . . . . . . 33
4.5. Message Header . . . . . . . . . . . . . . . . . . . . . 35
4.6. Session Initialization Message (SESS_INIT) . . . . . . . 36
4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 38
4.8. Session Extension Items . . . . . . . . . . . . . . . . . 39
5. Established Session Operation . . . . . . . . . . . . . . . . 40
5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 40
5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 40
5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 41
5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 43
5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 44
5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 44
5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 46
5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 48
5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 50
Sipos, et al. Expires 7 June 2021 [Page 2]
Internet-Draft DTN TCPCLv4 December 2020
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 52
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 52
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 55
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 55
8. Security Considerations . . . . . . . . . . . . . . . . . . . 55
8.1. Threat: Passive Leak of Node Data . . . . . . . . . . . . 56
8.2. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 56
8.3. Threat: TCPCL Version Downgrade . . . . . . . . . . . . . 56
8.4. Threat: Transport Security Stripping . . . . . . . . . . 56
8.5. Threat: Weak TLS Configurations . . . . . . . . . . . . . 57
8.6. Threat: Untrusted End-Entity Certificate . . . . . . . . 57
8.7. Threat: Certificate Validation Vulnerabilities . . . . . 57
8.8. Threat: Symmetric Key Limits . . . . . . . . . . . . . . 58
8.9. Threat: BP Node Impersonation . . . . . . . . . . . . . . 58
8.10. Threat: Denial of Service . . . . . . . . . . . . . . . . 59
8.11. Mandatory-to-Implement TLS . . . . . . . . . . . . . . . 60
8.12. Alternate Uses of TLS . . . . . . . . . . . . . . . . . . 60
8.12.1. TLS Without Authentication . . . . . . . . . . . . . 60
8.12.2. Non-Certificate TLS Use . . . . . . . . . . . . . . 60
8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 61
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 61
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 62
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 63
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 63
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 64
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 65
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 66
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 67
9.9. Object Identifier for PKIX Extended Key Usage . . . . . . 68
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
11.1. Normative References . . . . . . . . . . . . . . . . . . 69
11.2. Informative References . . . . . . . . . . . . . . . . . 70
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
1. Introduction
This document describes the TCP-based convergence-layer protocol for
Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to-
end architecture providing communications in and/or through highly
stressed environments, including those with intermittent
connectivity, long and/or variable delays, and high bit error rates.
More detailed descriptions of the rationale and capabilities of these
networks can be found in "Delay-Tolerant Network Architecture"
[RFC4838].
Sipos, et al. Expires 7 June 2021 [Page 3]
Internet-Draft DTN TCPCLv4 December 2020
An important goal of the DTN architecture is to accommodate a wide
range of networking technologies and environments. The protocol used
for DTN communications is the Bundle Protocol Version 7 (BPv7)
[I-D.ietf-dtn-bpbis], an application-layer protocol that is used to
construct a store-and-forward overlay network. BPv7 requires the
services of a "convergence-layer adapter" (CLA) to send and receive
bundles using the service of some "native" link, network, or Internet
protocol. This document describes one such convergence-layer adapter
that uses the well-known Transmission Control Protocol (TCP). This
convergence layer is referred to as TCP Convergence Layer Version 4
(TCPCLv4). For the remainder of this document, the abbreviation "BP"
without the version suffix refers to BPv7. For the remainder of this
document, the abbreviation "TCPCL" without the version suffix refers
to TCPCLv4.
The locations of the TCPCL and the BP in the Internet model protocol
stack (described in [RFC1122]) are shown in Figure 1. In particular,
when BP is using TCP as its bearer with TCPCL as its convergence
layer, both BP and TCPCL reside at the application layer of the
Internet model.
+-------------------------+
| DTN Application | -\
+-------------------------| |
| Bundle Protocol (BP) | -> Application Layer
+-------------------------+ |
| TCP Conv. Layer (TCPCL) | |
+-------------------------+ |
| TLS (optional) | -/
+-------------------------+
| TCP | ---> Transport Layer
+-------------------------+
| IPv4/IPv6 | ---> Network Layer
+-------------------------+
| Link-Layer Protocol | ---> Link Layer
+-------------------------+
Figure 1: The Locations of the Bundle Protocol and the TCP
Convergence-Layer Protocol above the Internet Protocol Stack
1.1. Scope
This document describes the format of the protocol data units passed
between entities participating in TCPCL communications. This
document does not address:
Sipos, et al. Expires 7 June 2021 [Page 4]
Internet-Draft DTN TCPCLv4 December 2020
* The format of protocol data units of the Bundle Protocol, as those
are defined elsewhere in [I-D.ietf-dtn-bpbis]. This includes the
concept of bundle fragmentation or bundle encapsulation. The
TCPCL transfers bundles as opaque data blocks.
* Mechanisms for locating or identifying other bundle entities
(peers) within a network or across an internet. The mapping of
Node ID to potential convergence layer (CL) protocol and network
address is left to implementation and configuration of the BP
Agent and its various potential routing strategies.
* Logic for routing bundles along a path toward a bundle's endpoint.
This CL protocol is involved only in transporting bundles between
adjacent entities in a routing sequence.
* Policies or mechanisms for issuing Public Key Infrastructure Using
X.509 (PKIX) certificates; provisioning, deploying, or accessing
certificates and private keys; deploying or accessing certificate
revocation lists (CRLs); or configuring security parameters on an
individual entity or across a network.
* Uses of TLS which are not based on PKIX certificate authentication
(see Section 8.12.2) or in which authentication of both entities
is not possible (see Section 8.12.1).
Any TCPCL implementation requires a BP agent to perform those above
listed functions in order to perform end-to-end bundle delivery.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.1. Definitions Specific to the TCPCL Protocol
This section contains definitions specific to the TCPCL protocol.
Network Byte Order: Most significant byte first, a.k.a., big endian.
All of the integer encodings in this protocol SHALL be transmitted
in network byte order.
TCPCL Entity: This is the notional TCPCL application that initiates
TCPCL sessions. This design, implementation, configuration, and
specific behavior of such an entity is outside of the scope of
this document. However, the concept of an entity has utility
Sipos, et al. Expires 7 June 2021 [Page 5]
Internet-Draft DTN TCPCLv4 December 2020
within the scope of this document as the container and initiator
of TCPCL sessions. The relationship between a TCPCL entity and
TCPCL sessions is defined as follows:
* A TCPCL Entity MAY actively initiate any number of TCPCL
Sessions and should do so whenever the entity is the initial
transmitter of information to another entity in the network.
* A TCPCL Entity MAY support zero or more passive listening
elements that listen for connection requests from other TCPCL
Entities operating on other entities in the network.
* A TCPCL Entity MAY passively initiate any number of TCPCL
Sessions from requests received by its passive listening
element(s) if the entity uses such elements.
These relationships are illustrated in Figure 2. For most TCPCL
behavior within a session, the two entities are symmetric and
there is no protocol distinction between them. Some specific
behavior, particularly during session establishment, distinguishes
between the active entity and the passive entity. For the
remainder of this document, the term "entity" without the prefix
"TCPCL" refers to a TCPCL entity.
TCP Connection: The term Connection in this specification
exclusively refers to a TCP connection and any and all behaviors,
sessions, and other states associated with that TCP connection.
TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a
TCPCL communication relationship between two TCPCL entities. A
TCPCL session operates within a single underlying TCP connection
and the lifetime of a TCPCL session is bound to the lifetime of
that TCP connection. A TCPCL session is terminated when the TCP
connection ends, due either to one or both entities actively
closing the TCP connection or due to network errors causing a
failure of the TCP connection. Within a single TCPCL session
there are two possible transfer streams; one in each direction,
with one stream from each entity being the outbound stream and the
other being the inbound stream (see Figure 3). From the
perspective of a TCPCL session, the two transfer streams do not
logically interact with each other. The streams do operate over
the same TCP connection and between the same BP agents, so there
are logical relationships at those layers (message and bundle
interleaving respectively). For the remainder of this document,
the term "session" without the prefix "TCPCL" refers to a TCPCL
session.
Session parameters: These are a set of values used to affect the
Sipos, et al. Expires 7 June 2021 [Page 6]
Internet-Draft DTN TCPCLv4 December 2020
operation of the TCPCL for a given session. The manner in which
these parameters are conveyed to the bundle entity and thereby to
the TCPCL is implementation dependent. However, the mechanism by
which two entities exchange and negotiate the values to be used
for a given session is described in Section 4.3.
Transfer Stream: A Transfer stream is a uni-directional user-data
path within a TCPCL Session. Transfers sent over a transfer
stream are serialized, meaning that one transfer must complete its
transmission prior to another transfer being started over the same
transfer stream. At the stream layer there is no logical
relationship between transfers in that stream; it's only within
the BP agent that transfers are fully decoded as bundles. Each
uni-directional stream has a single sender entity and a single
receiver entity.
Transfer: This refers to the procedures and mechanisms for
conveyance of an individual bundle from one node to another. Each
transfer within TCPCL is identified by a Transfer ID number which
is guaranteed to be unique only to a single direction within a
single Session.
Transfer Segment: A subset of a transfer of user data being
communicated over a transfer stream.
Idle Session: A TCPCL session is idle while there is no transmission
in-progress in either direction. While idle, the only messages
being transmitted or received are KEEPALIVE messages.
Live Session: A TCPCL session is live while there is a transmission
in-progress in either direction.
Reason Codes: The TCPCL uses numeric codes to encode specific
reasons for individual failure/error message types.
The relationship between connections, sessions, and streams is shown
in Figure 3.
Sipos, et al. Expires 7 June 2021 [Page 7]
Internet-Draft DTN TCPCLv4 December 2020
+--------------------------------------------+
| TCPCL Entity |
| | +----------------+
| +--------------------------------+ | | |-+
| | Actively Initiated Session #1 +------------->| Other | |
| +--------------------------------+ | | TCPCL Entity's | |
| ... | | Passive | |
| +--------------------------------+ | | Listener | |
| | Actively Initiated Session #n +------------->| | |
| +--------------------------------+ | +----------------+ |
| | +-----------------+
| +---------------------------+ |
| +---| +---------------------------+ | +----------------+
| | | | Optional Passive | | | |-+
| | +-| Listener(s) +<-------------+ | |
| | +---------------------------+ | | | |
| | | | Other | |
| | +---------------------------------+ | | TCPCL Entity's | |
| +--->| Passively Initiated Session #1 +-------->| Active | |
| | +---------------------------------+ | | Initiator(s) | |
| | | | | |
| | +---------------------------------+ | | | |
| +--->| Passively Initiated Session #n +-------->| | |
| +---------------------------------+ | +----------------+ |
| | +-----------------+
+--------------------------------------------+
Figure 2: The relationships between TCPCL entities
Sipos, et al. Expires 7 June 2021 [Page 8]
Internet-Draft DTN TCPCLv4 December 2020
+---------------------------+ +---------------------------+
| "Own" TCPCL Session | | "Other" TCPCL Session |
| | | |
| +----------------------+ | | +----------------------+ |
| | TCP Connection | | | | TCP Connection | |
| | | | | | | |
| | +-----------------+ | | Messages | | +-----------------+ | |
| | | Own Inbound | +--------------------+ | Peer Outbound | | |
| | | Transfer Stream | | Transfer Stream | | |
| | | ----- |<---[Seg]--[Seg]--[Seg]---| ----- | | |
| | | RECEIVER |---[Ack]----[Ack]-------->| SENDER | | |
| | +-----------------+ +-----------------+ | |
| | | |
| | +-----------------+ +-----------------+ | |
| | | Own Outbound |-------[Seg]---[Seg]----->| Peer Inbound | | |
| | | Transfer Stream |<---[Ack]----[Ack]-[Ack]--| Transfer Stream | | |
| | | ----- | | ----- | | |
| | | SENDER | +--------------------+ | RECEIVER | | |
| | +-----------------+ | | | | +-----------------+ | |
| +-----------------------+ | | +---------------------+ |
+----------------------------+ +--------------------------+
Figure 3: The relationship within a TCPCL Session of its two streams
3. General Protocol Description
The service of this protocol is the transmission of DTN bundles via
the Transmission Control Protocol (TCP). This document specifies the
encapsulation of bundles, procedures for TCP setup and teardown, and
a set of messages and entity requirements. The general operation of
the protocol is as follows.
3.1. Convergence Layer Services
This version of the TCPCL provides the following services to support
the overlaying Bundle Protocol agent. In all cases, this is not an
API definition but a logical description of how the CL can interact
with the BP agent. Each of these interactions can be associated with
any number of additional metadata items as necessary to support the
operation of the CL or BP agent.
Attempt Session: The TCPCL allows a BP agent to preemptively attempt
to establish a TCPCL session with a peer entity. Each session
attempt can send a different set of session negotiation parameters
as directed by the BP agent.
Terminate Session: The TCPCL allows a BP agent to preemptively
Sipos, et al. Expires 7 June 2021 [Page 9]
Internet-Draft DTN TCPCLv4 December 2020
terminate an established TCPCL session with a peer entity. The
terminate request is on a per-session basis.
Session State Changed: The TCPCL entity indicates to the BP agent
when the session state changes. The top-level session states
indicated are:
Connecting: A TCP connection is being established. This state
only applies to the active entity.
Contact Negotiating: A TCP connection has been made (as either
active or passive entity) and contact negotiation has begun.
Session Negotiating: Contact negotiation has been completed
(including possible TLS use) and session negotiation has begun.
Established: The session has been fully established and is ready
for its first transfer. When the session is established, the
peer Node ID (along with indication of whether or not it was
authenticated) and the negotiated session parameters (see
Section 4.7) are also communicated to the BP agent.
Ending: The entity sent SESS_TERM message and is in the ending
state.
Terminated: The session has finished normal termination
sequencing.
Failed: The session ended without normal termination sequencing.
Session Idle Changed: The TCPCL entity indicates to the BP agent
when the live/idle sub-state of the session changes. This occurs
only when the top-level session state is "Established". The
session transitions from Idle to Live at the at the start of a
transfer in either transfer stream; the session transitions from
Live to Idle at the end of a transfer when the other transfer
stream does not have an ongoing transfer. Because TCPCL transmits
serially over a TCP connection it suffers from "head of queue
blocking,&<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]