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
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Network Working Group S. Krishnan, Ed.
Request for Comments: 4957 Ericsson Research
Category: Informational N. Montavont
GET ENST Bretagne
E. Njedjou
France Telecom
S. Veerepalli
Qualcomm
A. Yegin, Ed.
Samsung
August 2007
<span class="h1">Link-Layer Event Notifications for Detecting Network Attachments</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Certain network access technologies are capable of providing various
types of link-layer status information to IP. Link-layer event
notifications can help IP expeditiously detect configuration changes.
This document provides a non-exhaustive catalogue of information
available from well-known access technologies.
<span class="grey">Krishnan, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</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>. Link-Layer Event Notifications . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.4">3.4</a>. IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.4.1">3.4.1</a>. Link Integrity Tests in 802.3 Networks . . . . . . . . <a href="#page-10">10</a>
3.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer
Event Notifications . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-3.4.3">3.4.3</a>. 802.1AB Link-Layer Discovery Protocol . . . . . . . . <a href="#page-12">12</a>
<a href="#section-3.4.4">3.4.4</a>. Other Heuristics . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-3.4.5">3.4.5</a>. Summary . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5">5</a>. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6">6</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<span class="grey">Krishnan, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
It is not an uncommon occurrence for a node to change its point of
attachment to the network. This can happen due to mobile usage
(e.g., a mobile phone moving among base stations) or nomadic usage
(e.g., road-warrior case).
A node changing its point of attachment to the network may end up
changing its IP subnet and therefore require reconfiguration of IP-
layer parameters, such as IP address, default gateway information,
and DNS server address. Detecting the subnet change can usually use
network-layer indications (such as a change in the advertised
prefixes for IPv6). But such indications may not be always available
(e.g., Detecting Network Attachment in IPv6 (DNAv6)) to the node upon
changing its point of attachment.
Link-layer event notifications can help IP expeditiously detect
configuration changes. This document provides a non-exhaustive
catalog of information available from some access technologies, and
discusses the interpretation of this information at the IP layer.
This document is not intended to specify or change the behavior of
these access technologies in any manner.
Additional information can be conveyed along with the event, such as
the identifier of the network attachment point (e.g., IEEE 802.11
Basic Service Set Identification (BSSID) and Service Set Identifier
(SSID)), or network-layer configuration parameters obtained via the
link-layer attachment process if available. It is envisaged that
such event notifications can in certain circumstances be used to
expedite the inter-subnet movement detection and reconfiguration
process. For example, the notification indicating that the node has
established a new link-layer connection may be used for immediately
probing the network for a possible configuration change. In the
absence of such a notification from the link layer, IP has to wait
for indications that are not immediately available, such as receipt
of the next scheduled router advertisement, unreachability of the
default gateway, etc.
It should be noted that a link-layer event notification does not
always translate into a subnet change. Even if the node has torn
down a link-layer connection with one attachment point and
established a new connection with another, it may still be attached
to the same IP subnet. For example, several IEEE 802.11 access
points can be attached to the same IP subnet. Moving among these
access points does not warrant any IP-layer configuration change.
<span class="grey">Krishnan, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
In order to enable an enhanced scheme for detecting change of subnet,
we need to define link-layer event notifications that can be
realistically expected from various access technologies. The
objective of this document is to provide a catalogue of link-layer
events and notifications in various architectures. While this
document mentions the utility of this information for detecting
change of subnet (or, detecting network attachment - DNA), the
detailed usage is left to other documents, namely, DNA solution
specifications.
The document limits itself to the minimum set of information that is
necessary for solving the DNA problem [<a href="./rfc4135" title=""Goals of Detecting Network Attachment in IPv6"">RFC4135</a>]. A broader set of
information (e.g., signal strength, packet loss, etc.) and events
(e.g. link down) may be used for other problem spaces, such as
anticipation-based Mobile IP fast handovers [<a href="./rfc4881" title=""Low-Latency Handoffs in Mobile IPv4"">RFC4881</a>], [<a href="./rfc4068" title=""Fast Handovers for Mobile IPv6"">RFC4068</a>],
etc.
These event notifications are considered with hosts in mind, although
they may also be available on the network side (e.g., on the access
points and routers). An API or protocol-based standard interface may
be defined between the link layer and IP for conveying this
information. That activity is beyond the scope of this document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
Link: is a communication facility or medium over which network nodes
can communicate. Each link is associated with a minimum of two
endpoints. An "attachment point" is the link endpoint on the link to
which the node is currently connected, such as an access point, a
base station, or a wired switch.
Link up: is an event provided by the link layer that signifies a
state change associated with the interface becoming capable of
communicating data packets. This event is associated with a link-
layer connection between the node and an attachment point.
BSSID: Basic Service Set Identification
DNA: Detecting Network Attachment
GPRS: General Packet Radio Service
PDP: Packet Data Protocol
SSID: Service Set Identifier
<span class="grey">Krishnan, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Link-Layer Event Notifications</span>
Link-layer event notifications are considered to be one of the inputs
to the DNA process. A DNA process is likely to take other inputs
(e.g., presence of advertised prefixes, reachability of default
gateways) before determining whether IP-layer configuration must be
updated. It is expected that the DNA process can take advantage of
link-layer notifications when they are made available to IP. While
by itself a link-layer notification may not constitute all the input
DNA needs, it can at least be useful for prompting the DNA process to
collect further information (i.e., other inputs to the process). For
example, the node may send a router solicitation as soon as it learns
that a new link-layer connection is established.
The link-layer event that is considered most useful to DNA process is
the link up event. The associated notifications can be provided to
the IP-layer after the event concludes successfully. The link up
events and notifications are associated with a network interface on
the node. The IP module may receive simultaneous independent
notifications from each one of the network interfaces on the node.
The actual event is managed by the link layer of the node through
execution of link-layer protocols and mechanisms. Once the event
successfully completes within the link layer, its notification is
delivered to the IP-layer. By the time the notification is
delivered, the link layer of the node must be ready to accept IP
packets from the IP and the physical layers. Each time an interface
changes its point of attachment, a link up event should be generated.
There is a non-deterministic usage of the link up notification to
accommodate implementations that desire to indicate the link is up,
but the data transmission may be blocked in the network (see IEEE
802.3 discussion). A link up notification may be generated with an
appropriate attribute, conveying its non-deterministic nature, to
convey the event. Alternatively, the link-layer implementation may
choose to delay the link up notification until the risk conditions
cease to exist.
If a non-deterministic link up was generated, another link up must
follow as soon as the link layer is capable of generating a
deterministic notification. The event attributes may indicate
whether the packets transmitted since the previous notification were
presumed to be blocked or allowed by the network, if the link layer
could determine the exact conditions.
<span class="grey">Krishnan, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
The deterministic link up event following a non-deterministic link up
event can be treated differently by consumers of the link up event.
For example, the second link up event need not trigger a confirmation
process, if the first one already did.
A node may have to change its IP-layer configuration even when the
link-layer connection stays the same. An example scenario is the
IPv6 subnet renumbering [<a href="./rfc2461" title=""Neighbor Discovery for IP Version 6 (IPv6)"">RFC2461</a>]. Therefore, there exist cases
where IP-layer configuration may have to change even without the IP
layer receiving a link up notification. Therefore, a link-layer
notification is not a mandatory indication of a subnet change.
A link up notification may optionally deliver information relating to
the attachment point. Such auxiliary information may include the
identity of the attachment point (e.g., base station identifier), or
the IP-layer configuration parameters associated with the attached
subnet (e.g., subnet prefix, default gateway address, etc.). While
merely knowing that a new link-layer connection is established may
prompt the DNA process to immediately seek other clues for detecting
a network configuration change, auxiliary information may constitute
further clues (and even the final answers sometimes). In cases where
there is a one-to-one mapping between the attachment point
identifiers and the IP-layer configurations, learning the former can
reveal the latter. Furthermore, IP-layer configuration parameters
obtained during the link-layer connection may be exactly what the DNA
process is trying to discover.
The link-layer process leading to a link up event depend on the link
technology. While a link-layer notification must always indicate
that the link up event occurred, the availability and types of
auxiliary information on the attachment point depends on the link-
layer technology as well. The following subsections examine four
link-layer technologies and describe when a link-layer notification
is generated and what information is included in it.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. GPRS/3GPP</span>
GSM Packet Radio System (GPRS) provides packet-switched data
transmission over a cellular network [<a href="#ref-GPRS" title=""Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS) Service description; Stage 2"">GPRS</a>][GPRS-LINK].
The GPRS architecture consists of a Radio Access Network and a packet
domain Core Network.
- The GPRS Radio Access Network is composed of Mobile Terminals
(MTs), a Base Station Subsystem and Serving GPRS Support Nodes
(SGSNs).
<span class="grey">Krishnan, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
- An IP Core Network that acts as the transport backbone of user
datagrams between SGSNs and Gateway GPRS Support Nodes (GGSNs).
The GGSN ensures the GPRS IP core network connectivity with
external networks, such as the Internet or Local Area Networks.
The GGSN acts as the default IP gateway for the MT.
A GPRS MT that wants to establish IP connectivity establishes first a
connection to the GPRS network and one or more PDP Context
associations between the MT and the GGSN. It is only after the PDP
Context has been established and after address autoconfiguration and
tunneling mechanism have taken place that the MT's IP packets can be
forwarded to and from its remote IP peers. The aim of PDP Context
establishment is also to provide IP-level configuration on top of the
GPRS link-layer attachment.
Successful establishment of a PDP Context on a GPRS link signifies
the availability of IP service to the MT. Therefore, this link-layer
event generates a link up event notification sent to the IP layer.
An MT may establish a secondary PDP Context while reusing the IP
configuration acquired from a previously established and active PDP
Context. Such a secondary PDP Context does not provide additional
information to the IP layer and only allows another quality-of-
service (QoS) profile to be used. The activation of such a secondary
PDP context does not usually generate a link up event since it does
not require new IP parameters. However, other additional PDP Context
activations are to be treated as indicated earlier.
With IPv4, the auxiliary information carried along with this
notification is the IPv4 address of the MT that is obtained as part
of the PDP Context. With IPv6, the PDP Context activation response
does not come along with a usable IPv6 address. Effectively, the
IPv6 address received from the GGSN in the PDP address field of the
message does not contain a valid prefix. The MN actually only uses
the interface identifier extracted from that field to form a link-
local address that it uses afterwards to obtain a valid prefix (e.g.,
by stateless [<a href="./rfc2462" title=""IPv6 Stateless Address Autoconfiguration"">RFC2462</a>][GPRS-CN] or stateful [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] [<a href="#ref-GPRS-GSSA" title=""Technical Specification Group Services and System Aspect; General Packet Radio Service (GPRS) Service description; Stage 2 (Release 6)"">GPRS-GSSA</a>]
address configuration). Therefore, no IPv6-related auxiliary
information is provided to the IP layer.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. cdma2000/3GPP2</span>
cdma2000-based 3GPP2 packet data services provide mobile users wide
area high-speed access to packet switched networks [<a href="#ref-CDMA2K" title=""cdma2000 Wireless IP Network Standard"">CDMA2K</a>]. Some of
the major components of the 3GPP2 packet network architecture consist
of:
<span class="grey">Krishnan, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
- Mobile Station (MS), which allows mobile access to packet-switched
networks over a wireless connection.
- Radio Access Network, which consists of the Base Station
Transceivers, Base Station Controllers, and the Packet Control
Function.
- Network Access Server known as the Packet Data Switching Node
(PDSN). The PDSN also serves as default IP gateway for the IP MS.
3GPP2 networks use the Point-to-Point Protocol (PPP [<a href="./rfc1661" title=""The Point-to-Point Protocol (PPP)"">RFC1661</a>]) as the
link-layer protocol between the MS and the PDSN. Before any IP
packets may be sent or received, PPP must reach the Network-Layer
Protocol phase, and the IP Control Protocol (IPCP [<a href="./rfc1332" title=""The PPP Internet Protocol Control Protocol (IPCP)"">RFC1332</a>], IPV6CP
[<a href="./rfc2472" title=""IP Version 6 over PPP"">RFC2472</a>]) must reach the Opened state. When these states are
reached in PPP, a link up event notification is delivered to the IP
layer.
When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4
Service, IPCP enables configuration of an IPv4 address on the MS.
This IPv4 address is provided as the auxiliary information along with
the link up notification. IPV6CP used for Simple IPv6 service does
not provide an IPv6 address, but the interface identifiers for local
and remote endpoints of the PPP link. Since there is no standards-
mandated correlation between the interface identifier and other IP-
layer configuration parameters, this information is deemed not useful
for DNA (nevertheless, it may be provided as auxiliary information
for other uses).
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. IEEE 802.11/WiFi</span>
IEEE 802.11-based WiFi networks are the wireless extension of the
Local Area Networks. Currently available standards are IEEE 802.11b
[<a href="#ref-IEEE-802.11b" title=""IEEE Std 802 Part 11, Information technology - Telecomunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless Lan Medium Access Control (MAC) And Physical Layer (PHY) Specifications"">IEEE-802.11b</a>], IEEE 802.11g [<a href="#ref-IEEE-802.11g" title=""IEEE Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 edition, Part 11: Wireless MAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. Amendment 4: Further Higher Data Rate Extension in the 2.4 GHz Band"">IEEE-802.11g</a>], and IEEE 802.11a
[<a href="#ref-IEEE-802.11a" title=""IEEE Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part 11: Wireless MAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ band"">IEEE-802.11a</a>]. The specifications define both the MAC layer and the
physical layer. The MAC layer is the same for all these
technologies.
Two operating modes are available in the IEEE 802.11 series, either
infrastructure mode or ad-hoc mode. In infrastructure mode, all
link-layer frames are transmitted to an access point (AP) that then
forwards them to the final receiver. A station (STA) establishes an
IEEE 802.11 association with an AP in order to send and receive IP
packets. In a WiFi network that uses Robust Secure Network (RSN
[<a href="#ref-IEEE-802.11i" title=""Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security"">IEEE-802.11i</a>]), successful completion of the 4-way handshake between
the STA and AP commences the availability of IP service. The link up
<span class="grey">Krishnan, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
event notification is generated upon this event. In non-RSN-based
networks, successful association or re-association events on the link
layer causes a link up notification sent to the IP layer.
As part of the link establishment, the STA learns the BSSID and SSID
associated with the AP. The BSSID is a unique identifier of the AP,
usually set to the MAC address of the wireless interface of the AP.
The SSID carries the identifier of the Extended Service Set (ESS) --
the set composed of APs and associated STAs that share a common
distribution system. The BSSID and SSID may be provided as auxiliary
information along with the link up notification. Unfortunately, this
information does not provide a deterministic indication of whether
the IP-layer configuration must be changed upon movement. There is
no standards-mandated one-to-one relation between the BSSID/SSID
pairs and IP subnets. An AP with a given BSSID can connect a STA to
any one of multiple IP subnets. Similarly, an ESS with the given
SSID may span multiple IP subnets. And finally, the SSIDs are not
globally unique. The same SSID may be used by multiple independent
ESSs. Nevertheless, BSSID/SSID information may be used in a
probabilistic way by the DNA process; hence, it is provided with the
link up event notification.
In ad-hoc mode, mobile stations (STA) in range may directly
communicate with each other, i.e., without any infrastructure or
intermediate hop. The set of communicating STAs is called IBSS for
Independent Basic Service Set. In an IBSS, only STA services are
available, i.e., authentication, deauthentication, privacy, and MAC
Service Data Unit (MSDU) delivery. STAs do not associate with each
other, and therefore may exchange data frames in state 2
(authenticated and not associated) or even in state 1
(unauthenticated and unassociated) if the Distribution System is not
used (i.e., "To DS" and "From DS" bits are clear). If authentication
is performed, a link up indication can be generated upon
authentication. Concerning the link layer identification, both the
BSSID (which is a random MAC address chosen by a STA of the IBSS) and
SSID may be used to identify a link, but not to make any assumptions
on the IP network configuration.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. IEEE 802.3 CSMA/CD</span>
IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most
commonly deployed Local Area Network technology in use today. As
deployed today, it is specified by a physical layer/medium access
control (MAC) layer specification [<a href="#ref-IEEE-802.3" title=""IEEE standard for local and metropolitan area networks - Specific Requirements, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications"">IEEE-802.3</a>]. In order to provide
connection of different LANs together into a larger network, 802.3
LANs are often bridged together [<a href="#ref-IEEE-802.1D" title=""IEEE standard for local and metropolitan area networks - common specifications - Media access control (MAC) Bridges"">IEEE-802.1D</a>].
<span class="grey">Krishnan, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
In this section, the terms 802.3 and Ethernet are used
interchangeably. This section describes some issues in providing
link-layer indications on Ethernet networks, and shows how bridging
affects these indications.
In Ethernet networks, hosts are connected by wires or by optic fibre
to a switch (bridge), a bus (e.g., coaxial cable), a repeater (hub),
or directly to another Ethernet device. Interfaces are symmetric, in
that while many different physical layers may be present, medium
access control is uniform for all devices.
In order to determine whether the physical medium is ready for frame
transfer, IEEE 802.3 Ethernet specifies its own link monitoring
mechanism, which is defined for some, but not all, classes of media.
Where available, this Link Integrity Test operation is used to
identify when packets are able to be received on an Ethernet segment.
It is applicable to both wired and optical physical layers, although
details vary between technologies (link pulses in twisted pair
copper, light levels in fibre).
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Link Integrity Tests in 802.3 Networks</span>
Link Integrity Tests in 802.3 networks typically occur at initial
physical connection time (for example, at the auto-negotiation stage)
and periodically afterwards. They make use of physical-layer
specific operations to determine if a medium is able to support link-
layer frames [<a href="#ref-IEEE-802.3" title=""IEEE standard for local and metropolitan area networks - Specific Requirements, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications"">IEEE-802.3</a>].
The status of the link as determined by the Link Integrity Test is
stored in the variable 'link_status'. Changes to the value of
link_status (for example due to Link Integrity Test failure) will
generate link indications if the technology-dependent interface is
implemented on an Ethernet device [<a href="#ref-IEEE-802.3" title=""IEEE standard for local and metropolitan area networks - Specific Requirements, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications"">IEEE-802.3</a>].
The link_status has possible values of FAIL, READY, and OK. In FAIL
state, Link Integrity Tests have failed. In READY state, the link
segment has passed integrity tests, but auto-negotiation has not
completed. In OK state, the medium is able to send and receive
packets.
Upon transition to a particular state, the Physical Medium Attachment
subsystems generates a PMA_LINK.indicate(link_status). Indications
of OK state may be used to generate a link up event notification.
These indications do not definitively ensure that packets will be
able to be received through the bridge domain, though (see the next
section). Such operations are governed by bridging.
<span class="grey">Krishnan, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. IEEE 802.1D Bridging and Its Effects on Link-layer Event</span>
<span class="h4"> Notifications</span>
Ethernet networks commonly consist of LANs joined together by
transparent bridges (usually implemented as switches). Transparent
bridges require the active topology to be loop free. This is
achieved through the Spanning Tree Protocol (STP) or the Rapid
Spanning Tree Protocol (RSTP). These protocols exchange Bridge
Protocol Data Units (BPDUs), as defined in [<a href="#ref-IEEE-802.1D" title=""IEEE standard for local and metropolitan area networks - common specifications - Media access control (MAC) Bridges"">IEEE-802.1D</a>]; this leads
to the blocking of ports (i.e., not forwarding), where required.
By default, the spanning tree protocol does not know whether a
particular newly connected piece of Ethernet will cause a loop.
Therefore, it will block all traffic from and to newly connected
ports with the exception of some unbridged management frames. The
STP will determine if the port can be connected to the network in a
loop-free manner.
For these technologies, even though the link layer appears available,
no data packet forwarding will occur until it is determined that the
port can be connected to the network in a loop-free environment.
For hosts that are providing indications to upper-layer protocols,
even if the host itself does not implement bridging or STP, packet
delivery across the network can be affected by the presence of
bridges.
A host connected to a bridge port does not receive any explicit
indication that the bridge has started forwarding packets.
Therefore, a host may not know when STP operations have completed, or
when it is safe to inform upper layers to transmit packets.
Where it is not known that forwarding operations are available, a
host should assume that RSTP or STP is being performed. Hosts may
listen to STP/RSTP and 802.1AB messages to gain further information
about the timing of full connectivity on the link, for example, to
override an existing indication.
Notably, though, it is not easy for a host to distinguish between
disabled bridge ports and non-bridge ports with no active
transmitters on them, as Disabled ports will have no traffic on them,
and incur 100% sender loss.
If no bridge configuration messages are received within the
Bridge_Max_Age interval (default 20s) then it is likely that there is
no visible bridge whose port is enabled for bridging (S8.4.5 of
[<a href="#ref-IEEE-802.1D" title=""IEEE standard for local and metropolitan area networks - common specifications - Media access control (MAC) Bridges"">IEEE-802.1D</a>]), since at least two BPDU hello messages would have
<span class="grey">Krishnan, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
been lost. Upon this timeout, a link up notification is generated,
if one has not been already.
If a BPDU is received, and the adjacent bridge is running the
original Spanning Tree Protocol, then a host cannot successfully send
packets until at least twice the ForwardDelay value in the received
BPDU has elapsed. After this time, a link up notification is
generated. If the previous link up notification was non-
deterministic, then this notification includes an attribute
signifying that the packets sent within the prior interval were lost.
If the bridge is identified as performing Rapid Spanning Tree
Protocol (RSTP), it instead waits Bridge_Max_Age after packet
reception (advertised in the BPDU's Max Age field), before
forwarding. For ports which are known to be point-to-point through
auto-negotiation, this delay is abbreviated to 3 seconds after auto-
negotiation completes [<a href="#ref-IEEE-802.1D" title=""IEEE standard for local and metropolitan area networks - common specifications - Media access control (MAC) Bridges"">IEEE-802.1D</a>].
<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>. 802.1AB Link-Layer Discovery Protocol</span>
The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP)
provides information to devices that are directly adjacent to them on
the local LAN [<a href="#ref-IEEE-802.1ab" title=""Draft Standard for Local and Metropolitan Networks: Station and Media Access Control Connectivity Discovery (Draft 13)"">IEEE-802.1ab</a>].
LLDP sends information periodically and at link status change time to
indicate the configuration parameters of the device. Devices may
send or receive these messages, or do both.
The LLDP message may contain a System Capabilities TLV, which
describes the MAC- and IP-layer functions that a device is currently
using. Where a host receives the System Capabilities TLV indicating
that no Bridging is occurring on the LLDP transmitter, no delays for
STP calculation will be applied to packets sent through this
transmitter. This would allow the generation of a link up
notification.
Additionally, if a host receives a System Capabilities TLV indicating
that the LLDP transmitter is a bridge, the host's advertisement that
it is an (end-host) Station-Only may tell the bridge not to run STP
and may immediately allow forwarding.
Proprietary extensions may also indicate that data forwarding is
already available on such a port. Discussion of such optimizations
is out of scope for this document.
Because the protocol is new and not widely deployed, it is unclear
how this protocol will eventually affect DNA in IPv4 or IPv6
networks.
<span class="grey">Krishnan, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
<span class="h4"><a class="selflink" id="section-3.4.4" href="#section-3.4.4">3.4.4</a>. Other Heuristics</span>
In 802.3 networks, Network Interface Cards (NICs) are often capable
of returning a speed and duplex indication to the host. Changes in
these characteristics may indicate a connection to a new layer 2
network.
<span class="h4"><a class="selflink" id="section-3.4.5" href="#section-3.4.5">3.4.5</a>. Summary</span>
Link-layer indications in Ethernet-like networks are complicated by
additional unadvertised delays due to spanning tree calculations.
This may cause re-indication or retraction of indications previously
sent to upper layer protocols.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
Attackers may spoof various indications at the link layer, or
manipulate the physical medium directly in an effort to confuse the
host about the state of the link layer. For instance, attackers may
spoof error messages or disturb the wireless medium to cause the host
to move its connection elsewhere or even to disconnect. Attackers
may also spoof information to make the host believe it has a
connection when, in reality, it does not. In addition, wireless
networks such as 802.11 are susceptible to an attack called the "Evil
Twin" attack where an attacker sets up an Access Point with the same
SSID as a legitimate one and gets the use to connect to the fake
access point instead of the real one. These attacks may cause use of
non-preferred networks or even denial of service.
This specification does not provide any protection of its own for the
indications from the lower layers. But the vulnerabilities can be
mitigated through the use of techniques in other parts of the
protocol stack. In particular, it is recommended that
authentication, replay, and integrity protection of link-layer
management messages are enabled when available. For example, the
IEEE 802.1ae standard [<a href="#ref-IEEE-802.1ae" title=""IEEE Std 802.1AE, Local and Metropolitan Area Networks - Media Access Control (MAC) Security"">IEEE-802.1ae</a>] defines such mechanisms for IEEE
802-compliant MAC layers. Additionally, the protocol stack may also
use some network-layer mechanisms to achieve partial protection. For
instance, SEND [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>] could be used to confirm secure reachability
with a router. However, network layer mechanisms are unable to deal
with all problems, such as insecure lower-layer notifications that
lead to the link not functioning properly.
<span class="grey">Krishnan, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Contributors</span>
In addition to the people listed in the author list, text for the
specific link-layer technologies covered by this document was
contributed by Thomas Noel (IEEE 802.11b) and Greg Daley (IEEE
802.3). The authors would like to thank them for their efforts in
bringing this document to fruition.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye,
JinHyeock Choi, John Loughney, Pekka Nikander, Brett Pentland, Tom
Petch, Dan Romascanu, Pekka Savola, Steve Bellovin, Thomas Narten,
Matt Mathis, Alfred Hoenes, and Muhammad Mukarram bin Tariq for their
useful comments and suggestions.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-CDMA2K">CDMA2K</a>] "cdma2000 Wireless IP Network Standard", ,
December 2000.
[<a id="ref-GPRS">GPRS</a>] "Digital cellular telecommunications system (Phase
2+); General Packet Radio Service (GPRS) Service
description; Stage 2", 3GPP TS 03.60 version 7.9.0
Release 98.
[<a id="ref-GPRS-LINK">GPRS-LINK</a>] "Digital cellular telecommunications system (Phase
2+); Radio subsystem link control", 3GPP GSM 03.05
version 7.0.0 Release 98.
[<a id="ref-IEEE-802.11a">IEEE-802.11a</a>] Institute of Electrical and Electronics Engineers,
"IEEE Std 802.11a-1999, supplement to IEEE Std
802.11-1999, Part 11: Wireless MAN Medium Access
Control (MAC) and Physical Layer (PHY)
specifications: High-speed Physical Layer in the 5
GHZ band", IEEE Standard 802.11a, September 1999.
[<a id="ref-IEEE-802.11b">IEEE-802.11b</a>] Institute of Electrical and Electronics Engineers,
"IEEE Std 802 Part 11, Information technology -
Telecomunications and information exchange between
systems - Local and metropolitan area networks -
Specific requirements - Part 11: Wireless Lan Medium
Access Control (MAC) And Physical Layer (PHY)
Specifications", IEEE Standard 802.11b, August 1999.
<span class="grey">Krishnan, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
[<a id="ref-IEEE-802.11g">IEEE-802.11g</a>] Institute of Electrical and Electronics Engineers,
"IEEE Std 802.11g-2003, Amendment to IEEE Std 802.11,
1999 edition, Part 11: Wireless MAN Medium Access
Control (MAC) and Physical Layer (PHY)
specifications. Amendment 4: Further Higher Data
Rate Extension in the 2.4 GHz Band", IEEE Standard
802.11g, June 2003.
[<a id="ref-IEEE-802.11i">IEEE-802.11i</a>] Institute of Electrical and Electronics Engineers,
"Supplement to STANDARD FOR Telecommunications and
Information Exchange between Systems - LAN/MAN
Specific Requirements - Part 11: Wireless Medium
Access Control (MAC) and physical layer (PHY)
specifications: Specification for Enhanced Security",
IEEE 802.11i, December 2004.
[<a id="ref-IEEE-802.1D">IEEE-802.1D</a>] Institute of Electrical and Electronics Engineers,
"IEEE standard for local and metropolitan area
networks - common specifications - Media access
control (MAC) Bridges", ISO/IEC IEEE Std 802.1D,
2004.
[<a id="ref-IEEE-802.1ab">IEEE-802.1ab</a>] Institute of Electrical and Electronics Engineers,
"Draft Standard for Local and Metropolitan Networks:
Station and Media Access Control Connectivity
Discovery (Draft 13)", IEEE draft Std 802.1AB, 2004.
[<a id="ref-IEEE-802.1ae">IEEE-802.1ae</a>] Institute of Electrical and Electronics Engineers,
"IEEE Std 802.1AE, Local and Metropolitan Area
Networks - Media Access Control (MAC) Security",
IEEE Standard 802.1ae, June 2006.
[<a id="ref-IEEE-802.3">IEEE-802.3</a>] Institute of Electrical and Electronics Engineers,
"IEEE standard for local and metropolitan area
networks - Specific Requirements, Part 3: Carrier
Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer
Specifications", ISO/IEC IEEE Std 802.3, 2002.
[<a id="ref-RFC1332">RFC1332</a>] McGregor, G., "The PPP Internet Protocol Control
Protocol (IPCP)", <a href="./rfc1332">RFC 1332</a>, May 1992.
[<a id="ref-RFC1661">RFC1661</a>] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, <a href="./rfc1661">RFC 1661</a>, July 1994.
[<a id="ref-RFC2462">RFC2462</a>] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", <a href="./rfc2462">RFC 2462</a>, December 1998.
<span class="grey">Krishnan, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
[<a id="ref-RFC2472">RFC2472</a>] Haskin, D. and E. Allen, "IP Version 6 over PPP",
<a href="./rfc2472">RFC 2472</a>, December 1998.
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, July 2003.
[<a id="ref-RFC3971">RFC3971</a>] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", <a href="./rfc3971">RFC 3971</a>,
March 2005.
[<a id="ref-RFC4135">RFC4135</a>] Choi, JH. and G. Daley, "Goals of Detecting Network
Attachment in IPv6", <a href="./rfc4135">RFC 4135</a>, August 2005.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-GPRS-CN">GPRS-CN</a>] "Technical Specification Group Core Network;
Internetworking between the Public Land Mobile
Network (PLMN) supporting packet based services and
Packet Data Networks (PDN) (Release 6)", 3GPP TS
29.061 version 6.1.0 2004-06.
[<a id="ref-GPRS-GSSA">GPRS-GSSA</a>] "Technical Specification Group Services and System
Aspect; General Packet Radio Service (GPRS) Service
description; Stage 2 (Release 6)", 3GPP TS 23.060
version 6.5.0 2004-06.
[<a id="ref-RFC2461">RFC2461</a>] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>,
December 1998.
[<a id="ref-RFC4068">RFC4068</a>] Koodli, R., "Fast Handovers for Mobile IPv6",
<a href="./rfc4068">RFC 4068</a>, July 2005.
[<a id="ref-RFC4881">RFC4881</a>] El Malki, K., "Low-Latency Handoffs in Mobile IPv4",
<a href="./rfc4881">RFC 4881</a>, June 2007.
<span class="grey">Krishnan, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
Authors' Addresses
Suresh Krishnan (editor)
Ericsson Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
EMail: suresh.krishnan@ericsson.com
Nicolas Montavont
GET ENST Bretagne
2, rue de la chataigneraie
Cesson-Sevigne 35576
France
Phone: (33) 2 99 12 70 23
EMail: nicolas.montavont@enst-bretagne.fr
Eric Njedjou
France Telecom
4, Rue du Clos Courtel BP 91226
Cesson Sevigne 35512
France
Phone: +33 299124878
EMail: eric.njedjou@orange-ftgroup.com
Siva Veerepalli
Qualcomm
5775 Morehouse Drive
San Diego, CA 92131
USA
Phone: +1 858 658 4628
EMail: sivav@qualcomm.com
Alper E. Yegin (editor)
Samsung
Istanbul
Turkey
Phone: +90 533 348 2402
EMail: a.yegin@partner.samsung.com
<span class="grey">Krishnan, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4957">RFC 4957</a> L2 Notifications for DNA August 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Krishnan, et al. Informational [Page 18]
</pre>
|
