idnits 2.17.1 draft-ietf-ipv6-deprecate-site-local-03.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 a Security Considerations section. ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' The IANA considerations have been rewritten for greater precision.' ) ** The document seems to lack an Authors' Addresses Section. ** There are 20 instances of lines with control characters in the document. ** The abstract seems to contain references ([SCOPING], [RFC3493], [RFC3513], [RFC2119], [RFC2434], [Bradner,1996], [RFC1918], [RFC3484]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'Bradner' is mentioned on line 389, but not defined -- Looks like a reference, but probably isn't: '1996' on line 389 == Unused Reference: 'RFC2772' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC2894' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC3082' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC3111' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC3142' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC3177' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC3316' is defined on line 464, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3177 (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3316 (Obsoleted by RFC 7066) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 March 27, 2004 B. Carpenter 4 Expires September 27, 2004 IBM 6 Deprecating Site Local Addresses 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 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 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes the issues surrounding the use of IPv6 site- 32 local unicast addresses in their original form, and formally 33 deprecates them. This deprecation does not prevent their continued 34 use until a replacement has been standardized and implemented. 36 1 Introduction 38 For some time, the IPv6 working group has been debating a set of 39 issues surrounding the use of "site local" addresses. In its meeting 40 in March 2003, the group reached a measure of agreement that these 41 issues were serious enough to warrant a replacement of site local 42 addresses in their original form. Although the consensus was far 43 from unanimous, the working group confirmed in its meeting in July 44 2003 the need to document these issues and the consequent decision 45 to deprecate IPv6 site-local unicast addresses. 47 Site-local addresses are defined in the IPv6 addressing architecture 48 [RFC3513], especially in section 2.5.6. 50 The remainder of this document describes the adverse effects of 51 site-local addresses according to the above definition, and formally 52 deprecates them. 54 Carpenter, Huitema. [Page 1] 55 Companion documents will describe the goals of a replacement 56 solution and specify a replacement solution. However, the formal 57 deprecation allows existing usage of site-local addresses to 58 continue until the replacement is standardized and implemented. 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 2 Adverse effects of site local addresses 66 Discussions in the IPv6 working group outlined several defects of 67 the current site local addressing scope. These defects fall in two 68 broad categories: ambiguity of addresses, and fuzzy definition of 69 sites. 71 As currently defined, site local addresses are ambiguous: an address 72 such as FEC0::1 can be present in multiple sites, and the address 73 itself does not contain any indication of the site to which it 74 belongs. This creates pain for developers of applications, for the 75 designers of routers and for the network managers. This pain is 76 compounded by the fuzzy nature of the site concept. We will develop 77 the specific nature of this pain in the following section. 79 2.1 Developer pain, scope identifiers 81 Early feedback from developers indicates that site local addresses 82 are hard to use correctly in an application. This is particularly 83 true for multi-homed hosts, which can be simultaneously connected to 84 multiple sites, and for mobile hosts, which can be successively 85 connected to multiple sites. 87 Applications would learn or remember that the address of some 88 correspondent was "FEC0::1234:5678:9ABC", they would try to feed the 89 address in a socket address structure and issue a connect, and the 90 call will fail because they did not fill up the "site identifier" 91 variable, as in "FEC0::1234:5678:9ABC%1". (The use of the % 92 character as a delimiter for site identifiers is specified in 93 [SCOPING].) The problem is compounded by the fact that the site 94 identifier varies with the host instantiation, e.g. sometimes %1 and 95 sometimes %2, and thus that the host identifier cannot be remembered 96 in memory, or learned from a name server. 98 In short, the developer pain is caused by the ambiguity of site 99 local addresses. Since site-local addresses are ambiguous, 100 application developers have to manage the "site identifiers" that 101 qualify the addresses of the hosts. This management of identifiers 102 has proven hard to understand by developers, and also hard to 103 execute by those developers who understand the concept. 105 2.2 Developer pain, local addresses 107 Carpenter, Huitema. [Page 2] 108 Simple client/server applications that do share IP addresses at the 109 application layer are made more complex by IPv6 site-local 110 addressing. These applications need to make intelligent decisions 111 about the addresses that should and shouldn't be passed across site 112 boundaries. These decisions, in practice, require that the 113 applications acquire some knowledge of the network topology. Site 114 local addresses may be used when client and server are in the same 115 site, but trying to use them when client and server are in different 116 sites may result in unexpected errors (i.e. connection reset by 117 peer) or the establishment of connections with the wrong node. The 118 robustness and security implications of sending packets to an 119 unexpected end-point will differ from application to application. 121 Multi-party applications that pass IP addresses at the application 122 layer present a particular challenge. Even if a node can correctly 123 determine whether a single remote node belongs or not to the local 124 site, it will have no way of knowing where those addresses may 125 eventually be sent. The best course of action for these 126 applications might be to use only global addresses. However, this 127 would prevent the use of these applications on isolated or 128 intermittently connected networks that only have site-local 129 addresses available, and might be incompatible with the use of site- 130 local addresses for access control in some cases. 132 In summary, the ambiguity of site local addresses leads to 133 unexpected application behavior when application payloads carry 134 these addresses outside the local site. 136 2.3 Manager pain, leaks 138 The management of IPv6 site local addresses is in many ways similar 139 to the management of RFC 1918 [RFC1918] addresses in some IPv4 140 networks. In theory, the private addresses defined in RFC 1918 141 should only be used locally, and should never appear in the 142 Internet. In practice, these addresses "leak". The conjunction of 143 leaks and ambiguity ends up causing management problems. 145 Names and literal addresses of "private" hosts leak in mail 146 messages, web pages, or files. Private addresses end up being used 147 as source or destination of TCP requests or UDP messages, for 148 example in DNS or trace-route requests, causing the request to fail, 149 or the response to arrive at unsuspecting hosts. 151 The experience with RFC1918 addresses also shows some non trivial 152 leaks, besides pacing these addresses in IP headers. Private 153 addresses also end up being used as targets of reverse DNS queries 154 for RFC1918, uselessly overloading the DNS infrastructure. In 155 general, many applications that use IP addresses directly end up 156 passing RFC1918 addresses in application payloads, creating 157 confusion and failures. 159 The leakage issue is largely unavoidable. While some applications 161 Carpenter, Huitema. [Page 3] 162 are intrinsically scoped (e.g., Router Advertisement, Neighbor 163 Discovery), most applications have no concept of scope, and no way 164 of expressing scope. As a result, "stuff leaks across the borders". 165 Since the addresses are ambiguous, the network managers cannot 166 easily find out "who did it". Leaks are thus hard to fix, resulting 167 in a lot of frustration. 169 2.4 Router pain, increased complexity 171 The ambiguity of site local addresses also creates complications for 172 the routers. In theory, site local addresses are only used within a 173 contiguous site, and all routers in that site can treat them as if 174 they were not ambiguous. In practice, special mechanisms are needed 175 when sites are disjoint, or when routers have to handle several 176 sites. 178 In theory, sites should never be disjoint. In practice, if site 179 local addressing is used throughout a large network, some elements 180 of the site will not be directly connected for example, due to 181 network partitioning. This will create a demand to route the site- 182 local packets across some intermediate network (such as the backbone 183 area) that cannot be dedicated for a specific site. In practice, 184 this leads to an extensive use of tunneling techniques, or the use 185 of multi-sited routers, or both. 187 Ambiguous addresses have fairly obvious consequences on multi-sited 188 routers. In classic router architecture, the exit interface is a 189 direct function of the destination address, as specified by a single 190 routing table. However, if a router is connected to multiple sites, 191 the routing of site local packets depends on the interface on which 192 the packet arrived. Interfaces have to be associated to sites, and 193 the routing entries for the site local addresses are site-dependent. 194 Supporting this requires special provisions in routing protocols and 195 techniques for routing and forwarding table virtualization that are 196 normally used for VPNs. This contributes to additional complexity of 197 router implementation and management. 199 Network management complexity is also increased by the fact that 200 though sites could be supported using existing routing constructs-- 201 such as domains and areas--the factors driving creation and setting 202 the boundaries of sites are different from the factors driving those 203 of areas and domains. 205 In multi-homed routers, such as for example site border routers, the 206 forwarding process should be complemented by a filtering process, to 207 guarantee that packets sourced with a site local address never leave 208 the site. This filtering process will in turn interact with the 209 forwarding of packets, for example if implementation defects cause 210 the drop of packets sent to a global address, even if that global 211 address happen to belong to the target site. 213 In summary, the ambiguity of site local addresses makes them hard to 215 Carpenter, Huitema. [Page 4] 216 manage in multi-sited routers, while the requirement to support 217 disjoint sites and existing routing protocol constructs creates a 218 demand for such routers. 220 2.5 Site is an ill-defined concept 222 The current definition of scopes follows an idealized "concentric 223 scopes" model. Hosts are supposed to be attached to a link, which 224 belongs to a site, which belongs to the Internet. Packets could be 225 sent to the same link, the same site, or outside that site. However, 226 experts have been arguing about the definition of sites for years 227 and have reached no sort of consensus. That suggests that there is 228 in fact no consensus to be reached. 230 Apart from link-local, scope boundaries are ill-defined. What is a 231 site? Is the whole of a corporate network a site, or are sites 232 limited to single geographic locations? Many networks today are 233 split between an internal area and an outside facing "DMZ", 234 separated by a firewall. Servers in the DMZ are supposedly 235 accessible by both the internal hosts and external hosts on the 236 Internet. Does the DMZ belong to the same site as the internal host? 238 Depending on whom we ask, the definition of the site scope varies. 239 It may map security boundaries, reachability boundaries, routing 240 boundaries, QOS boundaries, administrative boundaries, funding 241 boundaries, some other kinds of boundaries, or a combination of 242 these. It is very unclear that a single scope could satisfy all 243 these requirements. 245 There are some well known and important scope-breaking phenomena, 246 such as intermittently connected networks, mobile nodes, mobile 247 networks, inter-domain VPNs, hosted networks, network merges and 248 splits, etc. Specifically, this means that scope *cannot* be mapped 249 into concentric circles such as a naive link/local/global model. 250 Scopes overlap and extend into one another. The scope relationship 251 between two hosts may even be different for different protocols. 253 In summary, the current concept of site is naive, and does not map 254 operational requirements. 256 3 Development of a better alternative 258 The previous section reviewed the arguments against site-local 259 addresses. Obviously, site locals also have some benefits, without 260 which they would have been removed from the specification long ago. 261 The perceived benefits of site local are that they are simple, 262 stable, and private. However, it appears that these benefits can be 263 also obtained with an alternative architecture, for example 264 [Hinden/Haberman], in which addresses are not ambiguous and do not 265 have a simple explicit scope. 267 Having non-ambiguous address solves a large part of the developers' 269 Carpenter, Huitema. [Page 5] 270 pain, as it removes the need to manage site identifiers. The 271 application can use the addresses as if they were regular global 272 addresses, and the stack will be able to use standard techniques to 273 discover which interface should be used. Some level of pain will 274 remain, as these addresses will not always be reachable; however, 275 applications can deal with the un-reachability issues by trying 276 connections at a different time, or with a different address. 277 Speculatively, a more sophisticated scope mechanism might be 278 introduced at a later date. 280 Having non ambiguous addresses will not eliminate the leaks that 281 cause management pain. However, since the addresses are not 282 ambiguous, debugging these leaks will be much simpler. 284 Having non ambiguous addresses will solve a large part of the router 285 issues: since addresses are not ambiguous, routers will be able to 286 use standard routing techniques, and will not need different routing 287 tables for each interface. Some of the pain will remain at border 288 routers, which will need to filter packets from some ranges of 289 source addresses; this is however a fairly common function. 291 Avoiding the explicit declaration of scope will remove the issues 292 linked to the ambiguity of the site concept. Non-reachability can be 293 obtained by using "firewalls" where appropriate. The firewall rules 294 can explicitly accommodate various network configurations, by 295 accepting of refusing traffic to and from ranges of the new non- 296 ambiguous addresses. 298 One question remains, anycast addressing. Anycast addresses are 299 ambiguous by construction, since they refer by definition to any 300 host that has been assigned a given anycast address. Link-local or 301 global anycast addresses can be "baked in the code". Further study 302 is required on the need for anycast addresses with scope between 303 link-local and global. 305 4 Deprecation 307 This document formally deprecates the IPv6 site-local unicast prefix 308 defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The 309 special behavior of this prefix MUST no longer be supported in new 310 implementations. The prefix MUST NOT be reassigned for other use 311 except by a future IETF standards action. Future versions of the 312 addressing architecture [RFC3513] will include this information. 314 However, router implementations SHOULD be configured to prevent 315 routing of this prefix by default. 317 The references to site local addresses should be removed as soon as 318 practical from the revision of the Default Address Selection for 319 Internet Protocol version 6 [RFC3484], the revision of the Basic 320 Socket Interface Extensions for IPv6 [RFC3493], and from the 321 revision of the Internet Protocol Version 6 (IPv6) Addressing 323 Carpenter, Huitema. [Page 6] 324 Architecture [RFC3513]. Incidental references to site local 325 addresses should be removed from other IETF documents if and when 326 they are updated. These documents include [RFC2772, RFC2894, 327 RFC3082, RFC3111, RFC3142, RFC3177, and RFC3316]. 329 Existing implementations and deployments MAY continue to use this 330 prefix. 332 5 Security Considerations 334 The use of ambiguous site-local addresses has the potential to 335 adversely affect network security through leaks, ambiguity and 336 potential misrouting, as documented in section 2. Deprecating the 337 use of ambiguous addresses helps solving many of these problems. 339 The site-local unicast prefix allows for some blocking action in 340 firewall rules and address selection rules, which are commonly 341 viewed as a security feature since they prevent packets crossing 342 administrative boundaries. Such blocking rules can be configured for 343 any prefix, including the expected future replacement for the site- 344 local prefix. If these blocking rules are actually enforced, the 345 deprecation of the site-local prefix does not endanger security. 347 6 IANA Considerations 349 IANA is requested to mark the FEC0::/10 prefix as "deprecated", 350 pointing to this document. Reassignment of the prefix for any usage 351 requires justification via an IETF Standards Action [RFC2434]. 353 7 Copyright 355 The following copyright notice is copied from RFC 2026 [Bradner, 356 1996], Section 10.4, and describes the applicable copyright for this 357 document. 359 Copyright (C) The Internet Society March 26, 2004. All Rights 360 Reserved. 362 This document and translations of it may be copied and furnished to 363 others, and derivative works that comment on or otherwise explain it 364 or assist in its implementation may be prepared, copied, published 365 and distributed, in whole or in part, without restriction of any 366 kind, provided that the above copyright notice and this paragraph 367 are included on all such copies and derivative works. However, this 368 document itself may not be modified in any way, such as by removing 369 the copyright notice or references to the Internet Society or other 370 Internet organizations, except as needed for the purpose of 371 developing Internet standards in which case the procedures for 372 copyrights defined in the Internet Standards process must be 373 followed, or as required to translate it into languages other than 374 English. 376 Carpenter, Huitema. [Page 7] 377 The limited permissions granted above are perpetual and will not be 378 revoked by the Internet Society or its successors or assignees. 380 This document and the information contained herein is provided on an 381 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 382 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 383 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 384 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 385 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 387 8 Intellectual Property 389 The following notice is copied from RFC 2026 [Bradner, 1996], 390 Section 10.4, and describes the position of the IETF concerning 391 intellectual property claims made against this document. 393 The IETF takes no position regarding the validity or scope of any 394 intellectual property or other rights that might be claimed to 395 pertain to the implementation or use other technology described in 396 this document or the extent to which any license under such rights 397 might or might not be available; neither does it represent that it 398 has made any effort to identify any such rights. Information on the 399 IETF's procedures with respect to rights in standards-track and 400 standards-related documentation can be found in BCP-11. Copies of 401 claims of rights made available for publication and any assurances 402 of licenses to be made available, or the result of an attempt made 403 to obtain a general license or permission for the use of such 404 proprietary rights by implementers or users of this specification 405 can be obtained from the IETF Secretariat. 407 The IETF invites any interested party to bring to its attention any 408 copyrights, patents or patent applications, or other proprietary 409 rights which may cover technology that may be required to practice 410 this standard. Please address the information to the IETF Executive 411 Director. 413 9 Acknowledgements 415 The authors would like to thank Fred Templin, Peter Bieringer, 416 Chirayu Patel, Pekka Savola, and Alain Baudot for their review of 417 the initial draft. The text of section 2.2 includes 2 paragraphs 418 taken from a draft by Margaret Wasserman describing the impact of 419 site local addressing. Alain Durand pointed out the need to revise 420 existing RFC that make reference to site local addresses. 422 10 References 424 Normative References 426 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 427 Requirement Levels", RFC 2119, March 1997. 429 Carpenter, Huitema. [Page 8] 431 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an 432 IANA Considerations Section in RFCs", RFC 2434, October 1998. 434 [RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing 435 Architecture", RFC 3513, April 2003 437 Informative references 439 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 440 J. and E. Lear, "Address Allocation for Private Internets", RFC 441 1918, February 1996 443 [Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6 444 Unicast Addresses", work in progress. 446 [RFC2772] Rockell, R. and R. Fink. "6Bone Backbone Routing 447 Guidelines." RFC 2772, February 2000. 449 [RFC2894] M. Crawford. "Router Renumbering for IPv6." RFC 2894, 450 August 2000. 452 [RFC3082] Kempf, J. and J. Goldschmidt. "Notification and 453 Subscription for SLP." RFC 3082, March 2001. 455 [RFC3111] E. Guttman. "Service Location Protocol Modifications for 456 IPv6." RFC 3111, May 2001. 458 [RFC3142] Hagino, J. and K. Yamamoto. "An IPv6-to-IPv4 Transport 459 Relay Translator." RFC 3142, June 2001. 461 [RFC3177] IAB, IESG. "IAB/IESG Recommendations on IPv6 Address." RFC 462 3177, September 2001. 464 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J. and J. 465 Wiljakka. "Internet Protocol Version 6 (IPv6) for Some Second and 466 Third Generation Cellular Hosts." RFC 3316, April 2003. 468 [RFC3484] R. Draves. "Default Address Selection for Internet 469 Protocol version 6 (IPv6)." RFC 3484, February 2003. 471 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. 472 Stevens. "Basic Socket Interface Extensions for IPv6." RFC 3493, 473 February 2003. 475 [SCOPING] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 476 B. Zill, "IPv6 Scoped Address Architecture", work in progress. 478 11 Authors' Addresses 480 Christian Huitema 481 Microsoft Corporation 483 Carpenter, Huitema. [Page 9] 484 One Microsoft Way 485 Redmond, WA 98052-6399 486 USA 487 Email: huitema@microsoft.com 489 Brian Carpenter 490 IBM Corporation 491 Sauemerstrasse 4 492 8803 Rueschlikon 493 Switzerland 494 Email: brc@zurich.ibm.com 496 12 History of changes 498 12.1 Changes from draft-00 to draft-01 500 Changed the text in the introduction to say that the decision was 501 "confirmed" in July 2003. 503 Add some explanatory text in section 2.2, address leak, and section 504 2.3, routing pain. 506 In section 4, and 5 change the erroneous "link local" to "site 507 local". 509 Add a reference to RFC 2119 describing the use of keywords. 511 In section 5, qualify that the replacement of site local is only as 512 secure if blocking rules are actually implemented at site 513 boundaries. 515 12.2 Changes from draft-01 to draft-02 517 Inserted a new section "2.2 Developer pain, local addresses" to 518 capture the pain caused by ambiguous addresses carried in 519 application payloads. 521 Added a paragraph in section 4 recommending the removal of 522 references to site local addresses from several RFC. Added these RFC 523 to the Reference section. 525 Removed the reference to the draft "Addressing Requirements for 526 Local Communications within Sites", in order to avoid references to 527 drafts that may slow down document publication. 529 12.3 Changes from draft-02 to draft-03 531 The changes from draft 02 to draft 03 take into account the IESG 532 comments. 534 A reference to the scoped addresses architecture draft has been 535 added to section 2.1, in order to explain the usage of the % sign to 536 document site numbers in site local addresses. 538 Section 2.4 has been reworded following suggestions by Alex Zinin, 539 essentially to change the tone from "this creates a problem" to 540 "this would increase router implementation and management 541 complexity". 543 A new paragraph has been added to the security considerations, 544 reiterating the issues due to ambiguity which were brought up in the 545 preceding sections. 547 The IANA considerations have been rewritten for greater precision. 549 A duplicate reference to RFC 3513 has been removed.