RFC 7847
Logical-Interface Support for IP Hosts with Multi-Access Support
RFC 7847 💖 Logical-Interface Support for IP Hosts with Multi-Access Support
Okay bestie, the title block is giving informational vibes 🎀:
- Authors: T. Melia, Ed. (Kudelski Security) and S. Gundavelli, Ed. (Cisco) ✨
- Category: Informational, so it's not a Standards Track spec 🌸
- Date: May 2016 📅
- ISSN: 2070-1721
- Obsoletes / Updates: the header doesn't list either one, so it doesn't obsolete or update anything 🦋
Abstract
okay so a logical interface is a software idea that lives inside the host OS, and literally every popular OS has it 💅 Protocol implementations use it all the time. The logical interface is needed on a mobile node that's attached to a Proxy Mobile IPv6 domain, because it unlocks network-based mobility stuff like inter-technology handoffs, multihoming, and flow mobility 🔥 This doc explains how the logical-interface construct works, and how link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the access networks 👑 It also checks which link-layer technologies this approach fits, and analyzes the issues that pop up when you combine it with various mobility management features 🧚
Status of This Memo
not an Internet Standards Track spec, it's just published for info purposes 📝
This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶 Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 💀
Want the current status, errata, or a way to send feedback? Check http://www.rfc-editor.org/info/rfc7847 ✨
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. Please read these carefully because they spell out your rights and restrictions for this doc 🙈 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🌈
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Hiding Link-Layer Technologies -- Approaches and
Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Link-Layer Abstraction -- Approaches . . . . . . . . . . 4
3.2. Link-Layer Support . . . . . . . . . . . . . . . . . . . 5
3.3. Logical Interface . . . . . . . . . . . . . . . . . . . . 6
4. Technology Use Cases . . . . . . . . . . . . . . . . . . . . 6
5. Logical-Interface Functional Details . . . . . . . . . . . . 7
5.1. Configuration of a Logical Interface . . . . . . . . . . 8
5.2. Logical-Interface Conceptual Data Structures . . . . . . 9
6. Logical-Interface Use Cases in Proxy Mobile IPv6 . . . . . . 11
6.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 11
6.2. Inter-technology Handoff Support . . . . . . . . . . . . 12
6.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 161. Introduction ✨
okay so Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based mobility management protocol standardized by the IETF 🌸 One of its big goals is letting a mobile node do handovers across access networks that use different access technologies 🦋 The protocol was also built so a mobile node can attach to different access networks at the same time and do flow-based access selection [RFC7864] 💅 The base features in [RFC5213] and [RFC5844] support all of this already. BUT to get these features, the mobile node is required to have a specific software setup called logical-interface support 😭 The logical-interface config is what lets a mobile node switch between access networks without messing up the IP sessions on the host 👑
A logical-interface construct lives inside the OS. It's an interface abstraction, where a logical link-layer implementation hides a bunch of physical interfaces from the IP stack 🧚 This semantic has been used across lots of OSes to build stuff like a Mobile IP client [RFC6275] and an IPsec VPN client [RFC4301] 🎀 Lots of host OSes have some form of logical-interface construct, but there's no spec that documents how these logical interfaces behave, or what they need in order to support those mobility features 🙈 This spec is here to fix that 🔥
The rest of the doc describes the functional side of a logical interface on the mobile node, and how it interworks with a mobile node and the network elements in the Proxy Mobile IPv6 domain 🌈 It also looks at the issues that come with using a logical interface, and the contexts where that usage actually makes sense 💜
2. Terminology 🦋
all the mobility-related terms in this doc are interpreted as defined in the Proxy Mobile IPv6 specs [RFC5213] and [RFC5844] 📝 On top of those, this doc uses these terms:
PIF (Physical Interface): a network interface module on the host that connects to an access network. A host usually has a bunch of these, like Ethernet, Wireless LAN, LTE, etc. Each one can support a specific link technology 🍓LIF (Logical Interface): a virtual interface in the IP stack. To the IP stack it looks just like any other physical interface, and it gives the upper layers similar semantics for packet transmit and receive ✨ But it's only a logical construct, not a representation of any physical hardware 🫶SIF (Sub-Interface): a physical or logical interface that's part of a logical-interface construct. For example, a logical interface might be made by abstracting two physical interfaces, LTE and WLAN. Those two are called sub-interfaces of that logical interface 💅 Sometimes a sub-interface can also be another logical interface, like an IPsec tunnel interface 🧚
3. Hiding Link-Layer Technologies -- Approaches and Applicability 🌸
there are several techniques that let you hide access technology changes from the host layer 🦋 These changes mostly happen because the host moves between access networks 👑 This section sorts those existing techniques into a set of generic approaches, based on their most representative characteristics 💖 Later sections check how well these solution approaches work for features like inter-technology handovers and IP flow mobility for a mobile node 🔥
3.1. Link-Layer Abstraction -- Approaches 💜
the following generic mechanisms can hide access technology changes from the host IP layer:
- Link-Layer Support 🌈 Certain link-layer technologies can hide physical media changes from the upper layers. For example, IEEE 802.11 can seamlessly switch between IEEE 802.11a/b/g physical layers 🍓 An 802.11 Station (STA) can also move between different access points inside the same domain without the IP stack ever knowing 🙈 In that case the IEEE 802.11 Media Access Control (MAC) layer handles the mobility, so the media change is invisible to the upper layers 💀 Another example is IEEE 802.3, which supports changing the rate from 10 Mbps to 100 Mbps and to 1000 Mbps ✨ And then there's the 3GPP Evolved Packet System [TS23401], where the User Equipment (UE) can do inter-access handovers between three different access technologies (2G GSM/EDGE Radio Access Network (GERAN), 3G Universal Terrestrial Radio Access Network (UTRAN), and 4G Evolved UTRAN (E-UTRAN)). Those handovers are invisible to the IP layer at the UE 🫶
- Logical Interface 🦋 A logical interface is a mechanism that logically groups several physical interfaces so they show up to the IP layer as one single interface (see Figure 1). Depending on the access technologies, it might be possible to use more than one physical interface at a time, so the node is attached through different access technologies at once. Or it might just do handovers across a bunch of physical interfaces 🔥 Controlling how the access technologies get used (simultaneous, sequential attachment, etc.) isn't trivial and needs extra smarts and/or configuration inside the logical-interface implementation 😭 That config is usually handled by a connection manager, and it's based on a mix of user preferences on one hand and operator preferences, like the ones provisioned by the Access Network Discovery and Selection Function (ANDSF) [TS23402], on the other 👑 The IETF Interfaces MIB in [RFC2863] and the YANG data model for interface management in [RFC7223] both treat a logical interface like any other type of network interface on the host 🧚 That makes the logical interface a natural operating system construct 🌸
That's the end of part 1, bestie! 🌈 More parts are coming, so stay tuned 💖
3.2. Link-Layer Support ✨
okay so link-layer mobility support is for when the same link-layer technology is being used and the mobility can be fully handled at that layer 🫶 the classic example is a bunch of 802.11 access points deployed in the same subnet with a common IP-layer configuration (DHCP server, default router, etc.) 🧚 in that setup the handover across access points doesn't need to be hidden from the IP layer, because the IP-layer configuration stays the same after the handover. this is giving seamless ✨ and it fits when the different points of attachment (aka the access points) belong to the same network domain, like an enterprise, or hotspots from the same operator, etc. 🏢
ngl this type of link-layer tech doesn't usually let you attach to different access networks of the same technology at the same time 😭 so the logical interface wouldn't be used for simultaneous access for multihoming or flow mobility here. instead, the logical interface can handle inter-access technology handover between this kind of link-layer tech and another link-layer tech, like between IEEE 802.11 and IEEE 802.16 💜 it's the glow-up that it's giving 💅
3.3. Logical Interface 🦋
the logical interface lets the mobile node show a single-interface perspective to the IP layer and its upper layers (transport and application) 💖 which is so iconic, because inter-access technology handovers or application flow handovers can get hidden across different physical interfaces 🌈
the logical interface may support simultaneous attachment as well as sequential attachment 🔥 but to actually benefit from the simultaneous part it needs additional support at the node and the network 😤 for example, special mechanisms are required to enable addressing a particular interface from the network (e.g., for flow mobility). like, extensions to PMIPv6 are required so the network (i.e., the mobile access gateway (MAG) and local mobility anchor (LMA)) can deal with the logical interface, instead of using extensions to IP interfaces as currently specified in RFC 5213. the thing is RFC 5213 assumes that each physical interface capable of attaching to a MAG is an IP interface, while the logical-interface solution groups several physical interfaces under the same IP logical interface 🎀
so yeah, it's clear that the logical-interface approach satisfies the requirement of multi-access technology and supports both sequential and simultaneous access 👑✨
4. Technology Use Cases 🌸
3GPP has defined the Evolved Packet System (EPS) for heterogeneous wireless access 📡 a mobile device with 3GPP and non-3GPP wireless technologies can connect simultaneously or sequentially to any of the available access networks and receive IP services through any of them 🙈 this document focuses on using a logical interface for simultaneous and sequential use of a variety of access technologies 💅
as mentioned in the previous sections, the logical-interface construct can hide the specifics of each technology from the IP layer in the context of network-based mobility (e.g., in multi-access technology networks based on PMIPv6) 🧠 the LIF concept can be used with at least the following technologies: 3GPP access technologies (3G and LTE), IEEE 802.16 access technology, and IEEE 802.11 access technology 🦋
in some UE implementations, the wireless connection setup is based on creating a PPP interface between the IP layer and the wireless modem, configured with the IP Control Protocol (IPCP) and IPv6 Control Protocol (IPv6CP) [RFC5072] 🍓 in this case the PPP interface doesn't have any layer 2 (L2) addresses assigned 🫠 in some other implementations, the wireless modem is presented to the IP layer as a virtual Ethernet interface 💜
5. Logical-Interface Functional Details 🧚
this section identifies the functional details of a logical interface and gives some implementation considerations 📝
on most operating systems, a network interface is tied to a physical device that offers the services for transmitting and receiving IP packets from the network 💻 in some configurations, though, a network interface can also be a logical interface. it doesn't have the inherent ability to transmit or receive packets on a physical medium, and instead relies on other physical interfaces for those services 🌊 an example of this setup is an IP tunnel interface 🚇
here's an overview of a logical interface in Figure 1 👀 the logical interface allows heterogeneous attachment while making changes in the underlying media transparent to the IP stack ✨ so simultaneous and sequential network attachment procedures are possible, which unlocks inter-technology and flow mobility scenarios 🦋
+----------------------------+
| TCP/UDP |
Session-to-IP +---->| |
Address Binding | +----------------------------+
+---->| IP |
IP Address +---->| |
Binding | +----------------------------+
+---->| Logical Interface |
Logical-to- +---->| IPv4/IPv6 Address |
Physical | +----------------------------+
Interface +---->| L2 | L2 | | L2 |
Binding |(IF#1)|(IF#2)| ..... |(IF#n)|
+------+------+ +------+
| L1 | L1 | | L1 |
| | | | |
+------+------+ +------+Figure 1: General Overview of Logical Interface 🎨
from the perspective of the IP stack and the applications, a logical interface is just another interface 🙌 honestly the logical interface is only visible to the IP and upper layers when it's enabled 👀 a host doesn't see any operational difference between a logical and a physical interface 🤷♀️ like physical interfaces, a logical interface is represented as a software object that IP address configuration is bound to 💾 but it has some special properties that are essential for enabling inter-technology handover and flow-mobility features, and they are:
- the logical interface has a relation to a set of physical interfaces (sub-interfaces) on the host that it is abstracting. these sub-interfaces can be attached or detached from the logical interface at any time. the sub-interfaces attached to a logical interface are not visible to the IP and upper layers 🫥
- the logical interface may be attached to multiple access technologies 📶
- the Transmit/Receive functions of the logical interface are mapped to the Transmit/Receive services exposed by the sub-interfaces. this mapping is dynamic, and any change is not visible to the upper layers of the IP stack 🪄
- the logical interface maintains IP flow information for each of its sub-interfaces. a conceptual data structure is maintained for this purpose. the host may populate this information based on tracking each of the sub-interfaces for the active flows 🗂️
5.1. Configuration of a Logical Interface 🎀
a host may be statically configured with the logical-interface configuration, or an application such as a connection manager on the host may dynamically create it 💅 also the set of sub-interfaces that are part of a logical-interface construct may be a fixed set, or it may be kept dynamic, with sub-interfaces getting added or deleted as needed 🔄 the specific details related to these configuration aspects are implementation specific and are outside the scope of this document 🫶
the IP layer should be configured with a default router reachable via the logical interface 🛣️ the default router can be internal to the logical interface, i.e., it's a logical router that in turn decides which physical interface is used to transmit packets 🧭 main character router energy 👑
5.2. Logical-Interface Conceptual Data Structures ✨
Okay so every logical interface keeps a list of the sub-interfaces that belong to that logical-interface construct 🧚. This is a conceptual data structure called the LIF table, and it's giving spreadsheet energy 💅. Figure 2 shows an example where logical interface LIF-1 has three sub-interfaces, ETH-0, WLAN-0, and LTE-0, and logical interface LIF-2 has two, ETH-1 and WLAN-1. For each LIF entry, the table should store the link status and policy for that sub-interface (for example, active or not active). How routing policies get configured on the host is out of scope for this doc, so don't come for me about it 🙈
+=======================+========================+==================+
| Logical_Interface | Sub_Interface | Status/Policy |
+=======================+========================+==================+
| LIF-1 | ETH-0 | UP |
+=======================+========================+==================+
| LIF-1 | WLAN-0 | DOWN |
+=======================+========================+==================+
| LIF-1 | LTE-0 | UP |
+=======================+========================+==================+
| LIF-2 | ETH-1 | UP |
+=======================+========================+==================+
| LIF-2 | WLAN-1 | UP |
+=======================+========================+==================+Figure 2: Logical-Interface Table
The logical interface also keeps track of the flows tied to each sub-interface, and this conceptual data structure is called the Flow table 🦋. Figure 3 shows an example Flow table where FID-1, FID-2, FID-3, FID-4, and FID-5 are associated with sub-interfaces ETH-0, WLAN-0, LTE-0, ETH-1, and WLAN-1, respectively.
+=======================+========================+
| Flow | Sub_Interface |
+=======================+========================+
| FID-1 | ETH-0 |
+=======================+========================+
| FID-2 | WLAN-0 |
+=======================+========================+
| FID-3 | LTE-0 |
+=======================+========================+
| FID-4 | ETH-1 |
+=======================+========================+
| FID-5 | WLAN-1 |
+=======================+========================+Figure 3: Flow Table
The Flow table is what lets the logical interface route each IP flow over a specific sub-interface properly 🎀. The logical interface can identify flows arriving on its sub-interfaces and associate them with those sub-interfaces. This is kinda like the reflective QoS that IP routers do ✨. For locally generated traffic (for example, unicast flows), the logical interface should perform interface selection based on the Flow Routing Policies. If traffic for an existing flow suddenly arrives from the network on a different sub-interface than the one stored locally, the logical interface should interpret that as an explicit flow mobility trigger from the network, and it should update the corresponding entry in the Flow table. Similarly, locally generated events from the sub-interfaces, or configuration updates to the local policy rules, can cause updates to the table and hence trigger flow mobility 😭
6. Logical-Interface Use Cases in Proxy Mobile IPv6 🦋
This section explains how the logical-interface support on the mobile node can be used to enable some of the Proxy Mobile IPv6 protocol features 🧚
6.1. Multihoming Support 🌈
Figure 4 shows a mobile node with multiple interfaces attached to a Proxy Mobile IPv6 domain. In this scenario, the mobile node is configured to use a logical interface over the physical interfaces it's attached through 💖
LMA Binding Table
+========================+
+----+ | HNP MN-ID CoA ATT |
|LMA | +========================+
+----+ | HNP-1 MN-1 PCoA-1 5 |
//\\ | HNP-1 MN-1 PCoA-2 4 |
+---------//--\\-----------+
( // \\ )
( // \\ )
+------//--------\\--------+
// \\
PCoA-1 // \\ PCoA-2
+----+ +----+
(WLAN) |MAG1| |MAG2| (3GPP)
+----+ +----+
\ /
\ /
\ /
\ /
\ /
+-------+ +-------+
| if_1 | | if_2 |
|(WLAN) | |(3GPP) |
+-------+-+-------+
| Logical |
| Interface |
| (HNP-1) |
+-----------------|
| MN |
+-----------------+Figure 4: Multihoming Support
6.2. Inter-technology Handoff Support 🔥
The Proxy Mobile IPv6 protocol lets a mobile node with multiple network interfaces move between access technologies and still keep the same address configuration on its attached interface 🏃♀️ Figure 5 shows a mobile node doing an inter-technology handoff between access networks. The protocol lets the mobile node achieve address continuity during handoffs. If the host is configured to use a logical interface over the physical interface it's attached through, here are the related considerations:
LMA's Binding Table
+==========================+
+----+ | HNP MN-ID CoA ATT |
|LMA | +==========================+
+----+ | HNP-1 MN-1 PCoA-1 5 |
//\\ (pCoA-2)(4) <--change
+---------//--\\-----------+
( // \\ )
( // \\ )
+------//--------\\--------+
// \\
PCoA-1 // \\ PCoA-2
+----+ +----+
(WLAN) |MAG1| |MAG2| (3GPP)
+----+ +----+
\ /
\ Handoff /
\ /
\ /
+-------+ +-------+
| if_1 | | if_2 |
|(WLAN) | |(3GPP) |
+-------+-+-------+
| Logical |
| Interface |
| (HNP-1) |
+-----------------|
| MN |
+-----------------+Figure 5: Inter-technology Handoff Support
- When the mobile node performs a handoff between
if_1andif_2, the change will not be visible to the applications of the mobile node. 🫶 - The protocol signaling between the network elements will ensure the local mobility anchor will switch the forwarding for the advertised prefix set from
MAG1toMAG2. 👑
6.3. Flow Mobility Support 💅
To support IP flow mobility, there's a need to support vertical handoff scenarios, like transferring a subset of a prefix(es) (and therefore the flows associated with it/them) from one interface to another. The mobile node can support this by using the logical-interface support. This scenario is similar to the inter-technology handoff scenario defined in Section 6.2; only a subset of the prefixes gets moved between interfaces 🧚
Additionally, IP flow mobility in general starts when the LMA decides to move a particular flow from its default path to a different one. The LMA can decide the best MAG to use for forwarding a particular flow when the flow is initiated (for example, based on application policy profiles) and/or during the lifetime of the flow when it receives a network-based or a mobile-based trigger. However, the specific details of how the LMA can formulate such flow policy are outside the scope of this document 🙈
7. Security Considerations 💀
This specification explains the operational details of a logical interface on an IP host. The logical-interface implementation on the host is not visible to the network and does not require any special security considerations.
Okay, but this is the part where we have to be serious bestie 😭 Different layer 2 interfaces and the access networks they're connected to have different security properties. For example, the layer 2 network security of a Wireless LAN network operated by an end user is in the control of the home user, whereas an LTE operator has control of the layer 2 security of the LTE access network. An external entity using lawful means, or through other means, obtains the security keys from the LTE operator, but the same may not be possible in the case of a Wireless LAN network operated by a home user. Therefore, grouping interfaces with such varying security properties into one logical interface could have negative consequences in some cases. Such differences, though subtle, are entirely hidden by logical interfaces and are unknown to the upper layers. 💔
8. References 📖
8.1. Normative References 💜
- [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>.
8.2. Informative References 📚✨
Okay bestie, these are the extra reading, the background and context sources 🫶
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<http://www.rfc-editor.org/info/rfc2863>.
[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>.
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007,
<http://www.rfc-editor.org/info/rfc5072>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
[RFC7864] Bernardos, CJ., Ed., "Proxy Mobile IPv6 Extensions to
Support Flow Mobility", RFC 7864, DOI 10.17487/RFC7864,
May 2016, <http://www.rfc-editor.org/info/rfc7864>.
[TS23401] 3rd Generation Partnership Project, "Technical
Specification Group Services and System Aspects; General
Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN)
access", TS 23.401, V13.6.0, March 2016.
[TS23402] 3rd Generation Partnership Project, "Technical
Specification Group Services and System Aspects;
Architecture enhancements for non-3GPP accesses", TS
23.402, V13.5.0, March 2016.Acknowledgements 🙌
The authors wanted to give a shoutout to everyone who chatted about this topic in the NETLMM and NETEXT working groups 💜 They also thanked Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj Patil, Peter McCann, Julien Laganier, Maximilian Riegel, Georgios Karagian, Stephen Farrell, and Benoit Claise for their input to the document 👑 The main character squad, no notes 💅
Contributors 🎀
These are the people who contributed to the document, listed in alphabetical order 🌸
Carlos Jesus Bernardos Cano
Email: cjbc@it.uc3m.es
Antonio De la Oliva
Email: aoliva@it.uc3m.es
Yong-Geun Hong
Email: yonggeun.hong@gmail.com
Kent Leung
Email: kleung@cisco.com
Tran Minh Trung
Email: trungtm2909@gmail.com
Hidetoshi Yokota
Email: yokota@kddilabs.jp
Juan Carlos Zuniga
Email: JuanCarlos.Zuniga@InterDigital.comAuthors' Addresses 🦋
And finally, who actually wrote this bad boy 🫶 Telemaco Melia was the editor, and Sri Gundavelli was the other editor 💖
Telemaco Melia (editor)
Kudelski Security
Geneva
Switzerland
Email: telemaco.melia@gmail.com
Sri Gundavelli (editor)
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States
Email: sgundave@cisco.com📦 where this page comes from
- ietf: rfc7847 2016-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms