idnits 2.17.1 draft-ietf-ipngwg-iid-02.txt: ** The Abstract section seems to be numbered 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-25) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 536: '...rget of the solicitation. It MUST NOT...' RFC 2119 keyword, line 540: '...non-zero, all other bits MUST be zero....' RFC 2119 keyword, line 549: '... MUST be the link local address...' RFC 2119 keyword, line 551: '... MUST be zero. This should be ...' RFC 2119 keyword, line 561: '... the node MUST set the Solicite...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 1996) is 10207 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) == Unused Reference: 'IPv6' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'DHCPv6' is defined on line 703, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1884 (ref. 'Addrspec') (Obsoleted by RFC 2373) -- Possible downref: Non-RFC (?) normative reference: ref. 'Discovery' -- Possible downref: Non-RFC (?) normative reference: ref. 'Addrconf' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPv6' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Elz 3 Internet Draft University of Melbourne 4 Expiration Date: November 1996 5 May 1996 7 Identifying IPv6 Interfaces in Link-Local Addresses 9 draft-ietf-ipngwg-iid-02.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 1. Abstract 31 This draft proposes a change to the way that IPv6 link local 32 addresses are constructed, so that a node can guarantee that all of 33 its link local addresses are unique within the node. The current 34 definition of a link local address, a well known prefix, some number 35 of zero bits, and a link specific unique token, ensures that it will 36 be unique on the link, which is what is required for communications 37 using those addresses over the link, but does not require uniqueness 38 of the addresses within a node. In some cases all of a nodes 39 interfaces may share the same link local address. Even the 40 possibility of this means that link local addresses, which may in 41 some situations be the only addresses that exist, cannot be used for 42 internal definition of interfaces, or other purposes within the node. 43 This draft suggests a method by which nodes may overcome this 44 problem, by redefining the bits between the prefix and the token to 45 be available to be used by the node to cause the addresses to be 46 unique. 48 2. Introduction 50 IPv6 created link local addresses, by which all interfaces could 51 always be numbered, regardless of any other addressing which may, or 52 may not, be available. These addresses are only suitable for 53 communicating within that link, and are only unique on the link. 54 [Addrconf] defines link local addresses, the various IPv6 over foo 55 specs define mechanisms for generating link local addresses such that 56 they are highly likely to be unique, and [addrconf] defines methods 57 for detecting most cases in which this procedure has failed to 58 generate unique link local addresses. 60 However, nothing, so far, has defined any method for ensuring that 61 link local addresses are unique within a node, nor for that matter, 62 for justifying that any such uniqueness is useful. This draft 63 attempts to achieve both of those purposes. 65 It is intended that this draft serve the purpose of encouraging 66 debate and discussion on this issue, and then perhaps cause some 67 modifications to published RFCs, or other drafts. It is not intended 68 that this draft ever, itself, be more widely published. Because of 69 this, several terms (eg: "addrconf") are not defined here, and 70 assumed to be understood by the reader. Examination of IPv6 RFCs and 71 drafts should provide explanations. 73 No apology is made for failing to misspell "neighbour" in this draft. 75 3. Identifying Interfaces 77 It is usual for a node with more than one interface to need, from 78 time to time, a mechanism to identify a particular interface amongst 79 the interfaces available. Currently, with IPv4, this has been done 80 on an ad hoc basis, as IPv4 addresses could not be used. Not all 81 interfaces necessarily posses an IPv4 address. 83 However, with IPv6, all (IPv6) interfaces will have a link local 84 address. This address is intended to allow communications over the 85 attached links and so is defined to be usable only on that link. 87 With a minor modification, the link local address could also serve 88 the purpose of identifying interfaces within a node for IPv6. This 89 relies upon all interfaces having a link local address, however this 90 is already specified by [addrconf]. It also relies on the link local 91 addresses being unique within the node, which is a property they do 92 not currently have. 94 If this is adopted, implementations could, if they wanted, use link 95 local addresses as their standard method for interface identification 96 for IPv6, eliminating the various methods used for IPv4, often not 97 very satisfactory. 99 Many IPv4 implementations have used the concatenation of a variable 100 length interface-type string, with a number indicating which 101 interface of that type this is (eg: "le1", or "fta0"). This has 102 multiple drawbacks, for coding it means the need to deal with a 103 different kind of label than the addresses that are used to refer to 104 interfaces on all other nodes, there is usually no stable number 105 which can be expected to remain invariant over hardware 106 reconfigurations (installing a new interface may change the number 107 assigned to one that was otherwise untouched), and there are usually 108 no tools available for mapping more user friendly (or stable) names 109 to these identifiers. 111 Without this change, using link local addresses to identify 112 interfaces is not possible, unless an implementation can guarantee, 113 by some other means, that the tokens used by all interfaces will 114 differ, always. 116 4. The method. 118 A link local address is created by taking a well known prefix 119 (FE80::/10) [addrspec] and appending a link dependent unique token in 120 the low order bits [addrconf]. The precise method, and means of 121 generating the unique token is specified in the various "IP over foo" 122 specifications for links of type "foo" [IPv6/Ether, IPv6/FDDI, ...]. 124 For the purposes of this draft, the current [addrspec] link local 125 address shall be considered to be comprised of three fields, the 126 prefix, the intermediate-zeroes, and the token. 128 This draft proposes inserting a new field between the token and the 129 prefix. That is, the intermediate-zeroes will be split into two 130 fields, which we shall call the interface identifier, and the 131 discretionary bits. 133 The interface identifier will be node defined with the sole purpose 134 of disambiguating interfaces within a node if the token required on 135 several links happens to be the same. 137 The discretionary bits can be used by the node for any purpose, and 138 are no longer required to be zero. 140 4.1. Placement Option 1 142 The new interface identifier field will be placed in towards the left 143 of the link local address. This is to guarantee that it can be in 144 the same positions for all link types, regardless of the length of 145 the token to be appended. This guarantees that if the interface 146 identifier is unique within the node for all interfaces, then the 147 generated link local addresses will also be unique within the node 148 for all interfaces, regardless of the values of the discretionary 149 bits or token. It also achieves maximal benefit for the "::" 150 notational convention by keeping as many zeroes as possible in 151 contiguous positions, though implementations are permitted to place 152 any value they desire in the discretionary bits. In this option, the 153 discretionary bits will be in lesser significant bit positions than 154 the interface identifier. 156 It is suggested that the low order 16 bits of the high order 32 bits 157 of the link local address be allocated to interface identifier. This 158 allows another 6 bits between the current defined prefix, and the new 159 field, which will be reserved for future use, potentially to define a 160 different format for link local addresses at some future date. Using 161 high order bits also has ramifications (or more precisely non- 162 ramifications) with respect to multicast address selection for 163 neighbour discovery, which will be expanded upon below. The various 164 "IPv6 over foo" specifications will be altered to show this field. 166 4.2. Placement Option 2 168 The new interface identifier field will be placed in towards the 169 right of the link local address. This places it just next to the 170 token, which is assumed to have a defined maximum length. The 171 interface identifier field will be at a fixed bit position regardless 172 of token length, to the left of the longest possible token. This 173 guarantees that if the interface identifier is unique within the node 174 for all interfaces, then the generated link local addresses will also 175 be unique within the node for all interfaces, regardless of the 176 values of the discretionary bits or token. It also achieves maximal 177 benefit for the "::" notational convention by keeping as many zeroes 178 as possible in contiguous positions, though implementations are 179 permitted to place any value they desire in the discretionary bits. 180 In this option, the discretionary bits will be in more significant 181 bit positions than the interface identifier. 183 It is suggested that the high order 16 bits of the low order 64 bits 184 of the link local address be allocated to interface identifier. This 185 assumes that the longest permitted token is 48 bits. These bits are 186 beyond the range of bits used for multicast address selection for 187 neighbour discovery, which will be expanded upon below. The various 188 "IPv6 over foo" specifications will be altered to show this field. 190 4.3. The New Fields 192 The "addrconf" specification will define the contents of the 193 interface identifier field. This will specify that a node may insert 194 any value in this field that it desires, but that it is intended that 195 the field be used to cause all link local addresses assigned to the 196 node to be unique. It will be recommended that nodes use the field 197 to hold some interface hardware-specific value (or software-specific, 198 for virtual interfaces) which is likely to remain constant over time, 199 even if similar interfaces are added or removed. Thus, this field 200 alone will be unique amongst all interfaces to the node, and so is 201 sufficient to identify interfaces, regardless of whether or not the 202 token varies from one interface to another. 204 The discretionary bits may be used by the implementation for any 205 purpose. 207 5. Duplicate address detection 209 [Addrconf] specifies that any address generated by a node must be 210 tested for uniqueness by being tested by the Duplicate Address 211 Detection (DAD) algorithm. 213 For link local addresses as originally defined, this amounts to a 214 test for uniqueness of the link specific token on the link, as all 215 other bits in the address are the same for all nodes. 217 [Addrconf] uses this feature to permit DAD to be avoided for 218 additional addresses created from the same token on the same link, 219 when created in a standard manner - such as that specified for 220 stateless autoconfiguration in [addrconf]. Such addresses are formed 221 the same way in all nodes on the link, with the token inserted - 222 known uniqueness of the token guarantees uniqueness within the same 223 scope of the other generated address. Uniqueness in wider scopes is 224 derived from the known properties of the prefix to which the token is 225 appended. 227 As modified here, performing DAD on the link local address does not 228 any longer amount to any uniqueness guarantee of the token, as two 229 link local addresses (from different nodes) may have the same token, 230 yet differ in interface identifier, or discretionary bits. 232 To avoid the extra burden of testing all autonomously configured 233 addresses, this drafts specifies than when testing a link local 234 address for uniqueness using DAD, the address tested shall be formed 235 with the interface identifier and discretionary bits, that is, the 236 intermediate-zeroes, set to zero. This is the same address that was 237 previously tested. 239 Whenever a node that implements this modification receives a 240 Neighbour Solicitation packet containing a target address with prefix 241 FE80::/10 it should consider only those 10 bits, and the final token 242 bits, for which the size will be determined by the nature of the link 243 over which the NS is received, when comparing the target address 244 requested, and its own link local address for the link, all other 245 bits of both the target address sought, and the local link local 246 address should be considered to be zero. 248 Nodes that have been implemented according to previous versions of 249 [Addrconf] and [Discovery], or which simply do not wish to make use 250 of the interface identifier or discretionary bits, will have zeroes 251 in all the intermediate-zeroes bits of their own link local 252 addresses. When processing a ND packet sent for DAD purposes, simple 253 comparison of the addresses will work, as that ND packet will also 254 contain zeros in the intermediate-zeroes bits. Other ND packets may 255 contain other values in those bits, but this node will only be 256 concerned with those containing its own link local address, and that 257 will be as this node defined it. 259 The Neighbour Advertisement returned in response to receiving a 260 Neighbour Solicitation containing a target address with prefix 261 FE80::/10, and sent from the unspecified address, that is, a DAD 262 packet, should contain the responding node's link local address, 263 modified to contain only zeroes in the intermediate-zeroes bits. A 264 node that has not been modified to implement this specification will 265 do this naturally, as the intermediate-zeroes bits in its link local 266 address will all be zero anyway. Nodes implementing these 267 modifications must check received NS packets for their source address 268 being unspecified, which they must do anyway to reply correctly, and 269 if so, and if a reply is to be sent, ensure that the intermediate- 270 zeroes bits are cleared from the link local address. 272 When receiving Neighbour Advertisement packets during the DAD 273 process, and the target address therein has a prefix of FE80::/10, a 274 node implementing this specification must consider only the prefix, 275 and token when comparing the returned target address and the 276 tentative link local address for the node. The intermediate-zeroes 277 bits must, for this purpose, and only this purpose, be treated as if 278 they were set to zero the tentative link local address. Those bits 279 will always be zero in the NA reply received. 281 This procedure then returns DAD of the link local address to being a 282 uniqueness test of the token on the link, which then allows the token 283 to be used to generate other unique addresses without testing those - 284 including the link local address as defined here. 286 Note that as defined here, an implementation that chooses not to make 287 use of the interface identifier or discretionary bits fields, and 288 always uses them as intermediate-zeroes as currently defined, need 289 not alter its implementation from that pertaining to the previous 290 definition of link local addresses. Received NS packets for DAD will 291 contain zeroes in all relevant bits, and thus will appear as if this 292 specification did not exist. The returned NA from the node will 293 contain the interface link local address, just as now, which will be 294 the address with the intermediate-zeroes field. Ordinary NS and NA 295 packets directed to and from the node, will contain the node's link 296 local address, as always, whatever bits it contains, as would any 297 other packets to or from the node using its link local address. 298 Nodes must thus never assume that link local addresses will always 299 contain zeroes in the intermediate-zeroes bits. Nodes should not 300 ever be tempted to make assumptions about the values of any addresses 301 of any other nodes. 303 [Addrconf] and [Discovery] will be updated, as specified below, to 304 include these procedures. 306 6. Multicast Address Generation 308 [Discovery] specifies the algorithm by which the solicited-node 309 multicast address is generated. That uses only the low bits of the 310 IPv6 address. By positioning the interface identifier in the upper 311 bits of the link local address, the same solicited-node multicast 312 address will be generated, whatever interface identifier is chosen. 313 On some media, the token might be less than 32 bits wide. In such 314 cases the node may choose to use some of the bits used for multicast 315 address generation for other purposes. This draft strongly 316 recommends against this practice, but does not prohibit it. However, 317 nodes must be prepared to receive Neighbour Solicitation packets sent 318 to either the node's link local address, or to the address formed 319 from the prefix FE80::/16 and the interface token, with zeroes 320 between (in the intermediate-zeroes field). This may mean accepting 321 two different multicast addresses where one would ordinarily be 322 sufficient. 324 7. Rationale 326 By guaranteeing that all interfaces have unique addresses within the 327 node, the node can use those unique addresses to identify the 328 interface, rather than having to invent some new name space for this 329 purpose. Using addresses also allows all the standard tools to be 330 used for interface identification, that are used for host 331 identification. Interfaces can be named by Domain Name System names, 332 which can be manipulated in the same way as other DNS names, and 333 translated by standard routines into the addresses used as interface 334 identifiers. 336 Because a link local address must exist for all interfaces [addrconf] 337 and must always be generated in a standard way, the address is 338 effectively available for internal uses instantly the interface is 339 made known to the rest of the system - even before DAD is performed. 340 This means that no other interface identification is required, the 341 unique link local address can be, if the implementation desires, the 342 only interface identification provided. If DAD fails, [addrconf] 343 specifies that the interface be shut down. Even then the link local 344 address will still be unique within the node, and can still be used 345 to refer to the inactive interface. 347 With all interfaces identified by unique intra-node addresses, 348 implementations can, if they desire, make use of address fields in 349 the regular API for interface identification. For example, an 350 application might make use of source routing via a local interface in 351 order to direct packets to be transmitted over a specific link - 352 which would not imply that a routing header would be present in the 353 packet transmitted if the local address was all it contained, or that 354 that address would ever be present in a transmitted routing header. 355 Directing packets through specific interfaces, especially if 356 unnumbered, has not been easy, or even possible, in many current IP 357 implementations. 359 Implementations with multiple tokens available to create link local 360 addresses have the opportunity to connect multiple interfaces to one 361 link if that will produce a useful configuration - perhaps to achieve 362 higher bandwidth through a switch that permits multiple parallel 363 conversations. An implementation with only a single token would need 364 to invent a token, which is certainly not to be recommended, survive 365 with a shared link local address, or modify some other part of the 366 link local address, presumably using the technique described here. 367 With unique link local addresses, stateful autoconfiguration could be 368 used to obtain other addressing, where stateless autoconfiguration 369 would generate the same addresses for all such interfaces. Without 370 that, there would be no unique token for DHCP to use to assign 371 different addresses, 372 Where the node concerned is participating in routing protocols, such 373 as OSPF for IPv6, it also seems that having multiple interfaces on 374 one link sharing the same link local address might be a problem. 375 (Precise details unavailable...) 377 8. Specific Document Changes Suggested 379 In order to implement this change, the documents listed in this 380 section must be modified as indicated, or in such a way as to lead to 381 the same effect. Some of the documents concerned are, at the date of 382 this memo, available only as Internet Drafts. Because the changes 383 below relate to a specific version of each document, the normal 384 practice of never referencing an Internet Draft other than as "work 385 in progress" will be suspended here, and specific drafts will be 386 referenced. 388 Note that in these changes, the reference annotations have been 389 changed so as to be compatible with those used in this document, 390 rather than those used in the original. This is for clarity here 391 only, clearly the references in each case should be in the format 392 required by the specific document. 394 8.1. Changes to RFC1884 396 In section 2.4.8, on page 11, the diagram showing the format of a 397 link local address must be changed to either: 399 | 10 | 16 400 | bits | 6 | bits| 96-n bits | n bits | 401 +----------+---+-----+---------------+----------------------------+ 402 |1111111010| 0 | IID | discretionary | interface ID | 403 +----------+---+-----+---------------+----------------------------+ 405 or: 407 | 10 | 16 408 | bits | 54 bits | bits| 48 bits | 409 +----------+-------------------+-----+----------------------------+ 410 |1111111010| discretionary | IID | interface ID | 411 +----------+-------------------+-----+----------------------------+ 413 Which is chosen will depend upon which placement of the interface 414 identifier (IID) is decided to be better. See section 4. 416 No other changes are required. 418 8.2. Changes to draft-ietf-addrconf-ipv6-auto-07.txt 420 8.2.1. Changes to Terminology 422 In section 2, somewhere on pages 5 to 8, the following definitions 423 should be added: 425 interface identifier 426 - An integer identifier for each interface attached to a 427 node that is unique within the node, and relatively 428 stable. That is, the identifier should not normally 429 change across resets of the IPv6 layer, nor reboots of 430 the node, and should generally be unchanged by the 431 addition of deletion of other interfaces. 433 discretionary bits 434 - A value that the implementation or node can set to any 435 value for any purpose when defining the enclosing 436 structure or value. Once set, the bits must not be 437 altered as long as the particular structure remains 438 defined, or the value required. 440 8.2.2. Changes to link local address formation 442 In section 5.3, in the paragraph beginning "A link-local address is 443 formed ..." on page 15, will be replaced by the following paragraphs. 445 A link local address is formed from five component parts. The 446 most significant bits are always the well known prefix FE80::/10 447 [Addrspec]. The least significant bits are the interface token, 448 chosen in an interface specific way. Between those are placed 449 fields containing zeroes (padding), an interface identifier 450 field, and a field containing any value that the implementation 451 desires to place there. 453 The interface identifier field is a 16 bit field that can 454 contain either zeroes, or a value chosed by the implementation 455 that is unique among all interfaces connected to the node. Such 456 a value should be chosen in a way that long term stability of 457 the value chosen is likely. That is, neither a random number, 458 nor a simple count of interfaces as they are configured is 459 appropriate. Suitable choices would relate to the particular 460 hardware configuration, such as the slot number used on the bus, 461 or the address in I/O space of the interface adaptor, or 462 similar. It is highly desirable that the interface identifier 463 not alter merely because some other interface is added or 464 removed. 466 Following those paragraphs, one of the following paragraphs will be 467 added, depending on which choice is made for the positioning of the 468 interface identifier field. 470 Either: 472 The fields of the link local address will be formed in the 473 order, from most to least significant bits, the well known 474 prefix (FE80::/10) first, then a six bit zero field, then the 16 475 bit interface identifier field, then an M bit discretionary 476 field, followed by an N bit interface token. M shall be 96 - N. 477 If the interface token is more than 96 bits in length, 478 autoconfiguration fails, and manual configuration is required. 480 Or: 482 The fields of the link local address will be formed in the 483 order, from most to least significant bits, the well known 484 prefix (FE80::/10) first, then 54 discretionary bits, then the 485 16 bit interface identifier field, followed by an optional 486 variable width field of zeroes, followed by an N bit interface 487 token. If the interface token is less than 48 bits, the zero 488 filled field is included, and is 48 - N bits wide. If the 489 interface token is exactly 48 bits, no field of zeroes is 490 included. If the interface token is more than 48 bits in 491 length, autoconfiguration fails, and manual configuration is 492 required. 494 8.2.3. Changes to Duplicate Address Detection 496 In section 5.4.2, on page 16, the paragraph which begins "To check an 497 address, a node sends ..." shall be replaced by: 499 To check an address, a node sends DupAddrDetectTransmits 500 Neighbor Solicitations, each separated by RetransTimer 501 milliseconds. If the tentative address is not a link local 502 address, the solicitation's Target Address is set to the address 503 being checked. If the tentative address is a link local 504 address, the solicitation's Target Address is set to the address 505 being checked, modified such that only the prefix and interface 506 token fields are non-zero, all other bits of the link local 507 tentative address must be zero. The IP source is set to the 508 unspecified address and the IP destination is set to the 509 solicited-node multicast address of the Target Address. 511 In section 5.4.3, on page 17, the following paragraph should precede 512 the paragraphs that currently exist: 514 While performing Duplicate Address Detection for a link local 515 address, the node must consider a received Neighbor Solicitation 516 message sent with a Target Address that is also a link local 517 address, and which has the same interface token value as the 518 node's tentative link local address, to be a Neighbor 519 Solicitation sent to that tentative link local address. 521 In section 5.4.4 on page 18, the following paragraph should precede 522 the paragraph that currently exists: 524 While performing Duplicate Address Detection for a link local 525 address, the node must consider a received Neighbor 526 Advertisement message sent with a Target Address that is also a 527 link local address, and which has the same interface token value 528 as the node's tentative link local address, to be a Neighbor 529 Advertisement sent to that tentative link local address. 531 8.3. Changes to draft-ietf-ipngwg-discovery-06.txt 533 In section 4.3, on page 24, the Target Address field of the Neighbour 534 Solicitation packet is changed to be: 536 The IP address of the target of the solicitation. It MUST NOT 537 be a multicast address. If Duplicate Addres Detection is in 538 progress [Addrconf] and the address being tested ia a link local 539 address, then only the prefix (FE80::/10) and the interface 540 token are non-zero, all other bits MUST be zero. 542 In section 4.4, on page 26, the paragraph describing the Target 543 Address field of a Neighbour Advertisment shall be augmented as 544 follows. 546 Note that when responding to a Neighbour Solicitation sent from 547 the unspecified address (Source Address of the Neighbour 548 Solicitation) seeking a link local address, the Target Address 549 MUST be the link local address modified by including only the 550 prefix (FE80::/10) and interface token fields. All other bits 551 MUST be zero. This should be equivalent to the address in the 552 Target Address field of the Neighbour Solicitation packet, but 553 need not be identical to the node's link local address on the 554 interface. 556 In section 7.2.4, on page 61, the paragraph that begins "If the 557 source of the solicitation is the unspecified address, ..." will be 558 altered to be: 560 If the source of the solicitation is the unspecified address, 561 the node MUST set the Solicited flag to zero and multicast the 562 advertisement to the all-nodes address. Further, if the Target 563 Address is a link local address, then only the prefix and 564 interface token fields may have non-zero values, all other bits 565 of the Target Address MUST be zero. Otherwise, the node MUST 566 set the Solicited flag to one and unicast the advertisement to 567 the Source Address of the solicitation. 569 8.4. Changes to draft-ietf-ipngwg-ethernet-ntwrks-02.txt 571 On page 2, in the section entitled "Stateless Autoconfiguration and 572 Link-Local Addresses", the paragraph which begins: "The IPv6 Link- 573 local address ..." will be changed to be: 575 The IPv6 Link-local address [Addrspec] for an Ethernet interface 576 is formed by appending the interface's IEEE 802 address to the 577 80-bit prefix created by appending the interface's host specific 578 interface identifier [Addrconf] and other host or implementation 579 defined bits to the well known ten bit prefix FE80::/10. 581 The diagram that immediately follows will be replaced by either: 583 +-------+-------+-------+-------+-------+-------+------+------+ 584 | FE 80 | IID | <--- discretionary value -- | 585 +-------+-------+-------+-------+-------+-------+------+------+ 586 | --- ---> | Ethernet Address | 587 +-------+-------+-------+-------+-------+-------+------+------+ 589 or: 591 +-------+-------+-------+-------+-------+-------+------+------+ 592 | FE 80 <--- discretionary value --- --- --- ---> | 593 +-------+-------+-------+-------+-------+-------+------+------+ 594 | IID | Ethernet Address | 595 +-------+-------+-------+-------+-------+-------+------+------+ 597 Which is chosen will depend upon which placement of the interface 598 identifier (IID) is decided to be better. 600 8.5. Changes to draft-ietf-ipngwg-fddi-ntwrks-03.txt 602 On page 4, in the section entitled "Stateless Autoconfiguration and 603 Link-Local Addresses", the paragraph which begins: "The IPv6 Link- 604 local address ..." will be changed to be: 606 The IPv6 Link-local address [Addrspec] for an FDDI interface is 607 formed by appending the interface's IEEE 802 address to the 80- 608 bit prefix created by appending the interface's host specific 609 interface identifier [Addrconf] and other host or implementation 610 defined bits to the well known ten bit prefix FE80::/10. 612 The diagram that immediately follows will be replaced by either: 614 +-------+-------+-------+-------+-------+-------+------+------+ 615 | FE 80 | IID | <--- discretionary value -- | 616 +-------+-------+-------+-------+-------+-------+------+------+ 617 | --- ---> | FDDI Address | 618 +-------+-------+-------+-------+-------+-------+------+------+ 620 or: 622 +-------+-------+-------+-------+-------+-------+------+------+ 623 | FE 80 <--- discretionary value --- --- --- ---> | 624 +-------+-------+-------+-------+-------+-------+------+------+ 625 | IID | FDDI Address | 626 +-------+-------+-------+-------+-------+-------+------+------+ 628 Which is chosen will depend upon which placement of the interface 629 identifier (IID) is decided to be better. 631 8.6. Changes to draft-ietf-ipngwg-pppext-ipv6cp-02.txt 633 In section 5, the paragraph which begins "The most significant 10 634 bits of the address" on page 10 will be replaced by either: 636 The most significant 10 bits of the address is the Link-Local 637 prefix FE80::. This is followed by six more bits of zero, then 638 the 16 interface identifier bits, then 64 discretionary bits, 639 followed by the Interface Token field. 640 or: 641 The most significant 10 bits of the address is the Link-Local 642 prefix FE80::. This is followed by 54 discretionary bits, then 643 the 16 interface identifier bits, then 16 bits of zero, followed 644 by the Interface Token field. 646 The choice of replacement text will depend upon which placement of 647 the interface identifier field is considered best. The immediately 648 preceding diagram in the draft will be replaced by either: 650 | 10 bits | 6 | 16 | 64 bits | 32 bits | 651 +----------+---+-----+--------------------------+-----------------+ 652 |1111111010| 0 | IID | discretionary | Interface Token | 653 +----------+---+-----+--------------------------+-----------------+ 655 or: 657 | 10 bits | 54 bits | 16 | 16 | 32 bits | 658 +----------+------------------------------------+-----------------+ 659 |1111111010| discretionary | IID | 0 | Interface Token | 660 +----------+------------------------------------+-----------------+ 662 Which is chosen will depend upon which placement of the interface 663 identifier (IID) is decided to be better. Note that in the second 664 option, the token field remains 48 bits wide though the PPP token is 665 defined as only being 32 bits. The remaining 16 bits are zero 666 padded. This ensures that the interface identifier field will remain 667 in the same bit positions in all link local addresses. 669 8.7. Changes to other link specific documents 671 Other documents specifying IPv6 implementation details on other link 672 types will be changed in ways similar to those indicated above. 674 9. Security Considerations 676 Addressing and security are unrelated concepts. Attempts to pretend 677 otherwise are misguided. 679 10. References 681 [IPv6] "Internet Protocol, Version 6 (IPv6) Specification", 682 S. Deering, R. Hinden, RFC1883, January 4, 1996. 684 [Addrspec] "IP Version 6 Addressing Architecture", 685 R. Hinden, S. Deering, RFC1884, January 4, 1996. 687 [IPv6/Ether] "A Method for the Transmission of IPv6 Packets over 688 Ethernet Networks" 689 Matt Crawford, Work In Progress (soon to be an RFC). 691 [IPv6/FDDI] "A Method for the Transmission of IPv6 Packets over 692 FDDI Networks" 693 Matt Crawford, Work In Progress (soon to be an RFC). 695 [Discovery] "Neighbor Discovery for IP Version 6 (IPv6)" 696 Thomas Narten, Erik Nordmark, W A Simpson, 697 Work In Progress (soon to be an RFC). 699 [Addrconf] "IPv6 Stateless Address Autoconfiguration" 700 Susan Thomson, Thomas Narten, 701 Work In Progress (soon to be an RFC). 703 [DHCPv6] "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 704 J. Bound, C. Perkins, 705 Work In Progress (soon to be an RFC). 707 11. Acknowledgements 709 My thanks to Matt Crawford for assisting getting this draft into a 710 semi-presentable state, which is not to imply that he agrees with the 711 proposal. Also to Dennis Ferguson for pointing out additional 712 justification for use of a method like this. The IPNGWG working 713 group also devoted some valuable meeting time to discussion of this 714 issue, all who contributed there also contributed here. 716 12. Author's Address 718 Robert Elz 719 University of Melbourne 720 Parkville 721 Victoria 2052 722 Australia 724 EMail: kre@munnari.OZ.AU