1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
|
<pre>Internet Engineering Task Force (IETF) S. Kiesel
Request for Comments: 7723 University of Stuttgart
Category: Standards Track R. Penno
ISSN: 2070-1721 Cisco Systems, Inc.
January 2016
<span class="h1">Port Control Protocol (PCP) Anycast Addresses</span>
Abstract
The Port Control Protocol (PCP) anycast addresses enable PCP clients
to transmit signaling messages to their closest PCP-aware on-path
NAT, firewall, or other middlebox without having to learn the IP
address of that middlebox via some external channel. This document
establishes one well-known IPv4 address and one well-known IPv6
address to be used as PCP anycast addresses.
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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7723">http://www.rfc-editor.org/info/rfc7723</a>.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Kiesel & Penno Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7723">RFC 7723</a> PCP Anycast Addresses January 2016</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. PCP Server Discovery Based on Well-Known IP Address . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. PCP Discovery Client Behavior . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. PCP Discovery Server Behavior . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Deployment Considerations . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Registration of an IPv4 Special-Purpose Address . . . . . <a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Registration of an IPv6 Special-Purpose Address . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Information Leakage through Anycast . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Hijacking of PCP Messages Sent to Anycast Addresses . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6.1">6.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Port Control Protocol (PCP) [<a href="./rfc6887" title=""Port Control Protocol (PCP)"">RFC6887</a>] provides a mechanism to
control how incoming packets are forwarded by upstream devices such
as Network Address and Protocol Translation from IPv6 Clients to IPv4
Servers (NAT64), Network Address Translation from IPv4 to IPv4
(NAT44), and IPv6 and IPv4 firewall devices. Furthermore, it
provides a mechanism to reduce application keepalive traffic
[<a href="#ref-PCP-OPTIMIZE">PCP-OPTIMIZE</a>]. The PCP base protocol document [<a href="./rfc6887" title=""Port Control Protocol (PCP)"">RFC6887</a>] specifies
the message formats used, but the address to which a client sends its
request is either assumed to be the default router (which is
appropriate in a typical single-link residential network) or has to
be configured otherwise via some external mechanism, such as a
configuration file or a DHCP option [<a href="./rfc7291" title=""DHCP Options for the Port Control Protocol (PCP)"">RFC7291</a>].
This document follows a different approach: it establishes two well-
known anycast addresses for the PCP server, one IPv4 address and one
IPv6 address. PCP clients usually send PCP requests to these well-
known addresses if no other PCP server addresses are known or after
communication attempts to such other addresses have failed. The
anycast addresses are allocated from pools of special-purpose IP
addresses (see <a href="#section-4">Section 4</a>), in accordance with <a href="./rfc4085#section-3.4">Section 3.4 of
[RFC4085]</a>. Yet, a means to disable or override these well-known
addresses (e.g., a configuration file option) should be available in
implementations.
<span class="grey">Kiesel & Penno Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7723">RFC 7723</a> PCP Anycast Addresses January 2016</span>
Using an anycast address is particularly useful in larger network
topologies. For example, if the PCP-enabled NAT/firewall function is
not located on the client's default gateway but further upstream in a
Carrier-Grade NAT (CGN), sending PCP requests to the default
gateway's IP address will not have the desired effect. When using a
configuration file or the DHCP option to learn the PCP server's IP
address, this file or the DHCP server configuration must reflect the
network topology and the router and CGN configuration. This may be
cumbersome to achieve and maintain. If there is more than one
upstream CGN and traffic is routed using a dynamic routing protocol
such as OSPF, this approach may not be feasible at all, as it cannot
provide timely information regarding which CGN to interact with. In
contrast, when using the PCP anycast address, the PCP request will
travel through the network like any other packet (i.e., without any
special support from DNS, DHCP, other routers, or anything else)
until it reaches the PCP-capable device that receives it, handles it,
and sends back a reply. A further advantage of using an anycast
address instead of a DHCP option is that the anycast address can be
hard-coded into the application. There is no need for an application
programming interface that passes the PCP server's address from the
operating system's DHCP client to the application. For further
discussion of deployment considerations, see <a href="#section-3">Section 3</a>.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. PCP Server Discovery Based on Well-Known IP Address</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. PCP Discovery Client Behavior</span>
PCP clients can add the PCP anycast addresses, which are defined in
Sections <a href="#section-4.1">4.1</a> and <a href="#section-4.2">4.2</a>, after the default router list (for IPv4 and
IPv6) to the list of PCP server(s) (see step 2 in <a href="./rfc6887#section-8.1">Section 8.1 of
[RFC6887]</a>). This list is processed as specified in [<a href="./rfc7488" title=""Port Control Protocol (PCP) Server Selection"">RFC7488</a>].
Note: If, in some specific scenario, it was desirable to use only the
anycast address (and not the default router), this could be achieved
by putting the anycast address into the configuration file or DHCP
option.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. PCP Discovery Server Behavior</span>
PCP servers can be configured to listen on the anycast addresses for
incoming PCP requests. When a PCP server receives a PCP request
destined for an anycast address it supports, it sends the
corresponding PCP replies using that same anycast address as the
source address (see the "How UDP and TCP Use Anycasting" section of
[<a href="./rfc1546" title=""Host Anycasting Service"">RFC1546</a>] for further discussion).
<span class="grey">Kiesel & Penno Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7723">RFC 7723</a> PCP Anycast Addresses January 2016</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Deployment Considerations</span>
For general recommendations regarding operation of anycast services,
see [<a href="./rfc4786" title=""Operation of Anycast Services"">RFC4786</a>]. Architectural considerations of IP anycast are
discussed in [<a href="./rfc7094" title=""Architectural Considerations of IP Anycast"">RFC7094</a>].
In some deployment scenarios, using PCP anycasting may have certain
limitations that can be overcome by using additional mechanisms or by
using other PCP server discovery methods instead, such as DHCP
[<a href="./rfc7291" title=""DHCP Options for the Port Control Protocol (PCP)"">RFC7291</a>] or a configuration file.
One important example is a network topology in which a network is
connected to one or more upstream network(s) via several parallel
firewalls, each individually controlled by its own PCP server. Even
if all of these PCP servers are configured for anycasting, only one
will receive the messages sent by a given client, depending on the
state of the routing tables.
As long as routing is always symmetric, i.e., all upstream and
downstream packets from/to that client are routed through this very
same firewall, communication will be possible as expected. If there
is a routing change, a PCP client using PCP anycasting might start
interacting with a different PCP server. From the PCP client's point
of view, this would be the same as a PCP server reboot and the client
could detect it by examining the Epoch field during the next PCP
response or ANNOUNCE message. The client would re-establish the
firewall rules and packet flows could resume.
If, however, routing is asymmetric, upstream packets from a client
traverse a different firewall than the downstream packets to that
client. Establishing policy rules in only one of these two firewalls
by means of PCP anycasting will not have the desired result of
allowing bidirectional connectivity. One solution approach to
overcome this problem is an implementation-specific mechanism to
synchronize state between all firewalls at the border of a network,
i.e., a PEER message sent to any of these PCP servers would establish
rules in all firewalls. Another approach would be to use a different
discovery mechanism (e.g., DHCP or a configuration file) that allows
a PCP client to acquire a list of all PCP servers controlling the
parallel firewalls and configure each of them individually.
PCP anycast as such allows a PCP client to communicate only with its
closest upstream PCP server. However, it may be used in conjunction
with the PCP proxy function [<a href="./rfc7648" title=""Port Control Protocol (PCP) Proxy Function"">RFC7648</a>], in order to support scenarios
with cascaded PCP-enabled NATs or firewalls.
<span class="grey">Kiesel & Penno Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7723">RFC 7723</a> PCP Anycast Addresses January 2016</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Registration of an IPv4 Special-Purpose Address</span>
IANA has assigned a single IPv4 address from the 192.0.0.0/24 prefix
and registered it in the "IANA IPv4 Special-Purpose Address Registry"
[<a href="./rfc6890" title=""Special-Purpose IP Address Registries"">RFC6890</a>].
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 192.0.0.9/32 |
| Name | Port Control Protocol Anycast |
| RFC | <a href="./rfc7723">RFC 7723</a> (this document) |
| Allocation Date | October 2015 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Registration of an IPv6 Special-Purpose Address</span>
IANA has assigned a single IPv6 address from the 2001:0000::/23
prefix and registered it in the "IANA IPv6 Special-Purpose Address
Registry" [<a href="./rfc6890" title=""Special-Purpose IP Address Registries"">RFC6890</a>].
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 2001:1::1/128 |
| Name | Port Control Protocol Anycast |
| RFC | <a href="./rfc7723">RFC 7723</a> (this document) |
| Allocation Date | October 2015 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
<span class="grey">Kiesel & Penno Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7723">RFC 7723</a> PCP Anycast Addresses January 2016</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
In addition to the security considerations in [<a href="./rfc6887" title=""Port Control Protocol (PCP)"">RFC6887</a>], [<a href="./rfc4786" title=""Operation of Anycast Services"">RFC4786</a>],
and [<a href="./rfc7094" title=""Architectural Considerations of IP Anycast"">RFC7094</a>], two further security issues are considered here.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Information Leakage through Anycast</span>
In a network without any border gateway, NAT, or firewall that is
aware of the PCP anycast address, outgoing PCP requests could leak
out onto the external Internet, possibly revealing information about
internal devices.
Using an IANA-assigned, well-known PCP anycast address enables border
gateways to block such outgoing packets. In the default-free zone,
routers should be configured to drop such packets. Such
configuration can occur naturally via BGP messages advertising that
no route exists to said address.
Sensitive clients that do not wish to leak information about their
presence can set an IP TTL on their PCP requests that limits how far
they can travel towards the public Internet. However, methods for
choosing an appropriate TTL value, e.g., based on the assumed radius
of the trusted network domain, is beyond the scope of this document.
Before sending PCP requests with possibly privacy-sensitive
parameters (e.g., IP addresses and port numbers) to the PCP anycast
addresses, PCP clients can send an ANNOUNCE request (without
parameters; see <a href="./rfc6887#section-14.1">Section 14.1 of [RFC6887]</a>) in order to probe whether
a PCP server consumes and processes PCP requests sent to that anycast
address.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Hijacking of PCP Messages Sent to Anycast Addresses</span>
The anycast addresses are treated by normal host operating systems as
normal unicast addresses, i.e., packets destined for an anycast
address are sent to the default router for processing and forwarding.
Hijacking such packets in the first network segment would effectively
require the attacker to impersonate the default router, e.g., by
means of ARP spoofing in an Ethernet network. Once an anycast
message is forwarded closer to the core network, routing will likely
become subject to dynamic routing protocols such as OSPF or BGP.
Anycast messages could be hijacked by announcing counterfeited
messages in these routing protocols. When analyzing the risk and
possible consequences of such attacks in a given network scenario,
the probable impacts on PCP signaling need to be put into proportion
with probable impacts on other protocols such as the actual
application protocols.
<span class="grey">Kiesel & Penno Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7723">RFC 7723</a> PCP Anycast Addresses January 2016</span>
In addition to following best current practices in first-hop security
and routing-protocol security, PCP authentication [<a href="./rfc7652" title=""Port Control Protocol (PCP) Authentication Mechanism"">RFC7652</a>] may be
useful in some scenarios. However, the effort needed for a proper
setup of this authentication mechanism (e.g., installing the right
shared secrets or cryptographic keys on all involved systems) may
thwart the goal of fully automatic configuration by using PCP
anycast. Therefore, this approach may be less suitable for scenarios
with high trust between the operator of the PCP-controlled middlebox
and all users (e.g., a residential gateway used only by family
members) or in scenarios in which there is rather limited trust that
the middlebox will behave correctly (e.g., the Wi-Fi in an airport
lounge). In contrast, this scheme may be highly useful in scenarios
with many users and a trusted network operator, such as a large
corporate network or a university campus network, which uses several
parallel NATs or firewalls to connect to the Internet. Therefore, a
thorough analysis of the benefits and costs of using PCP
authentication in a given network scenario is recommended.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC6887">RFC6887</a>] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", <a href="./rfc6887">RFC 6887</a>,
DOI 10.17487/RFC6887, April 2013,
<<a href="http://www.rfc-editor.org/info/rfc6887">http://www.rfc-editor.org/info/rfc6887</a>>.
[<a id="ref-RFC6890">RFC6890</a>] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", <a href="https://www.rfc-editor.org/bcp/bcp153">BCP 153</a>,
<a href="./rfc6890">RFC 6890</a>, DOI 10.17487/RFC6890, April 2013,
<<a href="http://www.rfc-editor.org/info/rfc6890">http://www.rfc-editor.org/info/rfc6890</a>>.
[<a id="ref-RFC7488">RFC7488</a>] Boucadair, M., Penno, R., Wing, D., Patil, P., and T.
Reddy, "Port Control Protocol (PCP) Server Selection",
<a href="./rfc7488">RFC 7488</a>, DOI 10.17487/RFC7488, March 2015,
<<a href="http://www.rfc-editor.org/info/rfc7488">http://www.rfc-editor.org/info/rfc7488</a>>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-PCP-OPTIMIZE">PCP-OPTIMIZE</a>]
Reddy, T., Patil, P., Isomaki, M., and D. Wing,
"Optimizing NAT and Firewall Keepalives Using Port Control
Protocol (PCP)", Work in Progress,
<a href="./draft-ietf-pcp-optimize-keepalives-06">draft-ietf-pcp-optimize-keepalives-06</a>, May 2015.
[<a id="ref-RFC1546">RFC1546</a>] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", <a href="./rfc1546">RFC 1546</a>, DOI 10.17487/RFC1546,
November 1993, <<a href="http://www.rfc-editor.org/info/rfc1546">http://www.rfc-editor.org/info/rfc1546</a>>.
<span class="grey">Kiesel & Penno Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7723">RFC 7723</a> PCP Anycast Addresses January 2016</span>
[<a id="ref-RFC4085">RFC4085</a>] Plonka, D., "Embedding Globally-Routable Internet
Addresses Considered Harmful", <a href="https://www.rfc-editor.org/bcp/bcp105">BCP 105</a>, <a href="./rfc4085">RFC 4085</a>,
DOI 10.17487/RFC4085, June 2005,
<<a href="http://www.rfc-editor.org/info/rfc4085">http://www.rfc-editor.org/info/rfc4085</a>>.
[<a id="ref-RFC4786">RFC4786</a>] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", <a href="https://www.rfc-editor.org/bcp/bcp126">BCP 126</a>, <a href="./rfc4786">RFC 4786</a>, DOI 10.17487/RFC4786,
December 2006, <<a href="http://www.rfc-editor.org/info/rfc4786">http://www.rfc-editor.org/info/rfc4786</a>>.
[<a id="ref-RFC7094">RFC7094</a>] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", <a href="./rfc7094">RFC 7094</a>,
DOI 10.17487/RFC7094, January 2014,
<<a href="http://www.rfc-editor.org/info/rfc7094">http://www.rfc-editor.org/info/rfc7094</a>>.
[<a id="ref-RFC7291">RFC7291</a>] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
the Port Control Protocol (PCP)", <a href="./rfc7291">RFC 7291</a>,
DOI 10.17487/RFC7291, July 2014,
<<a href="http://www.rfc-editor.org/info/rfc7291">http://www.rfc-editor.org/info/rfc7291</a>>.
[<a id="ref-RFC7648">RFC7648</a>] Perreault, S., Boucadair, M., Penno, R., Wing, D., and S.
Cheshire, "Port Control Protocol (PCP) Proxy Function",
<a href="./rfc7648">RFC 7648</a>, DOI 10.17487/RFC7648, September 2015,
<<a href="http://www.rfc-editor.org/info/rfc7648">http://www.rfc-editor.org/info/rfc7648</a>>.
[<a id="ref-RFC7652">RFC7652</a>] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port
Control Protocol (PCP) Authentication Mechanism",
<a href="./rfc7652">RFC 7652</a>, DOI 10.17487/RFC7652, September 2015,
<<a href="http://www.rfc-editor.org/info/rfc7652">http://www.rfc-editor.org/info/rfc7652</a>>.
Acknowledgements
The authors would like to thank the members of the PCP working group
for contributions and feedback, in particular, Mohamed Boucadair,
Charles Eckel, Simon Perreault, Tirumaleswar Reddy, Markus Stenberg,
Dave Thaler, and Dan Wing.
<span class="grey">Kiesel & Penno Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7723">RFC 7723</a> PCP Anycast Addresses January 2016</span>
Authors' Addresses
Sebastian Kiesel
University of Stuttgart Information Center
Networks and Communication Systems Department
Allmandring 30
Stuttgart 70550
Germany
Email: ietf-pcp@skiesel.de
Reinaldo Penno
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
United States
Email: repenno@cisco.com
Kiesel & Penno Standards Track [Page 9]
</pre>
|
