File: rfc3122.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1123 lines) | stat: -rw-r--r-- 40,416 bytes parent folder | download | duplicates (5)
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
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123






Network Working Group                                           A. Conta
Request for Comments: 3122                        Transwitch Corporation
Category: Standards Track                                      June 2001


      Extensions to IPv6 Neighbor Discovery for Inverse Discovery
                             Specification

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo describes extensions to the IPv6 Neighbor Discovery that
   allow a node to determine and advertise an IPv6 address corresponding
   to a given link-layer address.  These extensions are called Inverse
   Neighbor Discovery.  The Inverse Neighbor Discovery (IND) was
   originally developed for Frame Relay networks, but may also apply to
   other networks with similar behavior.























Conta                       Standards Track                     [Page 1]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


Table of Contents

   1. Introduction.................................................... 3
   2. Inverse Neighbor Discovery Messages............................. 3
      2.1 Inverse Neighbor Discovery Solicitation Message............. 3
      2.2 Inverse Neighbor Discovery Advertisement Message............ 5
   3. Inverse Neighbor Discovery Options Format....................... 6
      3.1 Target Address List......................................... 6
   4. Inverse Neighbor Discovery Protocol............................. 9
      4.1 Sender Node Processing...................................... 9
      4.2 Receiver Node Processing.................................... 9
        4.2.1 Processing Inverse Neighbor Discovery Solicitations..... 9
        4.2.2 Processing Inverse Neighbor Discovery Advertisements... 10
      4.3 Message Validation......................................... 10
        4.3.1 Validation of Inverse Neighbor Discovery Solicitations. 10
        4.3.2 Validation of Inverse Neighbor Discovery Advertisements 11
   5. Security Considerations........................................ 12
   6. IANA Considerations............................................ 13
   7. Acknowledgments................................................ 13
   8. References..................................................... 13
   9. Authors' Addresses............................................. 14
   Appendix A........................................................ 15
   Full Copyright Statement.......................................... 20




























Conta                       Standards Track                     [Page 2]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


1. Introduction

   This document defines extensions to the IPv6 Neighbor Discovery
   (ND)[IPv6-IND].  The extensions are called IPv6 Inverse Neighbor
   Discovery (IND).  The IPv6 Inverse Neighbor Discovery (IND) allows a
   node that knows the link-layer address of a directly connected remote
   node to learn the IPv6 addresses of that node.  A node using IND
   sends solicitations and receives advertisements for one or more IPv6
   addresses corresponding to a known link-layer address.

   The Inverse Neighbor Discovery (IND) was originally developed for
   Frame Relay networks, but may also apply to other networks with
   similar behavior.

   The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
   SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
   in [KEYWORDS].

   There are a number of similarities and differences between the
   mechanisms described here and those defined for Inverse ARP for IPv4
   in [INV-ARP] or its replacement documents.

2. Inverse Neighbor Discovery Messages

   The following messages are defined:

2.1. Inverse Neighbor Discovery Solicitation Message

   A node sends an Inverse Neighbor Discovery Solicitation message to
   request an IPv6 address corresponding to a link-layer address of the
   target node while also providing its own link-layer address to the
   target.  Since the remote node IPv6 addresses are not known, Inverse
   Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node
   multicasts [IPv6], [IPv6-FR], [ENCAPS].  However, at link layer
   level, an IND Solicitation is sent directly to the target node,
   identified by the known link-layer address.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-





Conta                       Standards Track                     [Page 3]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   Source Address
      An IPv6 address assigned to the interface from which this message
      is sent.

   Destination Address
      The IPv6 all-node multicast address.  This address is specified in
      its link-scope format, which is FF02::1.

   Hop Limit      255

   Authentication Header
      If a Security Association for the IP Authentication Header exists
      between the sender and the destination, then the sender SHOULD
      include this header.

   ICMP Fields:

      Type           141

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

   Required options:

   The sender node MUST send the following options in the Solicitation
   message:

      Source Link-Layer Address
         The link-layer address of the sender.

      Target Link-Layer Address
         The link-layer address of the target node.

   Other valid options:

   The sender node MAY choose to add the following options in the
   Solicitation message:

   Source Address List
      The list of one or more IPv6 addresses of the interface identified
      by the Source Link-Layer Address.  This option is defined in
      section 3.




Conta                       Standards Track                     [Page 4]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   MTU
      The MTU configured for this link [IPv6-ND].

   Future versions of this protocol may add other option types.
   Receivers MUST silently ignore any options they do not recognize and
   continue processing the message.

2.2   Inverse Neighbor Discovery Advertisement Message

   A node sends Inverse Neighbor Discovery Advertisements in response to
   Inverse Neighbor Discovery Solicitations.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Options ...
   +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

   Source Address
      An address assigned to the interface from which the advertisement
      is sent.

   Destination Address
      The Source Address of an invoking Inverse Discovery Neighbor
      Solicitation.

   Hop Limit      255

   Authentication Header
      If a Security Association for the IP Authentication Header exists
      between the sender and the destination address, then the sender
      SHOULD include this header.

      ICMP Fields:

      Type         142

      Code         0

      Checksum     The ICMP checksum.  See [ICMPv6].





Conta                       Standards Track                     [Page 5]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


      Reserved     32-bit unused field.  It MUST be initialized to
                   zero by the sender and MUST be ignored by the
                   receiver.

   Required options:

   The sender node MUST send the following options in the Advertisement
   message:

   Source Link-Layer Address The link-layer address of the sender.

      Target Link-Layer Address
         The link-layer address of the target, that is, the sender of
         the advertisement.

      Target Address List
         The list of one or more IPv6 addresses of the interface
         identified by the Target Link-Layer Address in the Inverse
         Neighbor Discovery Solicitation message that prompted this
         advertisement.  This option is defined in Section 3.

   Other valid options:

   The sender node MAY choose to add the following option in the
   Advertisement message:

   MTU
      The MTU configured for this link [IPv6-ND].

   Future versions of this protocol may add other option types.
   Receivers MUST silently ignore any options they do not recognize and
   continue processing the message.

3. Inverse Neighbor Discovery Options Formats

   Inverse Neighbor Discovery messages include Neighbor Discovery
   options [IPv6-ND] as well as an Inverse Neighbor Discovery specific
   options: the Source Address List and the Target Address List.

3.1  Source/Target Address List

   The Source Address List and the Target Address List option are TLV
   options (type, length, variable size field) (see Section 4.6 of
   [IPv6-ND] with the following fields:







Conta                       Standards Track                     [Page 6]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length   |                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        -       -       -        +
   |                          Reserved                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                        IPv6 Address                           +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                        IPv6 Address                           +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   ~
   |
   +-+-+-+-+...

      Fields:

      Type           9 for Source Address List
                    10 for Target Address List

      Note: These Option Type values should be assigned from the IPv6
      Neighbor Discovery family of values.

      Length         The length of the option (including the Type,
                     Length, and the Reserved fields) in units of 8
                     octets.  The minimum value for Length is 3, for one
                     IPv6 address.

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      IPv6 Addresses One or more IPv6 addresses of the interface.





Conta                       Standards Track                     [Page 7]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   Description:

   The Source Address List contains a list of IPv6 addresses of the
   interface identified by the Source Link-Layer Address.

   The Target Address List contains a list of IPv6 addresses of the
   interface identified by the Target Link-Layer Address.

   The number of addresses "n" in the list is calculated based on the
   length of the option:

      n = (Length - 1)/2  (Length is the number of groups of 8 octets)

   The Source Address List MUST fit in one IND Solicitation message.
   Therefore in case all IPv6 addresses of an interface do not fit in
   one messages, the option does not contain a complete list.  For a
   complete list of IPv6 addresses, a node should rely on the IND
   Advertisement message.

   The Target Address List SHOULD be the complete list of addresses of
   the interface identified by the Target Link-Layer Address.  If the
   list of IPv6 addresses of an interface does not fit in one IND
   Advertisement message, one or more IND Advertisement messages, with
   the same fields as the first message, SHOULD follow.  The Target
   Address List option(s) of the second, and subsequent message(s)
   SHOULD contain the rest of the IPv6 addresses of the interface
   identified by the Target Link-Layer Address, which did not fit in the
   first message.

   Note 1: The scope of the Inverse Neighbor Discovery mechanism is
   limited to IPv6 address discovery, that is, providing address mapping
   information.  Therefore, it does not make any provisions or rules
   regarding how a node uses the addresses that were returned in an
   Inverse Discovery message.  Furthermore, it does not exclude any
   particular type of IPv6 address from the Source or Target Address

   List.  For example, if an interface has manually configured, and
   autoconfigured addresses, including temporary ones, unicast,
   multicast, etc..., the list should not exclude any.

   Note 2: An implementation MUST NOT send duplicates in the IPv6
   address list.









Conta                       Standards Track                     [Page 8]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


4. Inverse Neighbor Discovery Protocol

   IND operates essentially the same as ND [IPv6-ND]: the solicitor of a
   target IP address sends on an interface a solicitation message, the
   target node responds with an advertisement message containing the
   information requested.  The information learned MAY be stored in the
   Neighbor Discovery cache [IPv6-ND], as well as IPv6 address
   structures which may be associated with the interface.

4.1  Sender Node Processing

   A soliciting node formats an IND Solicitation message as defined in a
   previous section, encapsulates the packet for the specific link-layer
   and sends it directly to the target node.  Although the destination
   IP address is the all-node multicast address, the message is sent
   only to the target node.  The significant fields for the IND protocol
   are the Source IP address, the Source link-layer address, the Target
   link-layer address, and the MTU.  The latter can be used in setting
   the optimum value of the MTU for the link.

   While awaiting a response, the sender SHOULD retransmit IND
   Solicitation messages approximately every RetransTimer
   (expiration)[IPv6-ND], even in the absence of additional traffic to
   the neighbor.  Retransmissions MUST be rate-limited to at most one
   solicitation per neighbor every RetransTimer.

   If no IND Advertisement is received after MAX_MULTICAST_SOLICIT
   [IPv6-ND] solicitations, inverse address resolution has failed.  If
   the sending of the Solicitation was required by an upper-layer, the
   sender module MUST notify the error to the upper-layer through an
   appropriate mechanism (e.g., return value from a procedure call).

4.2  Receiver Node Processing

4.2.1  Processing Inverse Neighbor Solicitation Messages

   For every IND Solicitation, the receiving node SHOULD format in
   response a proper IND Advertisement using the link-layer source and
   target address pair as well as the IPv6 source address from the IND
   Solicitation message.

   If a node updates the Neighbor Discovery Cache with information
   learned from IND messages, the receiver node of the IND Solicitation
   SHOULD put the sender's IPv6 address/link-layer address mapping -
   i.e., the source IP address and the Source link-layer address from
   the solicitation message - into its ND cache [IPv6-ND] as it would
   for a ND solicitation.




Conta                       Standards Track                     [Page 9]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   Because IPv6 nodes may have multiple IPv6 addresses per interface, a
   node responding to an IND Solicitation SHOULD return in the Target
   Address List option a list containing one or more IPv6 addresses
   corresponding to the interface identified by the Target Link-Layer
   Address field in the solicitation message.  The list MUST not contain
   duplicates.

4.2.2  Processing Inverse Neighbor Advertisement Messages

   If a node updates The Neighbor Discovery Cache with information
   learned from IND messages, the receiver node of the IND advertisement
   SHOULD put the sender's IPv6 address/link-layer address mapping -
   i.e., the IP addresses from Target addresses list and the Source
   link-layer address from the IND advertisement  message - into its ND
   cache [IPv6-ND] as it would for a ND advertisement.

4.3  Message Validation

   Inverse Neighbor Discovery messages are validated as follows:

4.3.1  Validation of Inverse Neighbor Discovery Solicitations

   A node MUST silently discard any received Inverse Neighbor
   Solicitation messages that do not satisfy all of the following
   validity checks:

   -     The IP Hop Limit field has a value of 255, i.e., the packet
         could not possibly have been forwarded by a router.

   -     If the message includes an IP Authentication Header, the
         message authenticates correctly.

   -     ICMP Checksum is valid.

   -     ICMP Code is 0.

   -     ICMP length (derived from the IP length) is 24 or more
         octets.

   -     The Target Link-Layer Address is a required option and MUST
         be present.

   -     The Source Link-Layer Address is a required option and MUST
         be present.

   -     All included options have a length that is greater than
         zero.




Conta                       Standards Track                    [Page 10]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   The content of the Reserved field, and of any unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to the protocol
   may specify the contents of the Reserved field or add new options;
   backward-incompatible changes may use different Code values.

   The contents of any Neighbor Discovery [IPv6-ND] options that are not
   specified to be used with Inverse Neighbor Discovery Solicitation
   messages MUST be ignored and the packet processed as normal.  The
   only defined option that may appear besides the required options is
   the MTU option.

   An Inverse Neighbor Solicitation that passes the validity checks is
   called a "valid solicitation".

4.3.2  Validation of Inverse Neighbor Discovery Advertisements

   A node MUST silently discard any received Inverse Neighbor Discovery
   Advertisement messages that do not satisfy all of the following
   validity checks:

   -     The IP Hop Limit field has a value of 255, i.e., the packet
         could not possibly have been forwarded by a router.

   -     If the message includes an IP Authentication Header, the
         message authenticates correctly.

   -     ICMP Checksum is valid.

   -     ICMP Code is 0.

   -     ICMP length (derived from the IP length) is 48 or more
         octets.

   -     Source Link-Layer Address option is present.

   -     Target Link-Layer Address option is present.

   -     The Target Address List option is present.

   -     The length of the Target Address List option is at least 3.

   -     All other included options have a length that is greater
         than zero.

   The contents of the Reserved fields, and of any unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to the protocol
   may specify the contents of the Reserved fields or add new options;
   backward-incompatible changes may use different Code values.



Conta                       Standards Track                    [Page 11]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   The contents of any defined options [IPv6-ND] that are not specified
   to be used with Inverse Neighbor Advertisement messages MUST be
   ignored and the packet processed as normal.  The only defined option
   that may appear besides the required options is the MTU option.

   An Inverse Neighbor Advertisement that passes the validity checks is
   called a "valid advertisement".

5. Security Considerations

   When being employed on point to point virtual circuits, as it is the
   case with Frame Relay networks, Inverse Neighbor Discovery messages
   are less sensitive to impersonation attacks from on-link nodes, as it
   would be the case with broadcast links.

   Like Neighbor Discovery, the protocol reduces the exposure to threats
   from off-link nodes in the absence of authentication by ignoring IND
   packets received from off-link senders.  The Hop Limit field of all
   received packets is verified to contain 255, the maximum legal value.
   Because routers decrement the Hop Limit on all packets they forward,
   received packets containing a Hop Limit of 255 must have originated
   from a neighbor.

   Inverse Neighbor Discovery protocol packet exchanges can be
   authenticated using the IP Authentication Header [IPSEC-Auth].  A
   node SHOULD include an Authentication Header when sending Inverse
   Neighbor Discovery packets if a security association for use with the
   IP Authentication Header exists for the destination address.  The
   security associations may have been created through manual
   configuration or through the operation of some key management
   protocol.

   Received Authentication Headers in Inverse Neighbor Discovery packets
   MUST be verified for correctness and packets with incorrect
   authentication MUST be ignored.

   In case of use with Frame Relay, to avoid an IP Security
   Authentication verification failure, the Frame Relay specific
   preprocessing of a Neighbor Discovery Solicitation message that
   contains a DLCI format Source link-layer address option, MUST be done
   by the receiver node after it completed IP Security processing.

   It SHOULD be possible for the system administrator to configure a
   node to ignore any Inverse Neighbor Discovery messages that are not
   authenticated using either the Authentication Header or Encapsulating
   Security Payload.  Such a switch SHOULD default to allowing
   unauthenticated messages.




Conta                       Standards Track                    [Page 12]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   Confidentiality issues are addressed by the IP Security Architecture
   and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC-
   ESP].

6. IANA Considerations

   IANA was requested to assign two new ICMPv6 type values, as described
   in Section 2.1 and 2.2.  They were assigned from the Informational
   range of messages, as defined in Section 2.1 of RFC 2463.  There were
   no ICMPv6 code values defined for these types (other than 0); future
   assignments are to be made under Standards Action as defined in RFC
   2434.

   IANA was also requested to assign two new ICMPv6 Neighbor Discovery
   Option types as defined in Section 3.1.  No outside reviewing was
   necessary.

7. Acknowledgments

   Thanks to Steve Deering, Thomas Narten and Erik Nordmark for
   discussing the idea of Inverse Neighbor Discovery.  Thanks to Thomas
   Narten, and Erik Nordmark, and also to Dan Harrington, Milan Merhar,
   Barbara Fox, Martin Mueller, and Peter Tam for a thorough reviewing.

   Also it should be acknowledged that parts of the text in this
   specification derived from the IPv6 Neighbor Discovery text [IPv6-
   ND].

8. References

   [IPv6]        Deering, S. and R. Hinden, "Internet Protocol Version 6
                 Specification", RFC 2460, December 1998.

   [IPv6-ND]     Narten, T., Nordmark, E. and W. Simpson "Neighbor
                 Discovery for IP Version 6 (IPv6)", RFC 2461, December
                 1998.

   [ICMPv6]      Conta, A., and S. Deering "Internet Control Message
                 Protocol for the Internet Protocol Version 6", RFC
                 2463, December 1998.

   [IPv6-FR]     Conta, A., Malis, A. and M. Mueller, "Transmission of
                 IPv6 Packets over Frame Relay Networks", RFC 2590, May
                 1999. December 1997.

   [IPSEC]       Atkinson, R. and S. Kent, "Security Architecture for
                 the Internet Protocol", RFC 2401, November 1998.




Conta                       Standards Track                    [Page 13]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   [IPSEC-Auth]  Atkinson, R. and S. Kent, "IP Authentication Header",
                 RFC 2402, December 1998.

   [IPSEC-ESP]   Atkinson, R. and S. Kent, "IP Encapsulating Security
                 Protocol (ESP)", RFC 2406, November 1998.

   [ASSIGN]      Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
                 RFC 1700, March 1994.

   [ENCAPS]      Brown, C. and A. Malis, "Multiprotocol Interconnect
                 over Frame Relay", RFC 2427, November 1998.

   [INV-ARP]     Bradley, T., Brown, C. and A. Malis "Inverse Address
                 Resolution Protocol", RFC 2390, August 1998.

   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

9. Authors' Addresses

   Alex Conta
   Transwitch Corporation
   3 Enterprise Drive
   Shelton, CT 06484

   Phone: +1-203-929-8810
   EMail: aconta@txc.com
























Conta                       Standards Track                    [Page 14]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


Appendix A

A. Inverse Neighbor Discovery with Frame Relay Networks

   This appendix documents the details of using the Inverse Neighbor
   Discovery on Frame Relay Networks, which were too specific to be part
   of the more general content of the previous sections.

A.1  Introduction

   The Inverse Neighbor Discovery (IND) specifically applies to Frame
   Relay nodes.  Frame Relay permanent virtual circuits (PVCs) and
   switched virtual circuits (SVCs) are identified in a Frame Relay
   network by a Data Link Connection Identifier (DLCI).  Each DLCI
   defines for a Frame Relay node a single virtual connection through
   the wide area network (WAN).  A DLCI has in general a local
   significance.

   By way of specific signaling messages, a Frame Relay network may
   announce to a node a new virtual circuit with its corresponding DLCI.
   The DLCI identifies to a node a virtual circuit, and can be used as
   the equivalent of a remote node link-layer address, allowing a node
   to identify at link layer level the node at the other end of the
   virtual circuit.  For instance in Figure 1., node A (local node)
   identifies the virtual circuit to node B (remote node) by way of DLCI
   = 30.  However, the signaling message does not contain information
   about the DLCI used by a remote node to identify the virtual circuit
   to the local node, which could be used as the equivalent of the local
   link-layer address.  For instance in Figure 1., node B (remote node)
   may identify the virtual circuit to node A by way of DLCI = 62.

   Furthermore, the message being transmitted at link-layer level and
   completely independent of the IPv6 protocol does not include any IPv6
   addressing information.  The Inverse Neighbor Discovery is a protocol
   that allows a Frame Relay node to discover the equivalent of a local
   link layer address, that is, the identifier by way of which remote
   nodes identify the node, and more importantly discover the IPv6
   addresses of the interface at the other end of the virtual circuit,
   identified by the remote link-layer address.












Conta                       Standards Track                    [Page 15]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


                              ~~~~~~~~~~~                 Remote
                             {           }                Node
           +-----+ DLCI     {             }         DLCI+-----+
           |  A  |-30------{--+----+----+--}---------62-|  B  |
           +-----+          {             }             +-----+
           Local             {           } Frame Relay
           Node               ~~~~~~~~~~~  Network Cloud
                                Figure 1.

   The IPv6 Inverse Neighbor Discovery (IND) protocol allows a Frame
   Relay node to discover dynamically the DLCI by which a remote node
   identifies the virtual circuit.  It also allows a node to learn the
   IPv6 addresses of a node at the remote end of a virtual circuit.

A.2. Inverse Neighbor Discovery Messages

   Frame Relay nodes generate Inverse Neighbor Discovery messages as
   follows:

A.2.1. Inverse Neighbor Discovery Solicitation Message

   The sender of an Inverse Neighbor Discovery Solicitation does not
   know the remote node's IPv6 addresses, but knows the equivalent of a
   remote node link-layer address.  Inverse Neighbor Discovery (IND)
   Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR],
   [ENCAPS].  However, at link layer level, an IND Solicitation is sent
   directly to the target node, identified by the known link-layer
   address (DLCI).

   The fields of the message, which are filled following considerations
   specific to Frame Relay are:

   Source Link-Layer Address
      For the sender Frame Relay node, the Source Link-Layer Address is
      the equivalent of the link-layer address by which the remote node
      identifies the source of this message.  The sender may have no
      knowledge of this information.  If the sender knows the
      information, it SHOULD include it in the field, otherwise it
      SHOULD live it zero (empty).  This information, if present, can be
      used for network debugging purposes.  Regardless of the sender's
      action on this field, prior to any Inverse Neighbor Discovery
      processing, the receiver of this message replaces this field,
      whether filled in or not by the sender, with information carried
      by the Frame Relay header in the DLCI field.  The field is encoded
      in DLCI format as defined by [IPv6-FR].






Conta                       Standards Track                    [Page 16]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   Target Link-Layer Address
      For sender Frame Relay node, the Target Link-Layer Address field
      is filled with the value known as the equivalent of the target
      node link-layer address.  This value is the DLCI of the VC to the
      target node.  It is encoded in DLCI format [IPv6-FR].

      To illustrate the generating of a IND Solicitation message by a
      Frame Relay node, let's consider as an example Node A (Figure 1.)
      which sends an IND solicitation to Node B.  The Solicitation
      message fields will have the following values:

            At Node A (sender of the IND solicitation message).

                   Source Link-Layer Address
                           DLCI=unknown (overwritten by the receiver).

                   Target Link-Layer Address
                           DLCI=30.

            At Node B (receiver of the IND solicitation message).

                   Source Link-Layer Address
                           DLCI=62 (filled in by the receiver).

                   Target Link-Layer Address
                           DLCI=30.

   Note: For Frame Relay, both the above addresses are in Q.922 format
   (DLCI), which can have 10 (default), or 23 significant addressing
   bits [IPv6-FR].  The option length (link-layer address) is expressed
   in 8 octet units, therefore, the DLCI will have to be extracted from
   the 8 bytes based on the EA field (bit 0) of the second, third, or
   forth octet (EA = 1).  The C/R, FECN, BECN, DE fields in the Q.922
   address have no significance for IND and are set to 0 [IPv6-FR].

   MTU
      The value filled in the MTU option is the MTU for the virtual
      circuit identified by the known DLCI [IPv6-FR].

A.2.2  Inverse Neighbor Discovery Advertisement Message

   A Frame Relay node sends Inverse Neighbor Discovery Advertisements in
   response to Inverse Neighbor Discovery Solicitations.

   The fields of the message, which are filled following considerations
   specific to Frame Relay are:





Conta                       Standards Track                    [Page 17]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


   Source Link-Layer Address
      For Frame Relay, this field is copied from the Target link-layer
      address field of the Inverse Neighbor Discovery Solicitation.  It
      is encoded in DLCI format [IPv6-FR].

   Target Link-Layer Address
      For Frame Relay, this field is copied from the Source link-layer
      address field of the Inverse Neighbor Discovery Solicitation.  It
      is encoded in DLCI format [IPv6-FR].

   For example if Node B (Figure 1.) responds to an IND solicitation
   sent by Node A. with an IND advertisement, these fields will have the
   following values:

         At Node B (sender of the advertisement message):

                  Source Link-Layer Address
                     DLCI=30 (was Target in Solicitation Message).

                  Target Link-Layer Address
                     DLCI=62 (was Source in Solicitation Message).

         At Node A (receiver of the advertisement message from B).

                   Source Link-Layer Address
                     DLCI=30 (was Target in Solicitation Message).

                   Target Link-Layer Address
                     DLCI=62 (was Source in Solicitation Message).

   Target Address List
      The list of one or more IPv6 addresses of the interface identified
      by the Target Link-Layer Address in the Inverse Neighbor Discovery
      Solicitation message that prompted this advertisement.

   MTU The MTU configured for this link (virtual circuit) [IPv6-ND].

      Note:  In case of Frame Relay networks, the IND messages are sent
      on a virtual circuit, which acts like a virtual-link.  If the
      virtual circuit breaks, all participants to the circuit receive
      appropriate link layer signaling messages, which can be propagated
      to the  upper layers, including IPv6.

A.3. Inverse Neighbor Discovery Protocol

   This section of the appendix documents only the specific aspects of
   Inverse Neighbor Discovery with Frame Relay Networks.




Conta                       Standards Track                    [Page 18]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


A.3.1  Sender Node Processing

   A soliciting Frame Relay node formats an IND solicitation message as
   defined in a previous section, encapsulates the packet for the Frame
   Relay link-layer [IPv6-FR] and sends it to the target Frame Relay
   node.  Although the destination IP address is the IPv6 all-node
   multicast address, the message is sent only to the target Frame Relay
   node.  The target node is the known remote node on the link
   represented by the virtual circuit.

A.3.2  Receiver Node Processing

A.3.2.1  Processing Inverse Neighbor Solicitation Messages

   A Frame Relay node, before further processing, is replacing in the
   Source link-layer address the existent DLCI value with the DLCI value
   from the Frame Relay header of the frame containing the message.  The
   DLCI value has to be formatted appropriately in the Source link-layer
   address field [IPv6-FR].  This operation is required to allow a
   correct interpretation of the fields in the further processing of the
   IND solicitation message.

   For a Frame Relay node, the MTU value from the solicitation message
   MAY be used to set the receiver's MTU to a value that is more
   optimal, in case that was not already done at the interface
   configuration time.

A.3.2.2  Processing Inverse Neighbor Advertisement Messages

   The receiver Frame Relay node of the IND Advertisement MAY put the
   sender's IPv6 address/link-layer address mapping - i.e., the Target
   IP addresses and the Source link-layer address from the IND
   advertisement  message - into its ND cache [IPv6-ND] as it would for
   a ND Advertisement.

   Further, the receiver Frame Relay node of the IND Advertisement MAY
   store the Target link-layer address from the message as the DLCI
   value at the remote end of the VC.  This DLCI value is the equivalent
   of the link-layer address by which the remote node identifies the
   receiver.

   If the receiver node of the IND Advertisement has a pool of IPv6
   addresses, and if the implementation allows, it may take decisions to
   pairing specific local IPv6 addresses to specific IPv6 addresses from
   the target list in further communications on the VC.  More
   specifically, such a pairing may be based on IPv6 addresses being on
   the same subnet, that is having the same prefix.




Conta                       Standards Track                    [Page 19]

RFC 3122         Extensions to IPv6 Neighbor Discovery         June 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Conta                       Standards Track                    [Page 20]