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
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Internet Engineering Task Force (IETF) S. Madanapalli
Request for Comments: 5948 iRam Technologies
Category: Standards Track S. Park
ISSN: 2070-1721 Samsung Electronics
S. Chakrabarti
IP Infusion
G. Montenegro
Microsoft Corporation
August 2010
<span class="h1">Transmission of IPv4 Packets over the IP Convergence Sublayer</span>
<span class="h1">of IEEE 802.16</span>
Abstract
IEEE 802.16 is an air interface specification for wireless broadband
access. IEEE 802.16 has specified multiple service-specific
Convergence Sublayers for transmitting upper-layer protocols. The
Packet CS (Packet Convergence Sublayer) is used for the transport of
all packet-based protocols such as the Internet Protocol (IP) and
IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables
the transport of IPv4 packets directly over the IEEE 802.16 Media
Access Control (MAC) layer.
This document specifies the frame format, the Maximum Transmission
Unit (MTU), and the address assignment procedures for transmitting
IPv4 packets over the IP-specific part of the Packet Convergence
Sublayer of IEEE 802.16.
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/rfc5948">http://www.rfc-editor.org/info/rfc5948</a>.
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
Copyright Notice
Copyright (c) 2010 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Typical Network Architecture for IPv4 over IEEE 802.16 ..........<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. IEEE 802.16 IPv4 Convergence Sublayer Support ..............<a href="#page-4">4</a>
<a href="#section-4">4</a>. IPv4 CS Link in 802.16 Networks .................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. IPv4 CS Link Establishment .................................<a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Frame Format for IPv4 Packets ..............................<a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. Maximum Transmission Unit ..................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Subnet Model and IPv4 Address Assignment ........................<a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. IPv4 Unicast Address Assignment ...........................<a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. Address Resolution Protocol ...............................<a href="#page-8">8</a>
<a href="#section-5.3">5.3</a>. IP Broadcast and Multicast ................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-7">7</a>. Acknowledgements ................................................<a href="#page-9">9</a>
<a href="#section-8">8</a>. References ......................................................<a href="#page-9">9</a>
<a href="#section-8.1">8.1</a>. Normative References .......................................<a href="#page-9">9</a>
<a href="#section-8.2">8.2</a>. Informative References .....................................<a href="#page-9">9</a>
<a href="#appendix-A">Appendix A</a>. Multiple Convergence Layers -- Impact on Subnet
Model ................................................<a href="#page-11">11</a>
<a href="#appendix-B">Appendix B</a>. Sending and Receiving IPv4 Packets ...................<a href="#page-11">11</a>
<a href="#appendix-C">Appendix C</a>. WiMAX IPv4 CS MTU Size ...............................<a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
IEEE 802.16 [<a href="#ref-IEEE802_16" title=""IEEE Std 802.16-2009, Draft Standard for Local and Metropolitan area networks, Part 16: Air Interface for Broadband Wireless Access Systems"">IEEE802_16</a>] is a connection-oriented access technology
for the last mile. The IEEE 802.16 specification includes the
Physical (PHY) and Media Access Control (MAC) layers. The MAC layer
includes various Convergence Sublayers (CSs) for transmitting higher-
layer packets, including IPv4 packets [<a href="#ref-IEEE802_16" title=""IEEE Std 802.16-2009, Draft Standard for Local and Metropolitan area networks, Part 16: Air Interface for Broadband Wireless Access Systems"">IEEE802_16</a>].
The scope of this specification is limited to the operation of IPv4
over the IP-specific part of the Packet CS (referred to as "IPv4 CS")
for hosts served by a network that utilizes the IEEE Std 802.16 air
interface.
This document specifies a method for encapsulating and transmitting
IPv4 [<a href="./rfc0791" title=""Internet Protocol"">RFC0791</a>] packets over the IPv4 CS of IEEE 802.16. This
document also specifies the MTU and address assignment method for
hosts using IPv4 CS.
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="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
o Mobile Station (MS) -- The term "MS" is used to refer to an IP
host. This usage is more informal than that in IEEE 802.16, in
which "MS" refers to the interface implementing the IEEE 802.16
MAC and PHY layers and not to the entire host.
o Last mile -- The term "last mile" is used to refer to the final
leg of delivering connectivity from a communications provider to a
customer.
Other terminology in this document is based on the definitions in
[<a href="./rfc5154" title=""IP over IEEE 802.16 Problem Statement and Goals"">RFC5154</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Typical Network Architecture for IPv4 over IEEE 802.16</span>
The network architecture follows what is described in [<a href="./rfc5154" title=""IP over IEEE 802.16 Problem Statement and Goals"">RFC5154</a>] and
[<a href="./rfc5121" title=""Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks"">RFC5121</a>]. Namely, each MS is attached to an Access Router (AR)
through a Base Station (BS), a Layer 2 (L2) entity (from the
perspective of the IPv4 link between the MS and the AR).
For further information on the typical network architecture, see
<a href="./rfc5121#section-5">[RFC5121], Section 5</a>.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. IEEE 802.16 IPv4 Convergence Sublayer Support</span>
As described in [<a href="#ref-IEEE802_16" title=""IEEE Std 802.16-2009, Draft Standard for Local and Metropolitan area networks, Part 16: Air Interface for Broadband Wireless Access Systems"">IEEE802_16</a>], the IP-specific part of the Packet CS
allows the transmission of either IPv4 or IPv6 payloads. In this
document, we are focusing on IPv4 over the Packet Convergence
Sublayer.
For further information on the IEEE 802.16 Convergence Sublayer and
encapsulation of IP packets, see <a href="./rfc5121#section-4">Section 4 of [RFC5121]</a> and
[<a href="#ref-IEEE802_16" title=""IEEE Std 802.16-2009, Draft Standard for Local and Metropolitan area networks, Part 16: Air Interface for Broadband Wireless Access Systems"">IEEE802_16</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IPv4 CS Link in 802.16 Networks</span>
In 802.16, the transport connection between an MS and a BS is used to
transport user data, i.e., IPv4 packets in this case. A transport
connection is represented by a service flow, and multiple transport
connections can exist between an MS and a BS.
When an AR and a BS are co-located, the collection of transport
connections to an MS is defined as a single IPv4 link. When an AR
and a BS are separated, it is recommended that a tunnel be
established between the AR and a BS whose granularity is no greater
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
than "per MS" or "per service flow". (An MS can have multiple
service flows, which are identified by a service flow ID.) Then the
tunnel(s) for an MS, in combination with the MS's transport
connections, forms a single point-to-point IPv4 link.
Each host belongs to a different IPv4 link and is assigned a unique
IPv4 address, similar to the recommendations discussed in "Analysis
of IPv6 Link Models for IEEE 802.16 Based Networks" ([<a href="./rfc4968" title=""Analysis of IPv6 Link Models for 802.16 Based Networks"">RFC4968</a>]).
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. IPv4 CS Link Establishment</span>
In order to enable the sending and receiving of IPv4 packets between
the MS and the AR, the link between the MS and the AR via the BS
needs to be established. This section explains the link
establishment procedure, as described in <a href="./rfc5121#section-6.2">Section 6.2 of [RFC5121]</a>.
Steps 1-4 are the same as those indicated in <a href="./rfc5121#section-6.2">Section 6.2 of
[RFC5121]</a>. In step 5, support for IPv4 is indicated. In step 6, a
service flow is created that can be used for exchanging IP-layer
signaling messages, e.g., address assignment procedures using DHCP.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Frame Format for IPv4 Packets</span>
IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames in the
data payloads of the 802.16 PDU (see <a href="./rfc5154#section-3.2">Section 3.2 of [RFC5154]</a>).
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|E| TYPE |R|C|EKS|R|LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LEN LSB | CID MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID LSB | HCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload /
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CRC (optional) |
+-+-+-+-+-+-+-+-+
Figure 1. IEEE 802.16 MAC Frame Format for IPv4 Packets
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
Here, "MSB" means "most significant byte", and "LSB" means "least
significant byte".
H: Header Type (1 bit). Shall be set to zero, indicating that it
is a Generic MAC PDU.
E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload
is encrypted.
R: Reserved. Shall be set to zero.
C: Cyclic Redundancy Check (CRC) Indicator. 1 = CRC is included;
0 = No CRC is included.
EKS: Encryption Key Sequence.
LEN: The Length, in bytes, of the MAC PDU, including the MAC
header and the CRC, if present (11 bits).
CID: Connection Identifier (16 bits).
HCS: Header Check Sequence (8 bits).
CRC: An optional 8-bit field. The CRC is appended to the PDU
after encryption.
TYPE: This field indicates the subheaders (Mesh subheader,
Fragmentation subheader, Packing subheader, etc.) and special
payload types (e.g., Automatic Repeat reQuest (ARQ)) present in
the message payload.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Maximum Transmission Unit</span>
The MTU value for IPv4 packets on an IEEE 802.16 link is configurable
(e.g., see the end of this section for some possible mechanisms).
The default MTU for IPv4 packets over an IEEE 802.16 link SHOULD be
1500 octets. Given the possibility for "in-the-network" tunneling,
supporting this MTU at the end hosts has implications on the
underlying network, for example, as discussed in [<a href="./rfc4459" title=""MTU and Fragmentation Issues with In-the- Network Tunneling"">RFC4459</a>].
Per <a href="./rfc5121#section-6.3">[RFC5121], Section 6.3</a>, the IP MTU can vary to be larger or
smaller than 1500 octets.
If an MS transmits 1500-octet packets in a deployment with a smaller
MTU, packets from the MS may be dropped at the link layer silently.
Unlike IPv6, in which departures from the default MTU are readily
advertised via the MTU option in Neighbor Discovery (via router
advertisement), there is no similarly reliable mechanism in IPv4, as
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
the legacy IPv4 client implementations do not determine the link MTU
by default before sending packets. Even though there is a DHCP
option to accomplish this, DHCP servers are required to provide the
MTU information only when requested.
Discovery and configuration of the proper link MTU value ensures
adequate usage of the network bandwidth and resources. Accordingly,
deployments should avoid packet loss due to a mismatch between the
default MTU and the configured link MTUs.
Some of the mechanisms available for the IPv4 CS host to find out the
link's MTU value and mitigate MTU-related issues are:
o Recent revision of 802.16 by the IEEE (see IEEE 802.16-2009
[<a href="#ref-IEEE802_16" title=""IEEE Std 802.16-2009, Draft Standard for Local and Metropolitan area networks, Part 16: Air Interface for Broadband Wireless Access Systems"">IEEE802_16</a>]) to (among other things) allow the provision of the
Service Data Unit or MAC MTU in the IEEE 802.16 SBC-REQ/SBC-RSP
phase, such that clients that are compliant with IEEE 802.16 can
infer and configure the negotiated MTU size for the IPv4 CS link.
However, the implementation must communicate the negotiated MTU
value to the IP layer to adjust the IP Maximum Payload Size for
proper handling of fragmentation. Note that this method is useful
only when the MS is directly connected to the BS.
o Configuration and negotiation of MTU size at the network layer by
using the DHCP interface MTU option [<a href="./rfc2132" title=""DHCP Options and BOOTP Vendor Extensions"">RFC2132</a>].
This document recommends that implementations of IPv4 and IPv4 CS
clients SHOULD use the DHCP interface MTU option [<a href="./rfc2132" title=""DHCP Options and BOOTP Vendor Extensions"">RFC2132</a>] in order
to configure its interface MTU accordingly.
In the absence of DHCP MTU configuration, the client node (MS) has
two alternatives: 1) use the default MTU (1500 bytes), or 2)
determine the MTU by the methods described in IEEE 802.16-2009
[<a href="#ref-IEEE802_16" title=""IEEE Std 802.16-2009, Draft Standard for Local and Metropolitan area networks, Part 16: Air Interface for Broadband Wireless Access Systems"">IEEE802_16</a>].
Additionally, the clients are encouraged to run Path MTU (PMTU)
Discovery [<a href="./rfc1191" title=""Path MTU discovery"">RFC1191</a>] or Packetization Layer Path MTU Discovery
(PLPMTUD) [<a href="./rfc4821" title=""Packetization Layer Path MTU Discovery"">RFC4821</a>]. However, the PMTU mechanism has inherent
problems of packet loss due to ICMP messages not reaching the sender
and IPv4 routers not fragmenting the packets due to the Don't
Fragment (DF) bit being set in the IP packet. The above-mentioned
path MTU mechanisms will take care of the MTU size between the MS and
its correspondent node across different flavors of convergence layers
in the access networks.
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Subnet Model and IPv4 Address Assignment</span>
The subnet model recommended for IPv4 over IEEE 802.16 using IPv4 CS
is based on the point-to-point link between the MS and the AR
[<a href="./rfc4968" title=""Analysis of IPv6 Link Models for 802.16 Based Networks"">RFC4968</a>]; hence, each MS shall be assigned an address with a 32-bit
prefix length or subnet mask. The point-to-point link between the MS
and the AR is achieved using a set of IEEE 802.16 MAC connections
(identified by service flows) and an L2 tunnel (e.g., a Generic
Routing Encapsulation (GRE) tunnel) for each MS between the BS and
the AR. If the AR is co-located with the BS, then the set of IEEE
802.16 MAC connections between the MS and the BS/AR represent the
point-to-point connection.
The "next hop" IP address of the IPv4 CS MS is always the IP address
of the AR, because the MS and the AR are attached via a point-to-
point link.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. IPv4 Unicast Address Assignment</span>
DHCP [<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>] SHOULD be used for assigning an IPv4 address for the
MS. DHCP messages are transported over the IEEE 802.16 MAC
connection to and from the BS and relayed to the AR. In case the
DHCP server does not reside in the AR, the AR SHOULD implement a DHCP
relay agent [<a href="./rfc1542" title=""Clarifications and Extensions for the Bootstrap Protocol"">RFC1542</a>].
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Address Resolution Protocol</span>
The IPv4 CS does not allow for transmission of Address Resolution
Protocol (ARP) [<a href="./rfc0826" title=""Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware"">RFC0826</a>] packets. Furthermore, in a point-to-point
link model, address resolution is not needed.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. IP Broadcast and Multicast</span>
Multicast or broadcast packets from the MS are delivered to the AR
via the BS through the point-to-point link. This specification
simply assumes that the broadcast and multicast services are
provided. How these services are implemented in an IEEE 802.16
Packet CS deployment is out of scope of this document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document specifies transmission of IPv4 packets over IEEE 802.16
networks with the IPv4 Convergence Sublayer and does not introduce
any new vulnerabilities to IPv4 specifications or operation. The
security of the IEEE 802.16 air interface is the subject of
[<a href="#ref-IEEE802_16" title=""IEEE Std 802.16-2009, Draft Standard for Local and Metropolitan area networks, Part 16: Air Interface for Broadband Wireless Access Systems"">IEEE802_16</a>]. In addition, the security issues of the network
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
architecture spanning beyond the IEEE 802.16 Base Stations is the
subject of the documents defining such architectures, such as the
Worldwide Interoperability for Microwave Access (WiMAX) network
architecture [<a href="#ref-WMF" title=""WiMAX End-to-End Network Systems Architecture Stage 2-3 Release 1.2, http://www.wimaxforum.org/"">WMF</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The authors would like to acknowledge the contributions of Bernard
Aboba, Dave Thaler, Jari Arkko, Bachet Sarikaya, Basavaraj Patil,
Paolo Narvaez, and Bruno Sousa for their review and comments. The
working group members Burcak Beser, Wesley George, Max Riegel, and DJ
Johnston helped shape the MTU discussion for the IPv4 CS link.
Thanks to many other members of the 16ng Working Group who commented
on this document to make it better.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-IEEE802_16">IEEE802_16</a>] "IEEE Std 802.16-2009, Draft Standard for Local and
Metropolitan area networks, Part 16: Air Interface for
Broadband Wireless Access Systems", May 2009.
[<a id="ref-RFC0791">RFC0791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
September 1981.
[<a id="ref-RFC0826">RFC0826</a>] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit
Ethernet address for transmission on Ethernet
hardware", STD 37, <a href="./rfc826">RFC 826</a>, November 1982.
[<a id="ref-RFC1542">RFC1542</a>] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", <a href="./rfc1542">RFC 1542</a>, October 1993.
[<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-RFC2131">RFC2131</a>] Droms, R., "Dynamic Host Configuration Protocol",
<a href="./rfc2131">RFC 2131</a>, March 1997.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC1191">RFC1191</a>] Mogul, J. and S. Deering, "Path MTU discovery",
<a href="./rfc1191">RFC 1191</a>, November 1990.
[<a id="ref-RFC2132">RFC2132</a>] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", <a href="./rfc2132">RFC 2132</a>, March 1997.
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
[<a id="ref-RFC4459">RFC4459</a>] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", <a href="./rfc4459">RFC 4459</a>, April 2006.
[<a id="ref-RFC4821">RFC4821</a>] Mathis, M. and J. Heffner, "Packetization Layer Path
MTU Discovery", <a href="./rfc4821">RFC 4821</a>, March 2007.
[<a id="ref-RFC4840">RFC4840</a>] Aboba, B., Davies, E., and D. Thaler, "Multiple
Encapsulation Methods Considered Harmful", <a href="./rfc4840">RFC 4840</a>,
April 2007.
[<a id="ref-RFC4968">RFC4968</a>] Madanapalli, S., "Analysis of IPv6 Link Models for
802.16 Based Networks", <a href="./rfc4968">RFC 4968</a>, August 2007.
[<a id="ref-RFC5121">RFC5121</a>] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks",
<a href="./rfc5121">RFC 5121</a>, February 2008.
[<a id="ref-RFC5154">RFC5154</a>] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE
802.16 Problem Statement and Goals", <a href="./rfc5154">RFC 5154</a>,
April 2008.
[<a id="ref-WMF">WMF</a>] "WiMAX End-to-End Network Systems Architecture Stage
2-3 Release 1.2, <a href="http://www.wimaxforum.org/">http://www.wimaxforum.org/</a>",
January 2008.
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Multiple Convergence Layers -- Impact on Subnet Model</span>
Two different MSs using two different Convergence Sublayers (e.g., an
MS using Ethernet CS only and another MS using IPv4 CS only) cannot
communicate at the data link layer and require interworking at the IP
layer. For this reason, these two nodes must be configured to be on
two different subnets. For more information, refer to [<a href="./rfc4840" title=""Multiple Encapsulation Methods Considered Harmful"">RFC4840</a>].
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Sending and Receiving IPv4 Packets</span>
IEEE 802.16 MAC is a point-to-multipoint connection-oriented air
interface, and the process of sending and receiving IPv4 packets is
different from multicast-capable shared-medium technologies like
Ethernet.
Before any packets are transmitted, an IEEE 802.16 transport
connection must be established. This connection consists of an
IEEE 802.16 MAC transport connection between the MS and the BS and an
L2 tunnel between the BS and the AR (if these two are not
co-located). This IEEE 802.16 transport connection provides a point-
to-point link between the MS and the AR. All the packets originating
at the MS always reach the AR before being transmitted to the final
destination.
IPv4 packets are carried directly in the payload of IEEE 802.16
frames when the IPv4 CS is used. IPv4 CS classifies the packet based
on upper-layer (IP and transport layers) header fields to place the
packet on one of the available connections identified by the CID.
The classifiers for the IPv4 CS are source and destination IPv4
addresses, source and destination ports, Type-of-Service, and IP
Protocol field. The CS may employ Packet Header Suppression (PHS)
after the classification.
The BS optionally reconstructs the payload header if PHS is in use.
It then tunnels the packet that has been received on a particular MAC
connection to the AR. Similarly, the packets received on a tunnel
interface from the AR would be mapped to a particular CID using the
IPv4 classification mechanism.
The AR performs normal routing for the packets that it receives,
processing them per its forwarding table. However, the DHCP relay
agent in the AR MUST maintain the tunnel interface on which it
receives DHCP requests so that it can relay the DHCP responses to the
correct MS. The particular method is out of scope of this
specification as it need not depend on any particularities of
IEEE 802.16.
<span class="grey">Madanapalli, 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="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">Appendix C</a>. WiMAX IPv4 CS MTU Size</span>
The WiMAX (Worldwide Interoperability for Microwave Access) forum has
defined a network architecture [<a href="#ref-WMF" title=""WiMAX End-to-End Network Systems Architecture Stage 2-3 Release 1.2, http://www.wimaxforum.org/"">WMF</a>]. Furthermore, WiMAX has
specified IPv4 CS support for transmission of IPv4 packets between
the MS and the BS over the IEEE 802.16 link. The WiMAX IPv4 CS and
this specification are similar. One significant difference, however,
is that the WiMAX Forum [<a href="#ref-WMF" title=""WiMAX End-to-End Network Systems Architecture Stage 2-3 Release 1.2, http://www.wimaxforum.org/"">WMF</a>] has specified the IP MTU as 1400 octets
[<a href="#ref-WMF" title=""WiMAX End-to-End Network Systems Architecture Stage 2-3 Release 1.2, http://www.wimaxforum.org/"">WMF</a>] as opposed to 1500 in this specification.
Hence, if an IPv4 CS MS configured with an MTU of 1500 octets enters
a WiMAX network, some of the issues mentioned in this specification
may arise. As mentioned in <a href="#section-4.3">Section 4.3</a>, the possible mechanisms are
not guaranteed to work. Furthermore, an IPv4 CS client is not
capable of doing ARP probing to find out the link MTU. On the other
hand, it is imperative for an MS to know the link MTU size. In
practice, an MS should be able to sense or deduce the fact that it is
operating within a WiMAX network (e.g., given the WiMAX-specific
particularities of the authentication and network entry procedures),
and adjust its MTU size accordingly. Even though this method is not
perfect, and the potential for conflict may remain, this document
recommends a default MTU of 1500. This represents the WG's consensus
(after much debate) to select the best value for IEEE 802.16 from the
point of view of the IETF, in spite of the WiMAX Forum's deployment.
<span class="grey">Madanapalli, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5948">RFC 5948</a> IPv4 over IEEE 802.16's IPv4 CS August 2010</span>
Authors' Addresses
Syam Madanapalli
iRam Technologies
#H304, Shriram Samruddhi, Thubarahalli
Bangalore - 560066
India
EMail: smadanapalli@gmail.com
Soohong Daniel Park
Samsung Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon 442-742
Korea
EMail: soohong.park@samsung.com
Samita Chakrabarti
IP Infusion
1188 Arques Avenue
Sunnyvale, CA
USA
EMail: samitac@ipinfusion.com
Gabriel Montenegro
Microsoft Corporation
Redmond, WA
USA
EMail: gabriel.montenegro@microsoft.com
Madanapalli, et al. Standards Track [Page 13]
</pre>
|
