RFC 6957
Duplicate Address Detection Proxy
RFC 6957: Duplicate Address Detection Proxy 🎀
Okay bestie, we're starting with RFC 6957, which is a Standards Track document from June 2013 (ISSN 2070-1721). The main authors are F. Costa, J-M. Combes (the editor, so "Ed."), X. Pougnard from France Telecom Orange, and H. Li from Huawei Technologies. The title block doesn't have an Obsoletes or Updates line, so this one doesn't list anything it replaces or changes. 💅✨
Internet Engineering Task Force (IETF) F. Costa
Request for Comments: 6957 J-M. Combes, Ed.
Category: Standards Track X. Pougnard
ISSN: 2070-1721 France Telecom Orange
H. Li
Huawei Technologies
June 2013Abstract
Okay so the vibe here is a proxy-based mechanism that lets IPv6 nodes actually use Duplicate Address Detection (DAD) in a point-to-multipoint setup that runs a "split-horizon" forwarding scheme 🦋. It's mostly meant for DSL and Fiber access networks.
Here's the tea: the first-hop router keeps a Binding Table of every IPv6 address already in use on the point-to-multipoint domain (think a VLAN, for example). When a node runs DAD for an address somebody else already has, the first-hop router is the one that defends that address, not the device that's using it. Iconic protection energy 👑
Status of This Memo
This is an Internet Standards Track document 💖.
It's a product of the Internet Engineering Task Force (IETF), so it reflects what the IETF community agrees on. It got public review and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more info on Internet Standards, check out Section 2 of RFC 5741 🌸.
You can find the current status of this document, any errata, and where to send feedback at http://www.rfc-editor.org/info/rfc6957 🧚.
Copyright Notice
Copyright (c) 2013 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) as they were in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Any Code Components pulled out of this document 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Why Existing IETF Solutions Are Not Sufficient . . . . . . . 4
3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 4
3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . 5
3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . 5
3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6
4. Duplicate Address Detection Proxy (DAD-Proxy) Specifications 6
4.1. DAD-Proxy Data Structure . . . . . . . . . . . . . . . . 6
4.2. DAD-Proxy Mechanism . . . . . . . . . . . . . . . . . . . 7
4.2.1. No Entry Exists for the Tentative Address . . . . . . 7
4.2.2. An Entry Already Exists for the Tentative Address . . 7
4.2.3. Confirmation of Reachability to Check the Validity of
the Conflict . . . . . . . . . . . . . . . . . . . . 9
5. Manageability Considerations . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Interoperability with SEND . . . . . . . . . . . . . . . 11
6.2. Protection against IP Source Address Spoofing . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. DAD-Proxy State Machine . . . . . . . . . . . . . . 141. Introduction ✨
Okay so this document defines a function called Duplicate Address Detection (DAD) proxy. It lets the nodes on a point-to-multipoint domain use DAD even though that domain runs a "split-horizon" forwarding scheme 🎀. It's mainly for DSL and Fiber access architectures [TR-101]. The proxy only affects the first-hop router, so you don't have to change any of the other IPv6 nodes, which is so easy 🫶. It's fully effective when every node in the point-to-multipoint domain (other than the DAD proxy itself) does DAD.
This document also explains why plain DAD [RFC4862], the version without a proxy, can't work in a point-to-multipoint setup with split-horizon forwarding. IPv6 over PPP [RFC5072] is not affected, though 🦋. The big reason is that, because of how the forwarding works, IPv6 nodes on the same point-to-multipoint domain can't talk to each other directly. Any communication between them has to go through the first-hop router for that domain 🙈.
We're assuming here that link-layer addresses on a point-to-multipoint domain are unique from the first-hop router's point of view. For example, on an untrusted Ethernet architecture, this can be guaranteed by mechanisms like Media Access Control (MAC) address translation, which an aggregation device does between the IPv6 nodes and the first-hop router 💜.
1.1. Requirements Language
Here's the vocab part 💅. 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 RFC 2119 [RFC2119].
2. Background 🌈
Terminology here follows "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and "IPv6 Stateless Address Autoconfiguration" [RFC4862]. On top of that, this section defines some extra terms for DSL and Fiber access architectures. Those are the big use case where this solution works 🍓.
- Customer Premises Equipment (CPE): The first IPv6 node in a customer's network 🏠.
- Access Node (AN): The first aggregation point in the public access network. This document treats it as an L2 bridge 🌉.
- Broadband Network Gateway (BNG): The first-hop router from the CPE's point of view 👑.
- VLAN N:1 architecture: A point-to-multipoint architecture where lots of CPEs connect to the same VLAN. The CPEs can be on the same Access Node or on different ones 🧚.
- split-horizon model: A forwarding scheme where CPEs can't do direct layer 2 communication with each other. IP flows have to go through the BNG via routing instead 🙅♀️.
Here's where all those entities live, based on the definitions above:
+------+ +----+
| CPE3 |---------| AN |
+------+ +----+
|
|
+------+ +----+
| CPE2 |---------| AN |---+
+------+ +----+ |
+------+ | |
| CPE1 |------------+ |
+------+ +-----+
| BNG |--- Internet
+-----+
Figure 1: DSL and Fiber Access Architecture3. Why Existing IETF Solutions Are Not Sufficient 🙈
In the DSL or Fiber access architecture from Figure 1, CPE1, CPE2, CPE3, and the BNG are all IPv6 nodes. The AN is an L2 bridge that connects the BNG to each CPE. The AN enforces a split-horizon model, so CPEs can only send and receive frames (like Ethernet frames) to and from the BNG, not to each other 😭. Even so, the BNG is on the same link with every CPE, but a given CPE isn't on the same link as any other CPE.
3.1. Duplicate Address Detection
Duplicate Address Detection (DAD) [RFC4862] runs when an IPv6 node checks whether a tentative IPv6 address is unique. That node sends a Neighbor Solicitation (NS) message, with the IP destination set to the solicited-node multicast address of the tentative address 🔍.
The NS message gets multicast to the other nodes on the same link. If another node on the link is already using the tentative address, that node replies with a Neighbor Advertisement (NA) message to let the first node know. So when a node does DAD, it expects the NS messages to reach every node that's currently using the tentative address 💖.
But in a point-to-multipoint network with a split-horizon forwarding scheme in the AN, the CPEs can't talk to each other directly. Every packet a CPE sends goes from the AN to the BNG only, not to any other CPE. NS messages from one CPE only reach the BNG and never get to the other CPEs. So the other CPEs have no clue that a certain IPv6 address is in use by another CPE 🫠. That means that in a split-horizon network, DAD as defined in [RFC4862] can't work properly without some extra help 💀.
3.2. Neighbor Discovery Proxy
The Neighbor Discovery (ND) Proxy [RFC4389] is built for forwarding ND messages between different IP links that share the same subnet prefix. An ND Proxy function on a bridge makes sure packets between nodes on different segments get received by that function and have the correct link-layer address type on each segment 🌸. When the ND Proxy gets a multicast ND message, it forwards it to every other interface on the same link.
In a DSL or Fiber network, when the AN acts as an ND Proxy and gets an ND message from a CPE, it forwards that message to the BNG and none of the other CPEs, since only the BNG shares a link with that CPE 🙃. So putting ND Proxy on the AN wouldn't help a CPE find out about link-local addresses used by other CPEs.
The BNG must not forward link-local scoped messages from one CPE to other CPEs, so ND Proxy can't be implemented in the BNG either 🚫.
3.3. 6LoWPAN Neighbor Discovery
[RFC6775] defines an optional change to DAD for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) 🐝. When a 6LoWPAN node wants to configure an IPv6 address, it registers that address with one or more of its default routers using the Address Registration Option (ARO). If another node already owns that address, the router tells the 6LoWPAN node that it can't configure the address.
This mechanism needs changes in all hosts so they can support the ARO 🥲.
3.4. IPv6 Mobility Manager
According to [RFC6275], a home agent acts as a proxy for mobile nodes when they're away from the home network. The home agent defends a mobile node's home address by replying to NS messages with NA messages 🏡.
This has a problem if it's applied in a DSL or Fiber public access network. Operators of those networks require that an NA message only gets received by the sender of the matching NS message, for security and scalability reasons 🔐. But the home agent per [RFC6275] multicasts NA messages on the home link, so every node on that link receives them. That shortcoming stops this mechanism from being deployed directly in DSL or Fiber access networks 😤.
4. Duplicate Address Detection Proxy (DAD-Proxy) Specifications ✨
First things first: this mechanism is strongly based on DAD [RFC4862], so it isn't completely reliable. The goal of this document is not to fix DAD itself 🧁.
4.1. DAD-Proxy Data Structure 🗂️
okay so the BNG needs to keep a Binding Table 📋 with info about the IPv6 addresses each CPE generates 🏠. This table can be totally separate from the Neighbor Cache 🧠, and it has to be kept per point-to-multipoint domain (think one per Ethernet VLAN 🎀). Every entry MUST contain these fields:
IPv6 AddressLink-layer Address
For security or performance reasons, it must be possible to limit how many IPv6 addresses can sit behind one link-layer address (possibly, but not necessarily, to 1) 🔒.
When the BNG gets an unsolicited NA 📣 (like when a CPE wants to tell its neighbors about a new link-layer address) for an IPv6 address that's already in the Binding Table, every entry tied to that address MUST be updated accordingly ✨. The current link-layer address gets swapped out for the one in the unsolicited NA message.
Now the size stuff 🙈. For security or performance reasons, the Binding Table MUST be big enough for the deployment it's used in. If it's separate from the Neighbor Cache, it MUST be at least as big as that one. Implementations MUST either state the fixed size of the Binding Table they support, or make the size configurable. If it's configurable, implementations MUST state the largest size they support. Implementations SHOULD also let an operator check the current occupancy level, so they can tell if the table is about to get full 👀. A full Binding Table will likely be handled in a way similar to NS message loss 💀.
It is recommended to apply technical solutions that minimize the risk of the Binding Table filling up 🧹. Those solutions are out of scope for this document 🫶.
4.2. DAD-Proxy Mechanism 🦋
ok so when a CPE does DAD, as specified in [RFC4862], it sends a Neighbor Solicitation (NS) message with the unspecified address as the source address 🌸. It does this to check whether a tentative address is already in use on the link. The BNG receives this message and MUST perform the actions in the following sections, based on what's in the Binding Table 📋.
4.2.1. No Entry Exists for the Tentative Address 🆕
if there's no entry for the tentative address, the BNG MUST create one with this info:
IPv6 Addressfield set to the tentative address in the NS message.Link-layer Addressfield set to the link-layer source address in the link-layer header of the NS message.
The BNG MUST NOT reply to the CPE or forward the NS message 🙅♀️.
4.2.2. An Entry Already Exists for the Tentative Address 👀
if there IS an entry for the tentative address, the BNG MUST check these conditions:
- The address in the Target Address field in the NS message is equal to the address in the
IPv6 Addressfield in the entry. - The source address of the IPv6 Header in the NS message is equal to the unspecified address.
When both of those are met AND the source address of the link-layer header in the NS message is equal to the address in the Link-layer Address field in the entry, that means the CPE is still doing DAD for this address 🐣. The BNG MUST NOT reply to the CPE or forward the NS message.
When both conditions are met but the link-layer source address does NOT match the Link-layer Address in the entry, that means maybe another CPE is doing DAD for an address that's already owned 😳. The BNG then has to check whether there's a real conflict, by seeing if the CPE whose IPv6 address is in the entry is still connected 🔎. From here on, we'll call:
IPv6-CPE1: the IPv6 address of the existing entry in the Binding TableLink-layer-CPE1: the link-layer address of that entryLink-layer-CPE2: the link-layer address of the CPE performing DAD, which is different fromLink-layer-CPE1
The BNG MUST check if the potential address conflict is real 🕵️♀️. In particular:
- If
IPv6-CPE1is in the Neighbor Cache and it's associated withLink-layer-CPE1, the reachability ofIPv6-CPE1MUST be confirmed as explained in Section 4.2.3. - If
IPv6-CPE1is in the Neighbor Cache, but in that cache it's associated with a link-layer address other thanLink-layer-CPE1, that means there's possibly a conflict with another CPE, but that CPE did not perform DAD 🤔. This situation is out of scope for this document, since one assumption made above is that all the nodes of a point-to-multipoint domain (except the DAD proxy itself) perform DAD. - If
IPv6-CPE1is NOT in the Neighbor Cache, then the BNG MUST create a new entry based on the info in the entry in the Binding Table 🛠️. This step is needed so the reachability check described in Section 4.2.3 gets triggered. The entry in the Neighbor Cache MUST be created based on the algorithm defined in Section 7.3.3 of [RFC4861], in particular by treating this case as though a packet other than a solicited Neighbor Advertisement were received fromIPv6-CPE1. So the new Neighbor Cache entry MUST contain the following info:- IPv6 address:
IPv6-CPE1 - Link-layer address:
Link-layer-CPE1 - State:
STALE
- IPv6 address:
The reachability of IPv6-CPE1 MUST be confirmed as soon as possible, following the procedure in Section 4.2.3 ⚡.
4.2.3. Confirmation of Reachability to Check the Validity of the Conflict 🔍
so since IPv6-CPE1 is in an entry of the Neighbor Cache, its reachability is checked using the Neighbor Unreachability Detection (NUD) mechanism described in Section 7.3.1 of [RFC4861]. This mechanism MUST be triggered as though a packet had to be sent to IPv6-CPE1. Heads up, though: in some cases this mechanism doesn't actually do anything 🤷♀️. For instance, if the entry's state is REACHABLE and a positive confirmation was recently received that the forward path to IPv6-CPE1 was working properly (see RFC 4861 for more details), then this mechanism does nothing.
Next, what the BNG does depends on the result of the NUD process, as explained in the following sections 💅.
4.2.3.1. The Result of the NUD Process is Negative 🙃
if the NUD result is negative (aka this process removes IPv6-CPE1 from the Neighbor Cache), that means the potential conflict is NOT real 🎉.
The conflicting entry in the Binding Table (Link-layer-CPE1) gets deleted, and it's replaced by a new entry with the same IPv6 address, but with the link-layer address of the CPE performing DAD (Link-layer-CPE2), as explained in Section 4.2.1 💖.
4.2.3.2. The Result of the NUD Process is Positive 😤
if the NUD result is positive (aka after this process the state of IPv6-CPE1 is REACHABLE), that means the potential conflict IS real 🚨.
As shown in Figure 2, the BNG MUST reply to the CPE that's performing DAD (CPE2 in Figure 1) with an NA message in the following format 📨:
Layer 2 Header Fields:
Source Address
The link-layer address of the interface on which the BNG
received the NS message.
Destination Address
The source address in the Layer 2 Header of the NS
message received by the BNG (i.e., Link-layer-CPE2).
IPv6 Header Fields:
Source Address
An address assigned to the interface from which the
advertisement is sent.
Destination Address
The all-nodes multicast address.
ICMPv6 Fields:
Target Address
The tentative address already used (i.e., IPv6-CPE1).
Target Link-layer Address
The link-layer address of the interface on which the BNG
received the NS message.Here's the vibe in Figure 2 🎨:
CPE1 CPE2 BNG
| | |
(a)| | |
| | |
(b)|===================>|
| | |(c)
| | |
| (d)| |
| | |
| (e)|=========>|
| | |
| |<=========|(f)
| | |
(a) CPE1 generates a tentative address
(b) CPE1 performs DAD for this one
(c) BNG updates its Binding Table
(d) CPE2 generates a same tentative address
(e) CPE2 performs DAD for this one
(f) BNG informs CPE2 that DAD fails
Figure 2: DAD FailureThe BNG and the CPE MUST support unicast transmission, on the link layer, of IPv6 multicast messages [RFC6085], so they can generate and process that packet format respectively 🧚.
5. Manageability Considerations 🛎️
The BNG SHOULD support a mechanism to log and emit alarms whenever a duplication of IPv6 addresses is detected by the DAD-Proxy function 🚨. The BNG SHOULD also implement a function that lets an operator access logs and see the current entries in the Binding Table 👑. Managing access rights to get this info is out of scope for this document 🔐.
6. Security Considerations 💀
6.1. Interoperability with SEND 🙈
this one's serious, bestie 😭. The mechanism described in this document will NOT interoperate with SEcure Neighbor Discovery (SEND) [RFC3971]. The reason is that the BNG doesn't own the private key associated with the Cryptographically Generated Address (CGA) [RFC3972], which is needed to correctly sign the proxied ND messages [RFC5909].
Secure Proxy ND Support for SEND [RFC6496] was specified to fix this limitation, and it SHOULD be implemented and used on the BNG and the CPEs 🫶🔐.
6.2. Protection against IP Source Address Spoofing 🕵️♀️
to protect against IP source address spoofing in data packets, this proposal can be combined with Source Address Validation Improvement (SAVI) mechanisms [RFC6620] [SAVI-SEND] [SAVI-MIX] 🛡️.
If SAVI mechanisms are used, the SAVI device is the BNG, and the Binding Anchor for a CPE is its MAC address, which is assumed to be unique in this document (cf. Section 1) 🎀.
7. Acknowledgments 💜
big thank you to Alan Kavanagh, Wojciech Dec, Suresh Krishnan, and Tassos Chatzithomaoglou for their comments 🥹. The authors would also like to thank the IETF 6man WG members and the BBF community for their support 🌈.
8. References ✨
8.1. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
"Address Mapping of IPv6 Multicast Packets on Ethernet",
RFC 6085, January 2011.8.2. Informative References 📚
okay bestie, these are the "extra reading" refs 🤓 nothing here is strictly required to implement this, but they're the vibes that the spec is built on. ✨
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
over PPP", RFC 5072, September 2007.
[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing
Neighbor Discovery Proxy: Problem Statement", RFC 5909,
July 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
Martinez, "Secure Proxy ND Support for SEcure Neighbor
Discovery (SEND)", RFC 6496, February 2012.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC
6620, May 2012.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, November 2012.
[SAVI-MIX] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, Ed.,
"SAVI for Mixed Address Assignment Methods Scenario",
Work in Progress, May 2013.
[SAVI-SEND] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-
Address Validation Implementation", Work in Progress,
April 2013.
[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL
Aggregation", Issue 2, Technical Report TR-101, July
2011, `http://www.broadband-forum.org/technical/download/TR-101_Issue-2.pdf`.Appendix A. DAD-Proxy State Machine 🦋
this appendix is informative 💅 it's basically a cheat sheet summarising what the BNG does when it gets a DAD-based NS (DAD-NS) message. the tentative address in this message is IPv6-CPE1 and the associated link-layer address is Link-layer-CPE2. the full, precise rules live in Section 4.2, so if you want the receipts, go there 🧾
+------------+--------------------+--------------------+------------+
| Event | Check | Action | New event |
+------------+--------------------+--------------------+------------+
| DAD-NS | * No entry for | Create an entry | - |
| message | IPv6-CPE1 in the | for IPv6-CPE1 | |
| reception. | Binding Table. | bound to Link- | |
| | | layer-CPE2 in the | |
| | | Binding Table. | |
| | * Entry for | - | Existing |
| | IPv6-CPE1 in the | | entry. |
| | Binding Table. | | |
| | | | |
| Existing | * Link-layer-CPE2 | - | - |
| entry. | bound to IPv6-CPE1 | | |
| | in the Binding | | |
| | Table. | | |
| | * Another link- | - | Conflict? |
| | layer address, | | |
| | Link-layer-CPE1, | | |
| | bound to IPv6-CPE1 | | |
| | in the Binding | | |
| | Table. | | |
| | | | |
| Conflict? | * IPv6-CPE1 | - | Reachable? |
| | associated to | | |
| | Link-layer-CPE1 in | | |
| | the Neighbor | | |
| | Cache. | | |
| | * IPv6-CPE1 | Out of scope. | - |
| | associated to | | |
| | another link-layer | | |
| | address than Link- | | |
| | layer-CPE1 in the | | |
| | Neighbor Cache. | | |
| | * IPv6-CPE1 is not | Create an entry | Reachable? |
| | in the Neighbor | for IPv6-CPE1 | |
| | Cache. | associated to | |
| | | Link-layer-CPE1 in | |
| | | the Neighbor | |
| | | Cache. | |
| Reachable? | * NUD process is | IPv6-CPE2 is bound | - |
| | negative. | to Link-layer- | |
| | | CPE2, instead to | |
| | | Link-layer-CPE1, | |
| | | in the Binding | |
| | | Table. | |
| | * NUD process is | A NA message is | - |
| | positive. | sent. | |
+------------+--------------------+--------------------+------------+
Table 1: DAD-Proxy State MachineAuthors' Addresses 🎀
meet the squad who wrote this! 💖
Fabio Costa
France Telecom Orange
61 rue des Archives
75141 Paris Cedex 03
France
EMail: fabio.costa@orange.comJean-Michel Combes (editor)
France Telecom Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
EMail: jeanmichel.combes@orange.comXavier Pougnard
France Telecom Orange
2 avenue Pierre Marzin
22300 Lannion
France
EMail: xavier.pougnard@orange.comHongyu Li
Huawei Technologies
Huawei Industrial Base
Shenzhen
China
EMail: lihy@huawei.com📦 where this page comes from
- ietf: rfc6957 2013-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms