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
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>Internet Engineering Task Force (IETF) P. Duffy
Request for Comments: 6345 Cisco
Category: Standards Track S. Chakrabarti
ISSN: 2070-1721 Ericsson
R. Cragie
PG&E
Y. Ohba, Ed.
Toshiba
A. Yegin
Samsung
August 2011
<span class="h1">Protocol for Carrying Authentication for Network Access (PANA)</span>
<span class="h1">Relay Element</span>
Abstract
This document specifies Protocol for carrying Authentication for
Network Access (PANA) Relay Element functionality, which enables PANA
messaging between a PANA Client (PaC) and a PANA Authentication Agent
(PAA) where the two nodes cannot reach each other by means of regular
IP routing.
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/rfc6345">http://www.rfc-editor.org/info/rfc6345</a>.
<span class="grey">Duffy, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
Copyright Notice
Copyright (c) 2011 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Specification of Requirements ..............................<a href="#page-3">3</a>
<a href="#section-2">2</a>. PANA Relay Element ..............................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Security of Messages Sent between PRE and PAA ...................<a href="#page-5">5</a>
<a href="#section-4">4</a>. PANA Messages for Relay Operation ...............................<a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. PANA-Relay .................................................<a href="#page-7">7</a>
<a href="#section-5">5</a>. PANA AVPs for Relay Operation ...................................<a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. PaC-Information AVP ........................................<a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. Relayed-Message AVP ........................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-10">10</a>
<a href="#section-8">8</a>. Acknowledgments ................................................<a href="#page-10">10</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-10">10</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-10">10</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Protocol for carrying Authentication for Network Access (PANA)
[<a href="./rfc5191" title=""Protocol for Carrying Authentication for Network Access (PANA)"">RFC5191</a>] is a UDP-based protocol to perform Extensible
Authentication Protocol (EAP) authentication between a PANA Client
(PaC) and a PANA Authentication Agent (PAA).
This document specifies PANA Relay Element (PRE) functionality, which
enables PANA messaging between a PaC and a PAA where the two nodes
cannot reach each other by means of regular IP routing. For example,
in ZigBee IP [<a href="#ref-ZIGBEEIP" title=""ZigBee IP Specification"">ZIGBEEIP</a>] that uses 6LoWPAN [<a href="./rfc4944" title=""Transmission of IPv6 Packets over IEEE 802.15.4 Networks"">RFC4944</a>], a joining node
(PaC) can only use a link-local IPv6 address to communicate with a
parent node prior to PANA authentication. The PAA typically resides
in a 6LowPAN Border Router (6LBR) [<a href="#ref-6LoWPAN-ND" title=""Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)"">6LoWPAN-ND</a>], which is often
<span class="grey">Duffy, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
multiple IP hops away from the PaC. The PRE implemented on the
parent node is used for relaying PANA messages between the PaC and
the PAA in this scenario.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Specification of Requirements</span>
In this document, several words are used to signify the requirements
of the specification. These words are capitalized. 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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. PANA Relay Element</span>
A PANA Relay Element (PRE) is a node that is located between a PaC
and a PAA. It is responsible for relaying the PANA messages between
the PaC and the PAA. The PRE does not need to maintain per-PaC
state. From the PaC's perspective, the PRE appears as the PAA.
Normal IP routing is performed between the PRE and the PAA. A PAA
can communicate with multiple PREs. A PRE can communicate with
multiple PAAs, and it will choose one PAA to communicate with for a
given PaC. By default, the PaC discovers the PRE using the normal
mechanism for PAA discovery as defined in [<a href="./rfc5192" title=""DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents"">RFC5192</a>]. PREs are
assumed to be configured with the IP address(es) of the PAA(s).
Dynamic PAA discovery schemes for PREs are outside the scope of this
document.
The PRE and the PAA support the relay operation as follows.
When the PRE receives a PANA message from the PaC, it creates a PANA-
Relay (PRY) message (see <a href="#section-4.1">Section 4.1</a>) containing a Relayed-Message
AVP (see <a href="#section-5.2">Section 5.2</a>) and a PaC-Information AVP (see <a href="#section-5.1">Section 5.1</a>).
The Relayed-Message AVP encapsulates the entire PANA Message received
from the PaC. The PaC-Information AVP contains the PaC's IP address
and UDP port number used for sending the PANA messages. The PRY
message is sent to the PAA.
When the PAA receives the PRY message, it retrieves the PaC-
originated PANA message from the Relayed-Message AVP and the PaC's IP
address and UDP port number from the PaC-Information AVP. The PaC-
originated PANA message is processed in the same way as specified in
[<a href="./rfc5191" title=""Protocol for Carrying Authentication for Network Access (PANA)"">RFC5191</a>], with the following exceptions:
(a) The IP address and the port number contained in the PaC-
Information AVP and the source IP address and UDP port number of
the PRE are used to identify the PaC among multiple PANA-Client-
Initiation messages sent from different PaCs through the same PRE
<span class="grey">Duffy, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
or sent from more than one PaC with the same the IP address and
the port number through different PREs.
(b) The IP address and the port number contained in the PaC-
Information AVP are maintained by the PAA in the PANA session
attribute "IP address and UDP port number of the PaC" [<a href="./rfc5191" title=""Protocol for Carrying Authentication for Network Access (PANA)"">RFC5191</a>].
(c) The IP address and UDP port number of the PRE are maintained by
the PAA in a new PANA session attribute "IP address and UDP port
number of the PRE". A PANA session is referred to as a relayed
PANA session if this attribute has a non-null value.
When the PAA originates a PANA message for a relayed PANA session, it
sends a PRY message to the PRE's IP address and sets the destination
UDP port number to the UDP port number of the PRE maintained in the
PANA session attribute "IP address and UDP port number of the PRE".
The PRY message includes a Relayed-Message AVP containing the PAA-
originated PANA message and also includes a PaC-Information AVP
containing the PaC's IP address and UDP port number.
When the PRE receives the PRY message, it retrieves the PAA-
originated PANA message from the Relayed-Message AVP and the PaC's IP
address and UDP port number from and PaC-Information AVPs. The PAA-
originated PANA message is sent to the PaC's IP address with the
source UDP port number set to the PANA port number (716) and the
destination UDP port number set to the UDP port number contained in
the Relayed-Message AVP.
The Session Identifier and Sequence Number of any PRY message are set
to zero. PRY messages are never retransmitted by the PRE or the PAA.
Note that the PANA message carried in a Relayed-Message AVP may be
retransmitted by the PaC or PAA, leading to transmission of a new PRY
message carrying the same Relayed-Message AVP.
A PAA that supports this specification MUST be able to process PRY
messages for PaC-initiated PANA sessions.
This specification assumes there is at most one PRE between the PaC
and the PAA. Performing relay operation on a PANA message that is
already relayed (i.e., carried inside a PRY message) is out of scope
of this specification.
Figure 1 is an example message flow with a PRE.
<span class="grey">Duffy, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
PaC PRE PAA srcIP:port->dstIP:port
----- ----- ----- ----------------------
1. ---PCI--> IP1:p1 -> IP2a:716
2. ---PRY[P{IP1:p1},R{PCI}]--> IP2b:p2 -> IP3:716
3. <--PRY[P{IP1:p1},R{PAR}]--- IP3:716 -> IP2b:p2
4. <--PAR--- IP2a:716 -> IP1:p1
5. ---PAN--> IP1:p1 -> IP2a:716
6. ---PRY[P{IP1:p1},R{PAN}]--> IP2b:p2 -> IP3:716
7. <--PRY[P{IP1:p1},R{PAR}]--- IP3:716 -> IP2b:p2
8. <--PAR--- IP2a:716 -> IP1:p1
9. ---PAN--> IP1:p1 -> IP2a:716
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. ---PRY[P{IP1:p1},R{PAN}]--> </span> IP2b:p2 -> IP3:716
IP1 is the IP address of PaC.
IP2a and IP2b are the IP addresses of PRE.
IP2a is used for communicating with PaC.
IP2b is used for communicating with PAA.
The two IP address may be the same.
IP3 is the IP address of PAA.
p1 is PaC-assigned UDP port number.
p2 is PRE-assigned UDP port number.
P: PaC-Information AVP
R: Relayed-Message AVP
Figure 1: Example Call Message for PANA Relay
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Security of Messages Sent between PRE and PAA</span>
PRE/PAA security is OPTIONAL since PANA messages are designed to be
used in untrusted networks, but if a cryptographic mechanism is
supported, it SHOULD be IPsec. When the device characteristics
preclude support for IPsec, an alternative mechanism such as DTLS
[<a href="./rfc4347" title=""Datagram Transport Layer Security"">RFC4347</a>], or link-layer cryptographic security, etc., may be used
instead. This section describes how IPsec [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>] can be used for
securing the PANA relay messages.
<span class="grey">Duffy, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
When IPsec is used, each PRE must have an established pairwise trust
relationship with a PAA. That is, if messages from a PaC will be
relayed by a PRE to a PAA, the PRE and PAA must be configured to use
IPsec for the messages they exchange.
PREs and PAAs that support secure PRE to PAA communication use IPsec
under the following conditions:
Selectors PREs are manually configured with the addresses of
the PAAs to which PANA messages are to be forwarded.
PAAs that will be using IPsec for securing PANA
messages must also be configured with a list of the
PREs to which messages will be returned. The
selectors for the PREs and PAAs will be the pairs of
addresses defining PREs and PAAs that exchange PANA
messages on the PANA UDP port 716 in their source or
destination port.
Mode PREs and PAAs use transport mode and ESP. The
information in PANA messages is not generally
considered confidential, so encryption need not be
used (i.e., NULL encryption can be used).
Key management Because the PREs and PAA must be manually
configured, manually configured key management may
suffice, but does not provide defense against
replayed messages. Accordingly, IKE with preshared
secrets SHOULD be supported. IKE with public keys
MAY be supported.
Security policy PANA messages between PREs and PAAs should only be
accepted from PANA peers as identified in the local
configuration.
Authentication Shared keys, indexed to the source IP address of the
received PANA message, are adequate in this
application.
Availability Appropriate IPsec implementations are likely to be
available for PAAs and for PREs in more featureful
devices used in enterprise and core ISP networks.
IPsec is less likely to be available for PREs in
low-end devices primarily used in the home or small
office markets.
<span class="grey">Duffy, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. PANA Messages for Relay Operation</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. PANA-Relay</span>
The PANA-Relay (PRY) message is sent by the PRE to the PAA or by the
PAA to the PRE. It contains one PaC-Information AVP and one Relayed-
Message AVP. The PRY message SHOULD NOT carry other AVPs.
In a PRE-originated PRY message, the PaC-Information AVP contains an
IP address and the UDP port number of the PANA message that was
originated by the PaC and is contained in the Relayed-Message AVP.
In a PAA-originated PRY message, the information in the PaC-
Information AVP MUST be copied from the "IP address and UDP port
number of the PaC" attribute of the associated PANA session
[<a href="./rfc5191" title=""Protocol for Carrying Authentication for Network Access (PANA)"">RFC5191</a>].
The Session Identifier and Sequence Number field of any PRY message
MUST be set to zero. A PRY message MUST NOT be retransmitted by the
PRE or the PAA.
PANA-Relay ::= < PANA-Header: 5 >
{ PaC-Information }
{ Relayed-Message }
*[ AVP ]
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. PANA AVPs for Relay Operation</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. PaC-Information AVP</span>
The PaC-Information AVP (AVP Code 10) is of type OctetString and
contains an IP address (16-octet for an IPv6 address or 4-octet for
an IPv4 address) followed by a 2-octet UDP port number of the PaC,
both encoded in network-byte order.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Relayed-Message AVP</span>
The Relayed-Message (AVP Code 11) is of type OctetString and contains
a relayed PANA message excluding the UDP and IP headers.
<span class="grey">Duffy, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
A PRE's main objective is to assist transport of PANA messages
between the PaC and the PAA. Relay operation performed between the
PRE and the PAA forms an additional logical link for relaying the
end-to-end PANA messages between the PaC and the PAA. In that sense,
a PRE resembles a bridge or a router that sits between the PaC and
the PAA when non-relayed PANA [<a href="./rfc5191" title=""Protocol for Carrying Authentication for Network Access (PANA)"">RFC5191</a>] is used.
A PRE can pose certain threats to the relayed PANA messages. A PRE
can delay or drop PANA messages sent by the PaC or the PAA. It can
also spoof or modify PANA messages sent towards the PaC or the PAA.
These threats are similar to what an on-path bridge/router (i.e., a
man-in-the-middle, MitM) can pose to non-relayed PANA. EAP and PANA
protocols are designed to operate over unsecure links where
aforementioned threats can already exist. Even though these threats
cannot be leveraged to gain unauthorized network access, or
compromise of cryptographic keys (e.g., MK, MSK, EMSK, etc.), other
damages such as preventing authentication to complete, or denial-of
service are still possible.
Even though the PRE-to-PAA relay path appears to be a separate
additional logical link for transporting the PANA messages, the PRE
may pose a few additional risks versus traditional on-path bridges
and routers. The following explains the risks and mitigations of PRE
as a relay device.
The PRE inserts PaC-Information AVP as the PaC-generated PANA packet
is encapsulated in a PRY packet to the PAA. This AVP carries the IP
address and the UDP port number values of the PANA packet as sent by
the PAC. These values are already carried inside the IP and UDP
headers with non-relayed PANA and they are not necessarily secured.
EAP and PANA are designed to work in the absence of their protection.
Therefore, no additional PANA-layer security is needed when these
values are carried as PANA AVPs between the PRE and the PAA. If a
future document defines additional payload AVPs for the PRY messages,
there may be a need to define additional security for those messages.
A rogue PRE can spoof PANA messages on behalf of a victim PaC and
receive the PAA response irrespective of the location of the PRE with
respect to the network topology. Achieving the same threat with non-
relayed PANA requires the rogue node be an MitM, otherwise the
spoofed packets may be dropped by the ingress filtering network
elements, or the responses would be directly sent to the victim PaC
IP address and may not be received by the rogue node. Nevertheless,
such a rogue PRE cannot perform full initial authentication on behalf
of the victim PaC unless it also holds the PaC's credentials
<span class="grey">Duffy, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
(including the master key). Furthermore, any spoofed PANA messages
after the initial authentication will fail the integrity checks at
the PAA when a key-generating EAP method is used.
The only state that can change on the PAA upon a rogue PRE sending a
spoofed PRY is the IP address and UDP port number of the PRE stored
as PANA session attributes, which impacts where the PAA sends the
next PANA packet (i.e., to the rogue PRE instead of the legitimate
PRE). The PAA also needs to handle the PaC-Information AVP in
addition to the PaC-originated PANA message carried in the Relayed-
Message AVP, so use of the PRE may impose additional storage
requirements on the PAA. A rogue PRE generating a valid PANA packet
requires it be a MitM in order to synch up with the PANA session
state and attributes on the PaC. Such a MitM can already disturb the
EAP and PANA even without playing the role of a PRE.
An unauthorized node pretending as PAA can spoof the relayed PANA
messages to the PRE in order to get them delivered to the PaC. While
the harm caused by such spoofed packets are limited (due to the EAP
and PANA design with unsecured network operation in mind), the
processing of bogus packets can cause processing load on the PaC.
Some of the risks stemming from the aforementioned threats are
already handled by the EAP and PANA as described. The residual risks
shall be mitigated using additional physical or cryptographic
security in the network hosting the PREs and the PAAs. Access
control lists implemented on the PRE, PAA, or intermediary firewalls
supported by cryptographic or physical authentication/authorization
are needed for protecting legitimate PRE and PAAs against rogue ones.
Details of the cryptographic mechanisms using IPsec are specified in
<a href="#section-3">Section 3</a>. Use of manually configured preshared keys for IPsec
between PREs and PAAs does not defend against replayed PANA messages.
PREs do not need to maintain per-PaC state; therefore, they are
robust against resource consumption DoS (Denial-of-Service) attacks.
In the relay operation, the IP address of the PAA that is seen by the
PaC (i.e., an IP address of the PRE) is different from the IP address
of the PAA that is seen by the authentication server. If an EAP
channel binding solution uses the IP address of the PAA as part of
channel binding parameters, such a solution must take this into
account. Note that the same issue arises even when non-relayed PANA
is used and the PAA has one IP address configured on its interface
facing the PaC and another IP address on the other interface facing
the authentication server.
<span class="grey">Duffy, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
As described in Sections <a href="#section-4">4</a> and <a href="#section-5">5</a>, and following the new IANA
allocation policy on PANA messages [<a href="./rfc5872" title=""IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)"">RFC5872</a>], one Message Type and
two PANA AVP Codes have been assigned.
o A Message Type of 5 for PANA-Relay (PRY) message with the 'R'
(Request) bit cleared.
o A standard AVP Code of 10 for PaC-Information AVP.
o A standard AVP Code of 11 for Relayed-Message AVP.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The authors would like to thank Vlad Gherghisan, Shohei Watanabe,
Richard Kelsey, Rafa Marin Lopez, Margaret Wasserman, Alan DeKok,
Ralph Droms, Jari Arkko, Yoshifumi Nishida and Stephen Farrell for
their valuable comments.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-RFC5191">RFC5191</a>] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and
A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", <a href="./rfc5191">RFC 5191</a>, May 2008.
[<a id="ref-RFC5192">RFC5192</a>] Morand, L., Yegin, A., Kumar, S., and S. Madanapalli,
"DHCP Options for Protocol for Carrying Authentication
for Network Access (PANA) Authentication Agents",
<a href="./rfc5192">RFC 5192</a>, May 2008.
[<a id="ref-RFC5872">RFC5872</a>] Arkko, J. and A. Yegin, "IANA Rules for the Protocol
for Carrying Authentication for Network Access (PANA)",
<a href="./rfc5872">RFC 5872</a>, May 2010.
<span class="grey">Duffy, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC4347">RFC4347</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", <a href="./rfc4347">RFC 4347</a>, April 2006.
[<a id="ref-RFC4944">RFC4944</a>] Montenegro, G., Kushalnagar, N., Hui, J., and D.
Culler, "Transmission of IPv6 Packets over IEEE
802.15.4 Networks", <a href="./rfc4944">RFC 4944</a>, September 2007.
[<a id="ref-6LoWPAN-ND">6LoWPAN-ND</a>] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low Power and Lossy Networks
(6LoWPAN)", Work in Progress, June 2011.
[<a id="ref-ZIGBEEIP">ZIGBEEIP</a>] ZigBee Alliance, "ZigBee IP Specification",
ZigBee 095023r10, Work in Progress, July 2010.
<span class="grey">Duffy, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6345">RFC 6345</a> PANA Relay Element August 2011</span>
Authors' Addresses
Paul Duffy
Cisco Systems
200 Beaver Brook Road
Boxborough, MA 01719
USA
EMail: paduffy@cisco.com
Samita Chakrabarti
Ericsson
300 Holger Way
San Jose, CA 95135
USA
EMail: samita.chakrabarti@ericsson.com
Robert Cragie
Pacific Gas & Electric
Gridmerge Ltd., 89 Greenfield Crescent
Wakefield, WF4 4WA
UK
EMail: robert.cragie@gridmerge.com
Yoshihiro Ohba (editor)
Toshiba Corporate Research and Development Center
1 Komukai-Toshiba-cho
Saiwai-ku, Kawasaki, Kanagawa 212-8582
Japan
Phone: +81 44 549 2127
EMail: yoshihiro.ohba@toshiba.co.jp
Alper Yegin
Samsung
Istanbul
Turkey
EMail: a.yegin@partner.samsung.com
Duffy, et al. Standards Track [Page 12]
</pre>
|
