idnits 2.17.1 draft-conta-ipv6-nd_ext_ind-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-conta-ipv6-nd_ext_ind-00', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 78 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 21 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 79: '... The keywords MUST, MUST NOT, MAY, O...' RFC 2119 keyword, line 80: '... SHALL, SHALL NOT, SHOULD, SHOUL...' RFC 2119 keyword, line 127: '...yer address, then the sender SHOULD...' RFC 2119 keyword, line 137: '...d is unused. It MUST be initialized t...' RFC 2119 keyword, line 138: '...the sender and MUST be ignored by...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 20 has weird spacing: '...-Drafts may ...' == Line 21 has weird spacing: '...iate to use ...' == Line 25 has weird spacing: '... please check...' == Line 26 has weird spacing: '...listing conta...' == Line 35 has weird spacing: '...n as an exten...' == (73 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 1997) is 9782 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: 'TBD' is mentioned on line 132, but not defined == Missing Reference: 'ICMPv6' is mentioned on line 220, but not defined == Missing Reference: 'IPv6FR' is mentioned on line 275, but not defined == Missing Reference: 'IPV6FR' is mentioned on line 271, but not defined == Unused Reference: 'RFC-1883' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC-1970' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC-1825' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC-1826' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC-2200' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC-1293' is defined on line 348, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1970 (Obsoleted by RFC 2461) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 2200 (Obsoleted by RFC 2300) ** Obsolete normative reference: RFC 1293 (Obsoleted by RFC 2390) Summary: 20 errors (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPng Working Group A. Conta (Lucent) 3 INTERNET-DRAFT 4 July 1997 6 IPv6 Neighbor Discovery Extensions for Inverse Discovery 8 Specification 10 draft-conta-ipv6-nd_ext_ind-00.txt 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working doc- 15 uments of the Internet Engineering Task Force (IETF), its Areas, and 16 its Working Groups. Note that other groups may also distribute work- 17 ing documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 27 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Distribution of this memo is unlimited. 33 Abstract 35 This memo describes a mechanism that can be seen as an extension to 36 the IPv6 Neighbor Discovery. It allows a node to solicit and be 37 advertized an IPv6 address corresponding to a given link-layer 38 address. Because the known parameter is the link layer address, the 39 mechanism is called Inverse Neighbor Discovery. It specifically 40 applies to Frame Relay nodes that may have a Data Link Connection 41 Identifier (DLCI), the Frame Relay equivalent of a link-layer 42 address, associated with an established Permanent Virtual Circuit 43 (PVC), but do not know the IPv6 address of the node at the other end 44 of the circuit. It may also apply to other networks with similar 45 behavior. 47 1. Introduction 49 This document defines an extension mechanism to the IPv6 Neighbor 50 Discovery that will allow a node to solicit and be advertised an IPv6 51 address corresponding to a given link-layer address. Because the 52 input parameter is the link layer address, the mechanism is called 53 Inverse Neighbor Discovery. 55 The Inverse Neighbor Discovery (IND) specifically applies to Frame 56 Relay nodes. Frame Relay permanent virtual circuits (PVCs) and 57 switched virtual circuits (SVCs) are identified by each node in a 58 Frame Relay network through a Data Link Connection Identifier (DLCI). 59 Each DLCI defines for a Frame Relay node a single virtual connection 60 through the wide area network (WAN) and is the Frame Relay equivalent 61 to a link-layer address. 63 Through specific signaling messages, a Frame Relay network may 64 announce to a node a new virtual circuit with its corresponding DLCI. 65 However, the announcement being made at link-layer level and com- 66 pletely independent of the IPv6 protocol does not include IPv6 67 addressing information. The node receiving such an announcement 68 learns about the new connection, and it is able to address the other 69 end of the virtual circuit at link layer level, but, a configuration 70 or mechanism for discovering an IPv6 address of the other end of the 71 virtual circuit is necessary. 73 The IPv6 Inverse Neighbor Discovery (IND) will allow a Frame Relay 74 node to discover dynamically an IPv6 address of a node associated 75 with a virtual circuit. These extensions can be used with other 76 links that similar to Frame Relay provide destination data link-layer 77 addresses without indicating corresponding IPv6 addresses. 79 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 80 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as 81 defined in RFC 2119. 83 There is a good number of similarities but also differences between 84 the mechanisms described here and those defined for InARP for IPv4 in 85 RFC 1293, and the updating "draft-ietf-ion-inarp-update-01.txt". 87 2. Inverse Neighbor Discovery Messages 89 The following messages are defined: 91 2.1. Inverse Neighbor Discovery Solicitation Message 93 Nodes send Inverse Neighbor Discovery Solicitations to request an 94 IPv6 address corresponding to a link-layer address of the target node 95 while also providing their own link-layer address to the target. 96 Inverse Neighbor Discovery Solicitations are link-layer unicast mes- 97 sages, but IPv6 multicasts, since the destination IPv6 address is not 98 known. 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Type | Code | Checksum | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Reserved | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Options ... 108 +-+-+-+-+-+-+-+-+-+-+-+- 110 IP Fields: 112 Source Address 113 An IPv6 address assigned to the interface from 114 which this message is sent. 116 Destination Address 117 The solicited-node multicast address. It contains 118 the 24 bit normalised value of the DLCI. 120 Hop Limit 255 122 Priority 15 124 Authentication Header 125 If a Security Association for the IP Authentication 126 Header exists between the sender and the destina- 127 tion link-layer address, then the sender SHOULD 128 include this header. 130 ICMP Fields: 132 Type 135 or [TBD] if considered as new message 134 Code 0 135 Checksum The ICMP checksum. See [ICMPv6]. 137 Reserved This field is unused. It MUST be initialized to 138 zero by the sender and MUST be ignored by the 139 receiver. 141 Required options: 143 Source link-layer address 144 The link-layer address of the sender. 146 For Frame Relay, the sender link-layer address is 147 filled in by the receiver of this message. 149 Destination link-layer address 150 The link-layer address of the receiver. 152 For Frame Relay, both the above addresses are in 153 Q.922 format (DLCI), which can have 10 (default), 154 17, or 24 significant addressing bits. The option 155 length (link-layer address) is expressed in 8 octet 156 units, therefore, the DLCI will have to be 157 extracted from the 8 bytes based on the EA field 158 (bit 0) of the second, third, or forth octet (EA = 159 1). The C/R, FECN, BECN, DE fields do not have any 160 significance for IND [IPv6FR]. 162 MTU The MTU configured for this link (circuit). 164 Future versions of this protocol may add other option types. 165 Receivers MUST silently ignore any options they do not recognize and 166 continue processing the message. 168 2.2 Inverse Neighbor Discovery Advertisement Message Format 170 A node sends Inverse Neighbor Discovery Advertisements in response to 171 Inverse Neighbor Discovery Solicitations and sends unsolicited Neigh- 172 bor Advertisements in order to (unreliably) propagate new information 173 quickly. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type | Code | Checksum | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |R|S|O| Reserved | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 + + 184 | | 185 + Target Address + 186 | | 187 + + 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Options ... 191 +-+-+-+-+-+-+-+-+-+-+-+- 193 IP Fields: 195 Source Address 196 An address assigned to the interface from which the 197 advertisement is sent. 199 Destination Address 200 For solicited advertisements, the Source Address of an 201 invoking Neighbor Solicitation. 203 For unsolicited advertisements typically the all-nodes 204 multicast address. 206 Hop Limit 255 208 Priority 15 210 Authentication Header 211 If a Security Association for the IP Authentication 212 Header exists between the sender and the destination 213 address, then the sender SHOULD include this header. 215 ICMP Fields: 217 Type 136 219 Code 0 220 Checksum The ICMP checksum. See [ICMPv6]. 222 R Router flag. When set, the R-bit indicates that the 223 sender is a router. The R-bit is used by Neighbor 224 Unreachability Detection to detect a router that 225 changes to a host. 227 S Solicited flag. When set, the S-bit indicates that 228 the advertisement was sent in response to a Neighbor 229 Solicitation from the Destination address. The S-bit 230 is used as a reachability confirmation for Neighbor 231 Unreachability Detection. It MUST NOT be set in 232 multicast advertisements or in unsolicited unicast 233 advertisements. 235 Note that a Frame Relay link is a virtual circuit, which if brakes, 236 all participants to the circuit receive appropriate link layer sig- 237 naling, which can be propagated to the upper layers, including IPv6. 238 Consequently, Neighbor Unreachability Detection is a mechanism that 239 doubles this function of the Frame Relay link, and as such it is less 240 useful than in datagram oriented links. 242 O Override flag. When set, the O-bit indicates that 243 the advertisement should override an existing cache 244 entry and update the cached link-layer to IPv6 245 address mapping. When it is not set the advertise- 246 ment will not update a cached link-layer address to 247 IPv6 address mapping though it will update an 248 existing Neighbor Cache entry for which no IPv6 249 address is known. It SHOULD NOT be set in 250 solicited advertisements for anycast addresses and 251 in solicited proxy advertisements. It SHOULD be 252 set in other solicited advertisements and in unso- 253 licited advertisements. 255 Reserved 29-bit unused field. It MUST be initialized to zero 256 by the sender and MUST be ignored by the receiver. 258 Target Address 259 For solicited advertisements, the IPv6 address 260 corresponding to the Target Link-Layer Address in 261 the Inverse Neighbor Discover Solicitation message 262 that prompted this advertisement. For an unso- 263 licited advertisement, the IPv6 address whose link- 264 layer address to IPv6 address mapping has changed. 265 The Target Address MUST NOT be a multicast address. 267 Required options: 269 Target link-layer address 270 The link-layer address of the target, i.e., the 271 sender of the advertisement [IPV6FR]. 273 Source link-layer address 274 The link-layer address of the source, i.e., the 275 receiver of the advertisement [IPv6FR]. 277 MTU The MTU configured for this link (circuit). 279 Future versions of this protocol may add other option types. 280 Receivers MUST silently ignore any options they do not recognize and 281 continue processing the message. 283 3. Inverse Neighbor Discovery Conceptual Algorithm 285 IND operates essentially the same as IPv6 ND with the exception that 286 IND uses the link-layer address of the destination node which is 287 already known, instead of a link-layer multicast. A soliciting node 288 formats an IND solicitation message as defined above, encapsulates 289 the packet for the specific link-layer and sends it directly to the 290 target node. 292 Upon receiving an IND solicitation, a Frame Relay node fills in the 293 source link-layer address field with the DLCI from the frame link- 294 layer header. This is necessary for the correct functioning of the 295 Frame Relay mechanism. Further the receiver node may put the 296 sender's IPv6 address/link-layer address mapping into its ND cache as 297 it would for a ND solicitation. However, unlike in the case of ND, 298 all IND solicitations are destined and sent to the receiving node. 300 For every IND solicitation, the receiving node may format in response 301 a proper advertisment using the link-layer source and target address 302 pair as well as the IPv6 source address from the solicitation. If a 303 node is unable or unwilling to advertise, it ignores the solicita- 304 tion. 306 Because IPv6 nodes may have multiple IPv6 addresses per interface, a 307 node responding to an IND solicitation MAY select the IPv6 address 308 which has the same prefix as the solicitor's node IPv6 address. 310 When the soliciting node receives the IND advertisment, it resolves 311 the link-layer address to IPv6 address mapping in the ND cache. 313 Note: 315 Although IND applies to circuit oriented links, like Frame Relay, for 316 which a broken physical connectivity is detected in a timely fashion 317 by the link layer, and consequently the change of state is passed to 318 upper layer protocols such as IPv6, under certain circumstances, 319 information learned via IND may be aged or invalidated, and the IPv6 320 Neighbor Unreachability Detection may be used as an additional mecha- 321 nism to refresh the link-layer to IPv6 address mapping. 323 4. Acknowledgments 325 Thanks to Thomas Narten and Eric Nordmark who spent time discussing 326 the idea of Inverse Neighbor Discovery. Also thanks to Dan Harring- 327 ton, Milan Merhar, and Martin Mueller for a thorough reviewing. 329 5. Security Considerations 331 Security issues are not addressed in this memo at this time. 333 6. References 335 [RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 Speci- 336 fication" 338 [RFC-1970] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for 339 IP Version 6 (IPv6)" 341 [RFC-1825] R. Atkinson, "Security Architecture for the Internet Pro- 342 tocol" 344 [RFC-1826] R. Atkinson, "IP Authentication Header" 346 [RFC-2200] J. Reynolds, J. Postel, "Assigned Numbers" 348 [RFC-1293] T. Bradley, C. Brown, "Inverse Address Resolution Proto- 349 col", 1/1992 350 8. Authors' Addresses 352 Alex Conta 353 Lucent Technologies Inc. 354 300 Baker Ave, Suite 100 355 Concord, MA 01742 356 +1-508-287-2842 358 email: aconta@lucent.com 359