idnits 2.17.1 draft-ietf-ipngwg-ipv6-over-ppp-05.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-03-28) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** There are 162 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 268 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...ocument is a...' == Line 15 has weird spacing: '...cuments of t...' == Line 16 has weird spacing: '...t other group...' == Line 21 has weird spacing: '...iate to use ...' == Line 22 has weird spacing: '... as refer...' == (157 more instances...) -- 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 (February 1998) is 9538 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) -- No information found for draft-ietf-ipngwg-addrconfv2 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 1700 (ref. '4') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-addr-arch-v2-02 ** Downref: Normative reference to an Informational draft: draft-narten-canonical-ordering (ref. '8') Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft IP Version 6 over PPP February 1998 4 Internet Engineering Task Force 5 INTERNET-DRAFT Dimitry Haskin 6 Expires August 1998 Ed Allen 7 Bay Networks, Inc. 8 February 1998 10 IP Version 6 over PPP 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months. 20 Internet-Drafts may be updated, replaced, or obsoleted by other 21 documents at any time. It is not appropriate to use Internet-Drafts 22 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 Shadow 27 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 Abstract 33 The Point-to-Point Protocol (PPP) [1] provides a standard method of 34 encapsulating Network Layer protocol information over point-to-point 35 links. PPP also defines an extensible Link Control Protocol, and 36 proposes a family of Network Control Protocols (NCPs) for establishing 37 and configuring different network-layer protocols. 39 This document defines the method for transmission of IP Version 6 [2] 40 packets over PPP links as well as the Network Control Protocol (NCP) 41 for establishing and configuring the IPv6 over PPP. It also specifies 42 the method of forming IPv6 link-local addresses on PPP links. 44 Table of Contents 46 1. Introduction .......................................... 3 47 1.1. Specification of Requirements ...................... 3 48 2. Sending IPv6 Datagrams ................................ 3 49 3. A PPP Network Control Protocol for IPv6 ............... 4 50 4. IPV6CP Configuration Options .......................... 5 51 4.1. Interface-Identifier .............................. 5 52 5. Stateless Autoconfiguration and Link-Local Addresses .. 11 53 6 Security Considerations ............................... 12 54 7 Acknowledgments ....................................... 12 55 8 Changes from RFC-2023 ................................. 12 56 9 References ............................................ 13 57 10 Authors' Addresses .................................... 13 59 1. Introduction 61 PPP has three main components: 63 1. A method for encapsulating datagrams over serial links. 65 2. A Link Control Protocol (LCP) for establishing, configuring, and 66 testing the data-link connection. 68 3. A family of Network Control Protocols (NCPs) for establishing and 69 configuring different network-layer protocols. 71 In order to establish communications over a point-to-point link, each 72 end of the PPP link must first send LCP packets to configure and test 73 the data link. After the link has been established and optional 74 facilities have been negotiated as needed by the LCP, PPP must send 75 NCP packets to choose and configure one or more network-layer 76 protocols. Once each of the chosen network-layer protocols has been 77 configured, datagrams from each network-layer protocol can be sent 78 over the link. 80 In this document, the NCP for establishing and configuring the IPv6 81 over PPP is referred as the IPv6 Control Protocol (IPV6CP). 83 The link will remain configured for communications until explicit LCP 84 or NCP packets close the link down, or until some external event 85 occurs (power failure at the other end, carrier drop, etc.). 87 1.1. Specification of Requirements 89 In this document, several words are used to signify the requirements 90 of the specification. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [7]. 96 2. Sending IPv6 Datagrams 98 Before any IPv6 packets may be communicated, PPP MUST reach the 99 Network-Layer Protocol phase, and the IPv6 Control Protocol MUST reach 100 the Opened state. 102 Exactly one IPv6 packet is encapsulated in the Information field of 103 PPP Data Link Layer frames where the Protocol field indicates type hex 104 0057 (Internet Protocol Version 6). 106 The maximum length of an IPv6 packet transmitted over a PPP link is 107 the same as the maximum length of the Information field of a PPP data 108 link layer frame. PPP links supporting IPv6 MUST allow the 109 information field at least as large as the minimum link MTU size 110 required for IPv6 [2]. 112 3. A PPP Network Control Protocol for IPv6 114 The IPv6 Control Protocol (IPV6CP) is responsible for configuring, 115 enabling, and disabling the IPv6 protocol modules on both ends of the 116 point-to-point link. IPV6CP uses the same packet exchange mechanism 117 as the Link Control Protocol (LCP). IPV6CP packets may not be 118 exchanged until PPP has reached the Network-Layer Protocol phase. 119 IPV6CP packets received before this phase is reached should be 120 silently discarded. 122 The IPv6 Control Protocol is exactly the same as the Link Control 123 Protocol [1] with the following exceptions: 125 Data Link Layer Protocol Field 127 Exactly one IPV6CP packet is encapsulated in the Information 128 field of PPP Data Link Layer frames where the Protocol field 129 indicates type hex 8057 (IPv6 Control Protocol). 131 Code field 133 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 134 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 135 Ack and Code-Reject) are used. Other Codes should be treated 136 as unrecognized and should result in Code-Rejects. 138 Timeouts 140 IPV6CP packets may not be exchanged until PPP has reached the 141 Network-Layer Protocol phase. An implementation should be 142 prepared to wait for Authentication and Link Quality 143 Determination to finish before timing out waiting for a 144 Configure-Ack or other response. It is suggested that an 145 implementation give up only after user intervention or a 146 configurable amount of time. 148 Configuration Option Types 150 IPV6CP has a distinct set of Configuration Options. 152 4. IPV6CP Configuration Options 154 IPV6CP Configuration Options allow negotiation of desirable IPv6 155 parameters. IPV6CP uses the same Configuration Option format defined 156 for LCP [1], with a separate set of Options. If a Configuration 157 Option is not included in a Configure-Request packet, the default 158 value for that Configuration Option is assumed. 160 Up-to-date values of the IPV6CP Option Type field are specified in the 161 most recent "Assigned Numbers" RFC [4]. 163 The only IPV6CP option defined in this document is the Interface- 164 Identifier option (Option Type 1). Any other IPV6CP configuration 165 options that can be defined over time are to be defined in separate 166 documents. 168 4.1. Interface-Identifier 170 Description 172 This Configuration Option provides a way to negotiate a unique 64- 173 bit interface identifier to be used for the address 174 autoconfiguration [3] at the local end of the link (see section 5). 175 A Configure-Request MUST contain exactly one instance of the 176 Interface-Identifier option [1]. The interface identifier MUST be 177 unique within the PPP link; i.e. upon completion of the negotiation 178 different Interface-Identifier values are to be selected for the 179 ends of the PPP link. The interface identifier MAY also be unique 180 over a broader scope. 182 Before this Configuration Option is requested, an implementation 183 chooses its tentative Interface-Identifier. The non-zero value of 184 the tentative Interface-Identifier SHOULD be chosen such that the 185 value is both unique to the link and, if possible, consistently 186 reproducible across initializations of the IPV6CP finite state 187 machine (administrative Close and reOpen, reboots, etc). The 188 rationale for preferring a consistently reproducible unique 189 interface identifier to a completely random interface identifier is 190 to provide stability to global scope addresses that can be formed 191 from the interface identifier. 193 Assuming that interface identifier bits are numbered from 0 to 63 in 194 canonical bit order where the most significant bit is the bit number 195 0, the bit number 6 is the "u" bit (universal/local bit in IEEE 196 EUI-64 [5] terminology) which indicates whether or not the interface 197 identifier is based on a globally unique IEEE identifier (EUI-48 or 198 EUI-64 [5]) (see the case 1 below). It is set to one (1) if a 199 globally unique IEEE identifier is used to derive the interface 200 identifier, and it is set to zero (0) otherwise. 202 The following are methods for choosing the tentative Interface 203 Identifier in the preference order: 205 1) If an IEEE global identifier (EUI-48 or EUI-64) is available 206 anywhere on the node, it should be used to construct the 207 tentative Interface-Identifier due to its uniqueness properties. 208 When extracting an IEEE global identifier from another device on 209 the node, care should be taken to that the extracted identifier 210 is presented in canonical ordering [8]. 212 The only transformation from an EUI-64 identifier is to invert 213 the "u" bit (universal/local bit in IEEE EUI-64 terminology). 214 For example, for a globally unique EUI-64 identifier of the form: 216 most-significant least-significant 217 bit bit 218 |0 1|1 3|3 4|4 6| 219 |0 5|6 1|2 7|8 3| 220 +----------------+----------------+----------------+----------------+ 221 |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| 222 +----------------+----------------+----------------+----------------+ 224 where "c" are the bits of the assigned company_id, "0" is the 225 value of the universal/local bit to indicate global scope, "g" is 226 group/individual bit, and "e" are the bits of the extension 227 identifier, the IPv6 interface identifier would be of the form: 229 most-significant least-significant 230 bit bit 231 |0 1|1 3|3 4|4 6| 232 |0 5|6 1|2 7|8 3| 233 +----------------+----------------+----------------+----------------+ 234 |cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| 235 +----------------+----------------+----------------+----------------+ 237 The only change is inverting the value of the universal/local 238 bit. 240 In the case of a EUI-48 identifier, it is first converted to the 241 EUI-64 format by inserting two bytes, with hexadecimal values of 242 0xFF and 0xFE, in the middle of the 48 bit MAC (between the 243 company_id and extension-identifier portions of the EUI-48 244 value). For example, for a globally unique 48 bit EUI-48 245 identifier of the form: 247 most-significant least-significant 248 bit bit 249 |0 1|1 3|3 4| 250 |0 5|6 1|2 7| 251 +----------------+----------------+----------------+ 252 |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee| 253 +----------------+----------------+----------------+ 255 where "c" are the bits of the assigned company_id, "0" is the 256 value of the universal/local bit to indicate global scope, "g" is 257 group/individual bit, and "e" are the bits of the extension 258 identifier, the IPv6 interface identifier would be of the form: 260 most-significant least-significant 261 bit bit 262 |0 1|1 3|3 4|4 6| 263 |0 5|6 1|2 7|8 3| 264 +----------------+----------------+----------------+----------------+ 265 |cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee| 266 +----------------+----------------+----------------+----------------+ 268 2) If an IEEE global identifier is not available a different source 269 of uniqueness should be used. Suggested sources of uniqueness 270 include link-layer addresses, machine serial numbers, et cetera. 272 In this case the "u" bit of the interface identifier MUST be set 273 to zero (0). 275 3) If a good source of uniqueness cannot be found, it is recommended 276 that a random number be generated. In this case the "u" bit of 277 the interface identifier MUST be set to zero (0). 279 Good sources [1] of uniqueness or randomness are required for the 280 Interface-Identifier negotiation to succeed. If neither a unique 281 number or a random number can be generated it is recommended that a 282 zero value be used for the Interface-Identifier transmitted in the 283 Configure-Request. In this case the PPP peer may provide a valid 284 non-zero Interface-Identifier in its response as described below. 285 Note that if at least one of the PPP peers is able to generate 286 separate non-zero numbers for itself and its peer, the identifier 287 negotiation will succeed. 289 When a Configure-Request is received with the Interface-Identifier 290 Configuration Option and the receiving peer implements this option, 291 the received Interface-Identifier is compared with the Interface- 292 Identifier of the last Configure-Request sent to the peer. 293 Depending on the result of the comparison an implementation MUST 294 respond in one of the following ways: 296 If the two Interface-Identifiers are different but the received 297 Interface-Identifier is zero, a Configure-Nak is sent with a non- 298 zero Interface-Identifier value suggested for use by the remote 299 peer. Such a suggested Interface-Identifier MUST be different from 300 the Interface-Identifier of the last Configure-Request sent to the 301 peer. It is recommended that the value suggested be consistently 302 reproducible across initializations of the IPV6CP finite state 303 machine (administrative Close and reOpen, reboots, etc). The "u" 304 universal/local) bit of the suggested identifier MUST be set to zero 305 (0) regardless of its source unless the globally unique EUI-48/EUI- 306 64 derived identifier is provided for the exclusive use by the 307 remote peer. 309 If the two Interface-Identifiers are different and the received 310 Interface-Identifier is not zero, the Interface-Identifier MUST be 311 acknowledged, i.e. a Configure-Ack is sent with the requested 312 Interface-Identifier, meaning that the responding peer agrees with 313 the Interface-Identifier requested. 315 If the two Interface-Identifiers are equal and are not zero, a 316 Configure-Nak MUST be sent specifying a different non-zero 317 Interface-Identifier value suggested for use by the remote peer. It 318 is recommended that the value suggested be consistently reproducible 319 across initializations of the IPV6CP finite state machine 320 (administrative Close and reOpen, reboots, etc). The "u" 321 universal/local) bit of the suggested identifier MUST be set to zero 322 (0) regardless of its source unless the globally unique EUI-48/EUI- 323 64 derived identifier is provided for the exclusive use by the 324 remote peer. 326 If the two Interface-Identifiers are equal to zero, the Interface- 327 Identifiers negotiation MUST be terminated by transmitting the 328 Configure-Reject with the Interface-Identifier value set to zero. In 329 this case a unique Interface-Identifier can not be negotiated. 331 If a Configure-Request is received with the Interface-Identifier 332 Configuration Option and the receiving peer does not implement this 333 option, Configure-Rej is sent. 335 A new Configure-Request SHOULD NOT be sent to the peer until normal 336 processing would cause it to be sent (that is, until a Configure-Nak 337 is received or the Restart timer runs out). 339 A new Configure-Request MUST NOT contain the Interface-Identifier 340 option if a valid Interface-Identifier Configure-Reject is received. 342 Reception of a Configure-Nak with a suggested Interface-Identifier 343 different from that of the last Configure-Nak sent to the peer 344 indicates a unique Interface-Identifier. In this case a new 345 Configure-Request MUST be sent with the identifier value suggested 346 in the last Configure-Nak from the peer. But if the received 347 Interface-Identifier is equal to the one sent in the last Configure- 348 Nak, a new Interface-Identifier MUST be chosen. In this case, a new 349 Configure-Request SHOULD be sent with the new tentative Interface- 350 Identifier. This sequence (transmit Configure-Request, receive 351 Configure-Request, transmit Configure-Nak, receive Configure-Nak) 352 might occur a few times, but it is extremely unlikely to occur 353 repeatedly. More likely, the Interface-Identifiers chosen at either 354 end will quickly diverge, terminating the sequence. 356 If negotiation of the Interface-Identifier is required, and the peer 357 did not provide the option in its Configure-Request, the option 358 SHOULD be appended to a Configure-Nak. The tentative value of the 359 Interface-Identifier given must be acceptable as the remote 360 Interface- Identifier; i.e. it should be different from the 361 identifier value selected for the local end of the PPP link. The 362 next Configure-Request from the peer may include this option. If 363 the next Configure-Request does not include this option the peer 364 MUST NOT send another Configure-Nak with this option included. It 365 should assume that the peer's implementation does not support this 366 option. 368 By default, an implementation SHOULD attempt to negotiate the 369 Interface-Identifier for its end of the PPP connection. 371 A summary of the Interface-Identifier Configuration Option format is 372 shown below. The fields are transmitted from left to right. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Length | Interface-Identifier (MS Bytes) 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Interface-Identifier (cont) 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Interface-Identifier (LS Bytes) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Type 386 1 388 Length 390 10 392 Interface-Identifier 394 The 64-bit Interface-Identifier which is very likely to be unique 395 on the link or zero if a good source of uniqueness can not be 396 found. 398 Default Interface-Identifier Value 400 If no valid interface identifier can be successfully negotiated, 401 no default Interface-Identifier value should be assumed. The 402 procedures for recovering from such a case are unspecified. One 403 approach is to manually configure the interface identifier of the 404 interface. 406 5. Stateless Autoconfiguration and Link-Local Addresses 408 The Interface Identifier of IPv6 unicast addresses [6] of a PPP 409 interface, SHOULD be negotiated in the IPV6CP phase of the PPP 410 connection setup (see section 4.1). If no valid Interface Identifier 411 has been successfully negotiated, procedures for recovering from such 412 a case are unspecified. One approach is to manually configure the 413 Interface Identifier of the interface. 415 As long as the Interface Identifier is negotiated in the IPV6CP phase 416 of the PPP connection setup, it is redundant to perform duplicate 417 address detection as a part of the IPv6 Stateless Autoconfiguration 418 protocol [3]. Therefore it is recommended that for PPP links with the 419 IPV6CP Interface-Identifier option enabled the default value of the 420 DupAddrDetectTransmits autoconfiguration variable [3] be zero. 422 Link-local addresses of PPP interfaces have the following format: 424 | 10 bits | 54 bits | 64 bits | 425 +----------+------------------------+-----------------------------+ 426 |1111111010| 0 | Interface Identifier | 427 +----------+------------------------+-----------------------------+ 429 The most significant 10 bits of the address is the Link-Local prefix 430 FE80::. 54 zero bits pad out the address between the Link-Local 431 prefix and the Interface Identifier fields. 433 6. Security Considerations 435 The IPv6 Control Protocol extension to PPP can be used with all 436 defined PPP authentication and encryption mechanisms. 438 7. Acknowledgments 440 This document borrows from the Magic-Number LCP option and as such is 441 partially based on previous work done by the PPP working group. 443 8. Changes from RFC-2023 445 The following changes were made from RFC-2023 "IP Version 6 over PPP": 447 - Changed to use "Interface Identifier" instead of the "Interface 448 Token" term according to the terminology adopted in [6]. 450 - Increased the size of Interface Identifier to 64 bits according 451 to the newly adopted IPv6 addressing architecture [6]. 453 - Added methods for selection of an interface identifier that is 454 consistently reproducible across initializations of the IPV6CP 455 finite state machine. 457 - Added the interface identifier selection methods for generating 458 globally unique interface identifier from an unique an IEEE 459 global identifier when it is available anywhere on the node. 461 - Changed to send a Configure-Nak instead a Configure-Ack in 462 response to receiving a Configure-Request with a zero Interface- 463 Identifier value. 465 - Removed the IPv6 Configuration option definition and added text 466 stating that other than the Interface-Identifier IP6CP 467 configuration options are to be defined in separate documents. 469 - Added new and updated references. 471 - Minor text clarifications and improvements. 473 9. References 475 [1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC 1661, 476 July 1994. 478 [2] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 479 6 (IPv6) Specification", currently draft-ietf-ipngwg-ipv6-spec- 480 v2-01.txt 482 [3] Thomson, S., and T. Narten, "IPv6 Stateless Address 483 Autoconfiguration", currently draft-ietf-ipngwg-addrconfv2-00.txt 485 [4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 486 October 1994. 488 [5] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 489 Registration Authority", 490 http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 491 1997. 493 [6] Hinden, R., and S. Deering, "IP Version 6 Addressing 494 Architecture", currently draft-ietf-ipngwg-addr-arch-v2-02.txt 496 [7] S. Bradner, "Key words for use in RFCs to Indicate Requirement 497 Levels," RFC 2119. 499 [8] Narten T., and C. Burton, "A Caution On The Canonical Ordering Of 500 Link-Layer Addresses", currently draft-narten-canonical- 501 ordering-00.txt. 503 10. Authors' Addresses 505 Dimitry Haskin 506 Bay Networks, Inc. 507 600 Technology Park 508 Billerica, MA 01821 509 email: dhaskin@baynetworks.com 511 Ed Allen 512 Bay Networks, Inc. 513 600 Technology Park 514 Billerica, MA 01821 515 email: eallen@baynetworks.com