idnits 2.17.1 draft-ietf-ion-ipv6-ind-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 425 has weird spacing: '...isement messa...' == Line 563 has weird spacing: '...ections of th...' == Line 823 has weird spacing: '... to the upper...' == Line 864 has weird spacing: '...isement messa...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2000) is 8685 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPv6-IND' is mentioned on line 71, but not defined == Unused Reference: 'ASSIGN' is defined on line 615, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' ** Obsolete normative reference: RFC 2461 (ref. 'IPv6-ND') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-FR' ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'IPSEC-Auth') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'IPSEC-ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 1700 (ref. 'ASSIGN') (Obsoleted by RFC 3232) Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ION/IPng Working Groups A. Conta (Transwitch) 3 INTERNET-DRAFT 4 July 2000 6 Extensions to IPv6 Neighbor Discovery for Inverse Discovery 8 Specification 10 draft-ietf-ion-ipv6-ind-04.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This memo describes extensions to the IPv6 Neighbor Discovery that 36 allow a node to solicit and /be advertised/advertise/ an IPv6 address 37 corresponding to a given link-layer address. These extensions are 38 called Inverse Neighbor Discovery. They /specifically apply to/were 39 developed for/ Frame Relay networks but they may also apply to other 40 networks with similar behavior. 42 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 44 Table of Contents 46 1. Introduction......................................................3 47 2. Inverse Neighbor Discovery Messages...............................3 48 2.1 Inverse Neighbor Discovery Solicitation Message...............3 49 2.2 Inverse Neighbor Discovery Advertisement Message..............5 50 3. Inverse Neighbor Discovery Options Format.........................7 51 3.1 Target Address List...........................................7 52 4. Inverse Neighbor Discovery Protocol...............................9 53 4.1 Sender Node Processing.......................................10 54 4.2 Receiver Node Processing.....................................10 55 4.2.1 Processing Inverse Neighbor Discovery Solicitations......10 56 4.2.2 Processing Inverse Neighbor Discovery Advertisements.....11 57 4.3 Message Validation...........................................11 58 4.3.1 Validation of Inverse Neighbor Discovery Solicitations...11 59 4.3.2 Validation of Inverse Neighbor Discovery Advertisements..12 60 5. Security Considerations..........................................13 61 6. IANA Considerations..............................................13 62 7. Acknowledgments..................................................14 63 8. References.......................................................14 64 9. Authors' Addresses...............................................16 65 Appendix A..........................................................17 66 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 68 1. Introduction 70 This document defines extensions to the IPv6 Neighbor Discovery 71 (ND)[IPv6-IND]. The extensions are called IPv6 Inverse Neighbor 72 Discovery (IND). The IPv6 Inverse Neighbor Discovery (IND) allows a 73 node that knows the link-layer address of a directly connected remote 74 node to learn the IPv6 addresses of that node. A node using IND sends 75 solicitations and receives advertisements for one or more IPv6 76 addresses corresponding to a known link-layer address. 78 The Inverse Neighbor Discovery (IND) /specifically applies to/was 79 developed for/ Frame Relay networks. It may apply also to other 80 networks that have a similar behavior. 82 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 83 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as 84 defined in [KEYWORDS]. 86 There is a number of similarities and differences between the 87 mechanisms described here and those defined for Inverse ARP for IPv4 88 in [INV-ARP] or its replacement documents. 90 2. Inverse Neighbor Discovery Messages 92 The following messages are defined: 94 2.1. Inverse Neighbor Discovery Solicitation Message 96 A node sends an Inverse Neighbor Discovery Solicitation message to 97 request an IPv6 address corresponding to a link-layer address of the 98 target node while also providing its own link-layer address to the 99 target. Since the remote node IPv6 addresses are not known, Inverse 100 Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node 101 multicasts [IPv6], [IPv6-FR], [ENCAPS]. However, at link layer level, 102 an IND Solicitation is sent directly to the target node, identified 103 by the known link-layer address. 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Type | Code | Checksum | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Reserved | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Options ... 113 +-+-+-+-+-+-+-+-+-+-+-+- 114 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 116 IP Fields: 118 Source Address 119 An IPv6 address assigned to the interface from 120 which this message is sent. 122 Destination Address 123 The IPv6 all-node multicast address. This address 124 is specified in its link-scope format, which is 125 FF02::1. 127 Hop Limit 255 129 Authentication Header 130 If a Security Association for the IP Authentication 131 Header exists between the sender and the 132 destination link-layer address, then the sender 133 SHOULD include this header. 135 ICMP Fields: 137 Type [Value to be assigned by IANA] 139 Note: The Type value should be assigned from the IPv6 Neighbor 140 Discovery family of values. 142 Code 0 144 Checksum The ICMP checksum. See [ICMPv6]. 146 Reserved This field is unused. It MUST be initialized to 147 zero by the sender and MUST be ignored by the 148 receiver. 150 Required options: 152 The sender node MUST send the following options in the Solicitation 153 message: 155 Source Link-Layer Address 156 The link-layer address of the sender. 158 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 160 Target Link-Layer Address 161 The link-layer address of the target node. 163 Other valid options: 165 The sender node MAY choose to add the following options in the 166 Solicitation message: 168 Source Address List 169 The list of one or more IPv6 addresses of the 170 interface identified by the Source Link-Layer 171 Address. This option is defined in section 3. 173 MTU The MTU configured for this link [IPv6-ND]. 175 Future versions of this protocol may add other option types. 176 Receivers MUST silently ignore any options they do not recognize and 177 continue processing the message. 179 2.2 Inverse Neighbor Discovery Advertisement Message 181 A node sends Inverse Neighbor Discovery Advertisements in response to 182 Inverse Neighbor Discovery Solicitations. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type | Code | Checksum | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Reserved | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Options ... 192 +-+-+-+-+-+-+-+-+-+-+-+- 194 IP Fields: 196 Source Address 197 An address assigned to the interface from which the 198 advertisement is sent. 200 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 202 Destination Address 203 The Source Address of an invoking Inverse Discovery 204 Neighbor Solicitation. 206 Hop Limit 255 208 Authentication Header 209 If a Security Association for the IP Authentication 210 Header exists between the sender and the 211 destination address, then the sender SHOULD include 212 this header. 214 ICMP Fields: 216 Type [Value to be assigned by IANA] 218 Note: The Type value should be assigned from the IPv6 Neighbor 219 Discovery family of values. 221 Code 0 223 Checksum The ICMP checksum. See [ICMPv6]. 225 Reserved 32-bit unused field. It MUST be initialized to 226 zero by the sender and MUST be ignored by the 227 receiver. 229 Required options: 231 The sender node MUST send the following options in the Advertisement 232 message: 234 Source Link-Layer Address 235 This field is copied from the Target link-layer 236 address field of the Inverse Neighbor Discovery 237 Solicitation. 239 Target Link-Layer Address 240 This field is copied from the Source link-layer 241 address field of the Inverse Neighbor Discovery 242 Solicitation. 244 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 246 Target Address List 247 The list of one or more IPv6 addresses of the 248 interface identified by the Target Link-Layer 249 Address in the Inverse Neighbor Discovery 250 Solicitation message that prompted this 251 advertisement. This option is defined in Section 3. 253 Other valid options: 255 The sender node MAY choose to add the following option in the 256 Advertisement message: 258 MTU The MTU configured for this link 259 [IPv6-ND]. 261 Future versions of this protocol may add other option types. 262 Receivers MUST silently ignore any options they do not recognize and 263 continue processing the message. 265 3. Inverse Neighbor Discovery Options Formats 267 Inverse Neighbor Discovery messages include Neighbor Discovery 268 options [IPv6-ND] as well as an Inverse Neighbor Discovery specific 269 options: the Source Address List and the Target Address List. 271 3.1 Source/Target Address List 273 The Source Address List and the Target Address List option are TLV 274 options (type, length, variable size field) (see Section 4.6 of 275 [IPv6-ND] with the following fields: 277 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type | Length | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - + 284 | Reserved | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 + + 288 | | 289 + IPv6 Address + 290 | | 291 + + 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 + + 296 | | 297 + IPv6 Address + 298 | | 299 + + 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | 303 ~ 304 | 305 +-+-+-+-+... 307 Fields: 309 Type [To be assigned by IANA] for Source Address List 310 [To be assigned by IANA] for Target Address List 312 Note: These Option Type values should be assigned from the IPv6 313 Neighbor Discovery family of values. 315 Length The length of the option (including the Type, 316 Length, and the Reserved fields) in units of 8 317 octets. The minimum value for Length is 3, for one 318 IPv6 address. 320 Reserved This field is unused. It MUST be initialized to 321 zero by the sender and MUST be ignored by the 322 receiver. 324 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 326 IPv6 Addresses One or more IPv6 addresses of the interface. 328 Description: 330 The Source Address List contains a list of IPv6 addresses of the 331 interface identified by the Source Link-Layer Address. 333 The Target Address List contains a list of IPv6 addresses of the 334 interface identified by the Target Link-Layer Address. 336 The number of addresses "n" in the list is calculated based on the 337 length of the option: 339 n = (Length - 1)/2 (Length is the number of groups of 8 octets) 341 The Source Address List MUST fit in one IND Solicitation message. 342 Therefore in case all IPv6 addresses of an interface do not fit in 343 one messages, the option does not contain a complete list. For a 344 complete list of IPv6 addresses, a node should rely on the IND 345 Advertisement message. 347 The Target Address List SHOULD be the complete list of addresses of 348 the interface identified by the Target Link-Layer Address. If the 349 list of IPv6 addresses of an interface does not fit in one IND 350 Advertisement message, one or more IND Advertisement messages, with 351 the same fields as the first message, SHOULD follow. The Target 352 Address List option(s) of the second, and subsequent message(s) 353 SHOULD contain the rest of the IPv6 addresses of the interface 354 identified by the Target Link-Layer Address, which did not fit in the 355 first message. 357 Note: An implementation MUST NOT send duplicates in the IPv6 address 358 list. 360 4. Inverse Neighbor Discovery Protocol 362 IND operates essentially the same as ND [IPv6-ND]: the solicitor of a 363 target IP address sends on an interface a solicitation message, the 364 target node responds with an advertisement message containing the 365 information requested. The information learned MAY be stored in the 366 Neighbor Discovery cache [IPv6-ND], as well as IPv6 address 367 structures which may be associated with the interface. 369 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 371 4.1 Sender Node Processing 373 A soliciting node formats an IND Solicitation message as defined in a 374 previous section, encapsulates the packet for the specific link-layer 375 and sends it directly to the target node. Although the destination IP 376 address is the all-node multicast address, the message is sent only 377 to the target node. The significant fields for the IND protocol are 378 the Source IP address, the Source link-layer address, the Target 379 link-layer address, and the MTU. The latter can be used in setting 380 the optimum value of the MTU for the link. 382 While awaiting a response, the sender SHOULD retransmit IND 383 Solicitation messages approximately every RetransTimer 384 (expiration)[IPv6-ND], even in the absence of additional traffic to 385 the neighbor. Retransmissions MUST be rate-limited to at most one 386 solicitation per neighbor every RetransTimer. 388 If no IND Advertisement is received after MAX_MULTICAST_SOLICIT 389 [IPv6-ND] solicitations, inverse address resolution has failed. If 390 the sending of the Solicitation was required by an upper-layer, the 391 sender module MUST notify the error to the upper-layer through an 392 appropriate mechanism (e.g. return value from a procedure call). 394 4.2 Receiver Node Processing 396 4.2.1 Processing Inverse Neighbor Solicitation Messages 398 For every IND Solicitation, the receiving node SHOULD format in 399 response a proper IND Advertisement using the link-layer source and 400 target address pair as well as the IPv6 source address from the IND 401 Solicitation message. 403 If a node updates the Neighbor Discovery Cache with information 404 learned from IND messages, the receiver node of the IND Solicitation 405 SHOULD put the sender's IPv6 address/link-layer address mapping - 406 i.e. the source IP address and the Source link-layer address from the 407 solicitation message - into its ND cache [IPv6-ND] as it would for a 408 ND solicitation. 410 Because IPv6 nodes may have multiple IPv6 addresses per interface, a 411 node responding to an IND Solicitation SHOULD return in the Target 412 Address List option a list containing one or more IPv6 addresses 413 corresponding to the interface identified by the Target Link-Layer 414 Address field in the solicitation message. The list MUST not contain 415 duplicates. 417 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 419 4.2.2 Processing Inverse Neighbor Advertisement Messages 421 If a node updates The Neighbor Discovery Cache with information 422 learned from IND messages, the receiver node of the IND advertisement 423 SHOULD put the sender's IPv6 address/link-layer address mapping - 424 i.e. the IP addresses from Target addresses list and the Source 425 link-layer address from the IND advertisement message - into its ND 426 cache [IPv6-ND] as it would for a ND advertisement. 428 4.3 Message Validation 430 Inverse Neighbor Discovery messages are validated as follows: 432 4.3.1 Validation of Inverse Neighbor Discovery Solicitations 434 A node MUST silently discard any received Inverse Neighbor 435 Solicitation messages that do not satisfy all of the following 436 validity checks: 438 - The IP Hop Limit field has a value of 255, i.e., the packet 439 could not possibly have been forwarded by a router. 441 - If the message includes an IP Authentication Header, the 442 message authenticates correctly. 444 - ICMP Checksum is valid. 446 - ICMP Code is 0. 448 - ICMP length (derived from the IP length) is 24 or more 449 octets. 451 - The Target Link-Layer Address is a required option and MUST 452 be present. 454 - The Source Link-Layer Address is a required option and MUST 455 be present. 457 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 459 - All included options have a length that is greater than 460 zero. 462 The content of the Reserved field, and of any unrecognized options, 463 MUST be ignored. Future, backward-compatible changes to the protocol 464 may specify the contents of the Reserved field or add new options; 465 backward-incompatible changes may use different Code values. 467 The contents of any Neighbor Discovery [IPv6-ND] options that are not 468 specified to be used with Inverse Neighbor Discovery Solicitation 469 messages MUST be ignored and the packet processed as normal. The only 470 defined option that may appear besides the required options is the 471 MTU option. 473 An Inverse Neighbor Solicitation that passes the validity checks is 474 called a "valid solicitation". 476 4.3.2 Validation of Inverse Neighbor Discovery Advertisements 478 A node MUST silently discard any received Inverse Neighbor Discovery 479 Advertisement messages that do not satisfy all of the following 480 validity checks: 482 - The IP Hop Limit field has a value of 255, i.e., the packet 483 could not possibly have been forwarded by a router. 485 - If the message includes an IP Authentication Header, the 486 message authenticates correctly. 488 - ICMP Checksum is valid. 490 - ICMP Code is 0. 492 - ICMP length (derived from the IP length) is 48 or more 493 octets. 495 - Source Link-Layer Address option is present. 497 - Target Link-Layer Address option is present. 499 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 501 - The Target Address List option is present. 503 - The length of the Target Address List option is at least 3. 505 - All other included options have a length that is greater 506 than zero. 508 The contents of the Reserved fields, and of any unrecognized options, 509 MUST be ignored. Future, backward-compatible changes to the protocol 510 may specify the contents of the Reserved fields or add new options; 511 backward-incompatible changes may use different Code values. 513 The contents of any defined options [IPv6-ND] that are not specified 514 to be used with Inverse Neighbor Advertisement messages MUST be 515 ignored and the packet processed as normal. The only defined option 516 that may appear besides the required options is the MTU option. 518 An Inverse Neighbor Advertisement that passes the validity checks is 519 called a "valid advertisement". 521 5. Security Considerations 523 When being employed on point to point virtual circuits, as it is the 524 case with Frame Relay networks, Inverse Neighbor Discovery messages 525 are less sensitive to impersonation attacks from on-link nodes, as it 526 would be the case with broadcast links. 528 Like Neighbor Discovery, the protocol reduces the exposure to threats 529 from off-link nodes in the absence of authentication by ignoring IND 530 packets received from off-link senders. The Hop Limit field of all 531 received packets is verified to contain 255, the maximum legal value. 532 Because routers decrement the Hop Limit on all packets they forward, 533 received packets containing a Hop Limit of 255 must have originated 534 from a neighbor. 536 Inverse Neighbor Discovery protocol packet exchanges can be 537 authenticated using the IP Authentication Header [IPSEC-Auth]. A 538 node SHOULD include an Authentication Header when sending Inverse 539 Neighbor Discovery packets if a security association for use with the 540 IP Authentication Header exists for the destination address. The 541 security associations may have been created through manual 542 configuration or through the operation of some key management 543 protocol. 545 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 547 Received Authentication Headers in Inverse Neighbor Discovery packets 548 MUST be verified for correctness and packets with incorrect 549 authentication MUST be ignored. 551 It SHOULD be possible for the system administrator to configure a 552 node to ignore any Inverse Neighbor Discovery messages that are not 553 authenticated using either the Authentication Header or Encapsulating 554 Security Payload. Such a switch SHOULD default to allowing 555 unauthenticated messages. 557 Confidentiality issues are addressed by the IP Security Architecture 558 and the IP Encapsulating Security Payload documents [IPSEC], [IPSEC- 559 ESP]. 561 6. IANA Considerations 563 Values marked in previous sections of this specification as "Value 564 to be assigned by IANA", or "To be assigned by IANA" need to be 565 assigned by IANA. 567 The ICMP Type values should be assigned similarly to the other ICMP 568 Type values. It is preffered to assign, if possible, an ICMP Type 569 value from the IPv6 Neighbor Discvery family of values, that is, 570 close or in sequential order with the ICMP Type values assigned for 571 the IPv6 Neighbor Discovery. No outside reviewing is necessary. 573 The Option Type Value should be assigned similarly to the IPv6 574 Neighbor Discovery Option Type values. It is preffered to assign, if 575 possible, an Option Type value close or in sequential order with the 576 Option Type values assigned to the IPv6 Neighbor Discovery. No 577 outside reviewing is necessary. 579 7. Acknowledgments 581 Thanks to Steve Deering, Thomas Narten and Eric Nordmark for 582 discussing the idea of Inverse Neighbor Discovery. Thanks to Thomas 583 Narten, and Erik Nordmark, and also to Dan Harrington, Milan Merhar, 584 Barbara Fox, Martin Mueller, and Peter Tam for a thorough reviewing. 586 Also it should be acknowledged that parts of the text in this 587 specification derived from the IPv6 Neighbor Discovery text [IPv6- 588 ND]. 590 8. References 592 [IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6 593 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 595 Specification", RFC 2460, December 1998. 597 [IPv6-ND] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for 598 IP Version 6 (IPv6)", RFC 2461, December 1998. 600 [ICMPv6] A. Conta, S. Deering "Internet Control Message Protocol for 601 the Internet Protocol Version 6", RFC 2463, December 1998. 603 [IPv6-FR] A. Conta, A. Malis, M. Mueller, "Transmission of IPv6 604 Packets over Frame Relay networks" Work in Progress, December 1997. 606 [IPSEC] Atkinson, R., S. Kent, "Security Architecture for the 607 Internet Protocol", RFC 2401, November 1998. 609 [IPSEC-Auth] Atkinson, R., S. Kent, "IP Authentication Header", RFC 610 2402, December 1998. 612 [IPSEC-ESP] Atkinson, R., S. Kent, "IP Encapsulating Security 613 Protocol (ESP)", RFC 2406, November 1998. 615 [ASSIGN] J. Reynolds, J. Postel, "Assigned Numbers", RFC 1700. 617 [ENCAPS] C. Brown, A. Malis, "Multiprotocol Interconnect over Frame 618 Relay", RFC 2427, November 1998. 620 [INV-ARP] T. Bradley, C. Brown, A.Malis "Inverse Address Resolution 621 Protocol",RFC 2390, August 1998 623 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, March 1997. 626 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 628 9. Authors' Addresses 630 Alex Conta 631 Transwitch Corporation 632 3 Enterprise Drive 633 Shelton, CT 06484 634 +1-203-929-8810 635 email: aconta@txc.com 636 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 638 Appendix A 640 A. Inverse Neighbor Discovery with Frame Relay Networks 642 This appendix documents the details of using the Inverse Neighbor 643 Discovery on Frame Relay Networks, which were too specific to be part 644 of the more general content of the previous sections. 646 A.1 Introduction 648 The Inverse Neighbor Discovery (IND) specifically applies to Frame 649 Relay nodes. Frame Relay permanent virtual circuits (PVCs) and 650 switched virtual circuits (SVCs) are identified in a Frame Relay 651 network by a Data Link Connection Identifier (DLCI). Each DLCI 652 defines for a Frame Relay node a single virtual connection through 653 the wide area network (WAN). A DLCI has in general a local 654 significance. 656 By way of specific signaling messages, a Frame Relay network may 657 announce to a node a new virtual circuit with its corresponding DLCI. 658 The DLCI identifies to a node a virtual circuit, and can be used as 659 the equivalent of a remote node link-layer address, allowing a node 660 to identify at link layer level the node at the other end of the 661 virtual circuit. For instance in Figure 1., node A (local node) 662 identifies the virtual circuit to node B (remote node) by way of DLCI 663 = 30. However, the signaling message does not contain information 664 about the DLCI used by a remote node to identify the virtual circuit 665 to the local node, which could be used as the equivalent of the local 666 link-layer address. For instance in Figure 1., node B (remote node) 667 may identify the virtual circuit to node A by way of DLCI = 62. 669 Furthermore, the message being transmitted at link-layer level and 670 completely independent of the IPv6 protocol does not include any IPv6 671 addressing information. Therefore it seems to be useful to define a 672 protocol that allows a Frame Relay node to discover the equivalent of 673 a local link layer address, that is, the identifier by way of which 674 remote nodes identify the node, and more importantly discover the 675 IPv6 addresses of the interface at the other end of the virtual 676 circuit, identified by the remote link-layer address. 678 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 680 ~~~~~~~~~~~ Remote 681 { } Node 682 +-----+ DLCI { } DLCI+-----+ 683 | A |-30------{--+----+----+--}---------62-| B | 684 +-----+ { } +-----+ 685 Local { } Frame Relay 686 Node ~~~~~~~~~~~ Network Cloud 688 Figure 1. 690 The IPv6 Inverse Neighbor Discovery (IND) protocol allows a Frame 691 Relay node to discover dynamically the DLCI by which a remote node 692 identifies the virtual circuit. It also allows a node to learn the 693 IPv6 addresses of a node at the remote end of a virtual circuit. 695 A.2. Inverse Neighbor Discovery Messages 697 The Inverse Neighbor Discovery messages are generated by Frame Relay 698 nodes as follows: 700 A.2.1. Inverse Neighbor Discovery Solicitation Message 702 The sender of an Inverse Neighbor Discovery Solicitation does not 703 know the remote node's IPv6 addresses, but knows the equivalent of a 704 remote node link-layer address. Inverse Neighbor Discovery (IND) 705 Solicitations are sent as IPv6 all-node multicasts [IPv6], [IPv6-FR], 706 [ENCAPS]. However, at link layer level, an IND Solicitation is sent 707 directly to the target node, identified by the known link-layer 708 address (DLCI). 710 The fields of the message which are filled following considerations 711 specific to Frame Relay are: 713 Source Link-Layer Address 714 For the sender Frame Relay node, the Source Link-Layer Address is 715 the equivalent of the link-layer address by which the remote node 716 identifies the source of this message. The sender may have no 717 knowledge of this information, and may leave this field empty. 718 Therefore prior to any Inverse Neighbor Discovery processing, the 719 receiver of this message replaces this field, whether filled in or 720 not by the sender, with information carried by the Frame Relay 721 header in the DLCI field. The field is encoded in DLCI format as 722 defined by [IPv6-FR]. 724 Target Link-Layer Address 725 For sender Frame Relay node, the Target Link-Layer Address field 726 is filled with the value known as the equivalent of the target 727 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 729 node link-layer address. This value is the DLCI of the VC to the 730 target node. It is encoded in DLCI format [IPv6-FR]. 732 To illustrate the generating of a IND Solicitation message by a Frame 733 Relay node, let's consider as an example Node A (Figure 1.) which 734 sends an IND solicitation to Node B. The Solicitation message fields 735 will have the following values: 737 At Node A (sender of the IND solicitation message). 739 Source Link-Layer Address 740 DLCI=unknown (overwritten by the receiver). 742 Target Link-Layer Address 743 DLCI=30. 745 At Node B (receiver of the IND solicitation message). 747 Source Link-Layer Address 748 DLCI=62 (filled in by the receiver). 750 Target Link-Layer Address 751 DLCI=30. 753 Note: For Frame Relay, both the above addresses are in Q.922 format 754 (DLCI), which can have 10 (default), or 23 significant addressing 755 bits [IPv6-FR]. The option length (link-layer address) is expressed 756 in 8 octet units, therefore, the DLCI will have to be extracted from 757 the 8 bytes based on the EA field (bit 0) of the second, third, or 758 forth octet (EA = 1). The C/R, FECN, BECN, DE fields in the Q.922 759 address have no significance for IND and are set to 0 [IPv6-FR]. 761 MTU 762 The value filled in the MTU option is the MTU for the virtual 763 circuit identified by the known DLCI [IPv6-FR]. 765 A.2.2 Inverse Neighbor Discovery Advertisement Message 767 A Frame Relay node sends Inverse Neighbor Discovery Advertisements in 768 response to Inverse Neighbor Discovery Solicitations. 770 The fields of the message which are filled following considerations 771 specific to Frame Relay are: 773 The "Override" Bit in the message header. 774 For Frame Relay, the Inverse Neighbor Discovery Advertisement 775 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 777 messages unlike the Neighbor Discovery Advertisement messages 778 carrying DLCI format link-layer addresses, SHOULD have the 779 Override bit "O", in the message header set to 1. 781 Source Link-Layer Address 782 For Frame Relay, this field is copied from the Target link-layer 783 address field of the Inverse Neighbor Discovery Solicitation. It 784 is encoded in DLCI format [IPv6-FR]. 786 Target Link-Layer Address 787 For Frame Relay, this field is copied from the Source link-layer 788 address field of the Inverse Neighbor Discovery Solicitation. It 789 is encoded in DLCI format [IPv6-FR]. 791 For example if Node B (Figure 1.) responds to an IND solicitation 792 sent by Node A. with an IND advertisement, these fields will have the 793 following values: 795 At Node B (sender of the advertisement message): 797 Source Link-Layer Address 798 DLCI=30 (was Target in Solicitation Message). 800 Target Link-Layer Address 801 DLCI=62 (was Source in Solicitation Message). 803 At Node A (receiver of the advertisement message from B). 805 Source Link-Layer Address 806 DLCI=30 (was Target in Solicitation Message). 808 Target Link-Layer Address 809 DLCI=62 (was Source in Solicitation Message). 811 Target Address List 812 The list of one or more IPv6 addresses of the interface identified 813 by the Target Link-Layer Address in the Inverse Neighbor Discovery 814 Solicitation message that prompted this advertisement. 816 MTU 817 The MTU configured for this link (virtual circuit) [IPv6-ND]. 819 Note: In case of Frame Relay networks, the IND messages are sent 820 on a virtual circuit, which acts like a virtual-link. If the 821 virtual circuit breaks, all participants to the circuit receive 822 appropriate link layer signaling messages, which can be propagated 823 to the upper layers, including IPv6. 825 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 827 A.3. Inverse Neighbor Discovery Protocol 829 This section of the appendix documents only the specific aspects of 830 Inverse Neighbor Discovery with Frame Relay Networks. 832 A.3.1 Sender Node Processing 834 A soliciting Frame Relay node formats an IND solicitation message as 835 defined in a previous section, encapsulates the packet for the Frame 836 Relay link-layer [IPv6-FR] and sends it to the target Frame Relay 837 node. Although the destination IP address is the IPv6 all-node 838 multicast address, the message is sent only to the target Frame Relay 839 node. The target node is the known remote node on the link 840 represented by the virtual circuit. 842 A.3.2 Receiver Node Processing 844 A.3.2.1 Processing Inverse Neighbor Solicitation Messages 846 A Frame Relay node, before further processing, is replacing in the 847 Source link-layer address the existent DLCI value with the DLCI value 848 from the Frame Relay header of the frame containing the message. The 849 DLCI value has to be formatted appropriately in the Source link-layer 850 address field [IPv6-FR]. This operation is required to allow a 851 correct interpretation of the fields in the further processing of the 852 IND solicitation message. 854 For a Frame Relay node, the MTU value from the solicitation message 855 MAY be used to set the receiver's MTU to a value that is more 856 optimal, in case that was not already done at the interface 857 configuration time. 859 A.3.2.2 Processing Inverse Neighbor Advertisement Messages 861 The receiver Frame Relay node of the IND Advertisement MAY put the 862 sender's IPv6 address/link-layer address mapping - i.e. the Target IP 863 addresses and the Source link-layer address from the IND 864 advertisement message - into its ND cache [IPv6-ND] as it would for 865 a ND Advertisement. 867 Further, the receiver Frame Relay node of the IND Advertisement MAY 868 store the Target link-layer address from the message as the DLCI 869 value at the remote end of the VC. This DLCI value is the equivalent 870 of the link-layer address by which the remote node identifies the 871 receiver. 873 INTERNET-DRAFT IPv6 Inverse Neighbor Discovery July 13, 19100 875 If the receiver node of the IND Advertisement has a pool of IPv6 876 addresses, and if the implementation allows, it may take decisions to 877 pairing specific local IPv6 addresses to specific IPv6 addresses from 878 the target list in further communications on the VC. More 879 specifically, such a pairing may be based on IPv6 addresses being on 880 the same subnet. 882 1298