< draft-ietf-ipv6-deprecate-site-local-02.txt   draft-ietf-ipv6-deprecate-site-local-03.txt >
INTERNET DRAFT C. Huitema INTERNET DRAFT C. Huitema
<draft-ietf-ipv6-deprecate-site-local-02.txt> Microsoft <draft-ietf-ipv6-deprecate-site-local-03.txt> Microsoft
November 18, 2003 B. Carpenter March 27, 2004 B. Carpenter
Expires June 18, 2004 IBM Expires September 27, 2004 IBM
Deprecating Site Local Addresses Deprecating Site Local Addresses
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
skipping to change at page 10, line ? skipping to change at page 10, line ?
Early feedback from developers indicates that site local addresses Early feedback from developers indicates that site local addresses
are hard to use correctly in an application. This is particularly are hard to use correctly in an application. This is particularly
true for multi-homed hosts, which can be simultaneously connected to true for multi-homed hosts, which can be simultaneously connected to
multiple sites, and for mobile hosts, which can be successively multiple sites, and for mobile hosts, which can be successively
connected to multiple sites. connected to multiple sites.
Applications would learn or remember that the address of some Applications would learn or remember that the address of some
correspondent was "FEC0::1234:5678:9ABC", they would try to feed the correspondent was "FEC0::1234:5678:9ABC", they would try to feed the
address in a socket address structure and issue a connect, and the address in a socket address structure and issue a connect, and the
call will fail because they did not fill up the "site identifier" call will fail because they did not fill up the "site identifier"
variable, as in "FEC0::1234:5678:9ABC&1". The problem is compounded variable, as in "FEC0::1234:5678:9ABC%1". (The use of the %
by the fact that the site identifier varies with the host character as a delimiter for site identifiers is specified in
instantiation, e.g. sometimes &1 and sometimes &2, and thus that the [SCOPING].) The problem is compounded by the fact that the site
host identifier cannot be remembered in memory, or learned from a identifier varies with the host instantiation, e.g. sometimes %1 and
name server. sometimes %2, and thus that the host identifier cannot be remembered
in memory, or learned from a name server.
In short, the developer pain is caused by the ambiguity of site In short, the developer pain is caused by the ambiguity of site
local addresses. Since site-local addresses are ambiguous, local addresses. Since site-local addresses are ambiguous,
application developers have to manage the "site identifiers" that application developers have to manage the "site identifiers" that
qualify the addresses of the hosts. This management of identifiers qualify the addresses of the hosts. This management of identifiers
has proven hard to understand by developers, and also hard to has proven hard to understand by developers, and also hard to
execute by those developers who understand the concept. execute by those developers who understand the concept.
2.2 Developer pain, local addresses 2.2 Developer pain, local addresses
Simple client/server applications that do share IP addresses at the
Carpenter, Huitema. [Page 2] Carpenter, Huitema. [Page 2]
Simple client/server applications that do share IP addresses at the
application layer are made more complex by IPv6 site-local application layer are made more complex by IPv6 site-local
addressing. These applications need to make intelligent decisions addressing. These applications need to make intelligent decisions
about the addresses that should and shouldn't be passed across site about the addresses that should and shouldn't be passed across site
boundaries. These decisions, in practice, require that the boundaries. These decisions, in practice, require that the
applications acquire some knowledge of the network topology. Site applications acquire some knowledge of the network topology. Site
local addresses may be used when client and server are in the same local addresses may be used when client and server are in the same
site, but trying to use them when client and server are in different site, but trying to use them when client and server are in different
sites may result in unexpected errors (i.e. connection reset by sites may result in unexpected errors (i.e. connection reset by
peer) or the establishment of connections with the wrong node. The peer) or the establishment of connections with the wrong node. The
robustness and security implications of sending packets to an robustness and security implications of sending packets to an
skipping to change at page 10, line ? skipping to change at page 10, line ?
The experience with RFC1918 addresses also shows some non trivial The experience with RFC1918 addresses also shows some non trivial
leaks, besides pacing these addresses in IP headers. Private leaks, besides pacing these addresses in IP headers. Private
addresses also end up being used as targets of reverse DNS queries addresses also end up being used as targets of reverse DNS queries
for RFC1918, uselessly overloading the DNS infrastructure. In for RFC1918, uselessly overloading the DNS infrastructure. In
general, many applications that use IP addresses directly end up general, many applications that use IP addresses directly end up
passing RFC1918 addresses in application payloads, creating passing RFC1918 addresses in application payloads, creating
confusion and failures. confusion and failures.
The leakage issue is largely unavoidable. While some applications The leakage issue is largely unavoidable. While some applications
are intrinsically scoped (eg. Router Advertisement, Neighbor
Carpenter, Huitema. [Page 3] Carpenter, Huitema. [Page 3]
are intrinsically scoped (e.g., Router Advertisement, Neighbor
Discovery), most applications have no concept of scope, and no way Discovery), most applications have no concept of scope, and no way
of expressing scope. As a result, "stuff leaks across the borders". of expressing scope. As a result, "stuff leaks across the borders".
Since the addresses are ambiguous, the network managers cannot Since the addresses are ambiguous, the network managers cannot
easily find out "who did it". Leaks are thus hard to fix, resulting easily find out "who did it". Leaks are thus hard to fix, resulting
in a lot of frustration. in a lot of frustration.
2.4 Router pain, routing tables 2.4 Router pain, increased complexity
The ambiguity of site local addresses also creates problems for the The ambiguity of site local addresses also creates complications for
routers. In theory, site local addresses are only used within a the routers. In theory, site local addresses are only used within a
contiguous site, and all routers in that site can treat them as if contiguous site, and all routers in that site can treat them as if
they were not ambiguous. In practice, problem occurs when sites are they were not ambiguous. In practice, special mechanisms are needed
disjoint, or when routers have to handle several sites. when sites are disjoint, or when routers have to handle several
sites.
In theory, sites should never be disjoint. In practice, if site In theory, sites should never be disjoint. In practice, if site
local addressing is used throughout a large network, some elements local addressing is used throughout a large network, some elements
of the site will not be directly connected. This will create a of the site will not be directly connected for example, due to
demand to route the site-local packets across some intermediate network partitioning. This will create a demand to route the site-
network. In practice, this leads to an extensive use of tunneling local packets across some intermediate network (such as the backbone
techniques, or the use of multi-sited routers, or both. area) that cannot be dedicated for a specific site. In practice,
this leads to an extensive use of tunneling techniques, or the use
of multi-sited routers, or both.
Ambiguous addresses have fairly obvious consequences on multi-sited Ambiguous addresses have fairly obvious consequences on multi-sited
routers. In classic router architecture, the exit interface is a routers. In classic router architecture, the exit interface is a
direct function of the destination address, as specified by a single direct function of the destination address, as specified by a single
routing table. However, if a router is connected to multiple sites, routing table. However, if a router is connected to multiple sites,
the routing of site local packets depends on the interface on which the routing of site local packets depends on the interface on which
the packet arrived. Interfaces have to be associated to sites, and the packet arrived. Interfaces have to be associated to sites, and
the routing entries for the site local addresses are site-dependent. the routing entries for the site local addresses are site-dependent.
The route management software and the routing protocols have to Supporting this requires special provisions in routing protocols and
account for the site boundaries. This can be particularly hard to do techniques for routing and forwarding table virtualization that are
when sites are adjacent or overlap. normally used for VPNs. This contributes to additional complexity of
router implementation and management.
Network management complexity is also increased by the fact that
though sites could be supported using existing routing constructs--
such as domains and areas--the factors driving creation and setting
the boundaries of sites are different from the factors driving those
of areas and domains.
In multi-homed routers, such as for example site border routers, the In multi-homed routers, such as for example site border routers, the
routing process should be complemented by a filtering process, to forwarding process should be complemented by a filtering process, to
guarantee that packets sourced with a site local address never leave guarantee that packets sourced with a site local address never leave
the site. This filtering process will in turn interact with the the site. This filtering process will in turn interact with the
routing of packets, as it may cause the drop of packets sent to a forwarding of packets, for example if implementation defects cause
global address, even if that global address happen to belong to the the drop of packets sent to a global address, even if that global
target site. address happen to belong to the target site.
In summary, the ambiguity of site local addresses makes them hard to In summary, the ambiguity of site local addresses makes them hard to
Carpenter, Huitema. [Page 4]
manage in multi-sited routers, while the requirement to support manage in multi-sited routers, while the requirement to support
disjoint sites creates a demand for such routers. disjoint sites and existing routing protocol constructs creates a
demand for such routers.
2.5 Site is an ill-defined concept 2.5 Site is an ill-defined concept
The current definition of scopes follows an idealized "concentric The current definition of scopes follows an idealized "concentric
scopes" model. Hosts are supposed to be attached to a link, which scopes" model. Hosts are supposed to be attached to a link, which
belongs to a site, which belongs to the Internet. Packets could be belongs to a site, which belongs to the Internet. Packets could be
sent to the same link, the same site, or outside that site. However, sent to the same link, the same site, or outside that site. However,
experts have been arguing about the definition of sites for years experts have been arguing about the definition of sites for years
and have reached no sort of consensus. That suggests that there is and have reached no sort of consensus. That suggests that there is
Carpenter, Huitema. [Page 4]
in fact no consensus to be reached. in fact no consensus to be reached.
Apart from link-local, scope boundaries are ill-defined. What is a Apart from link-local, scope boundaries are ill-defined. What is a
site? Is the whole of a corporate network a site, or are sites site? Is the whole of a corporate network a site, or are sites
limited to single geographic locations? Many networks today are limited to single geographic locations? Many networks today are
split between an internal area and an outside facing "DMZ", split between an internal area and an outside facing "DMZ",
separated by a firewall. Servers in the DMZ are supposedly separated by a firewall. Servers in the DMZ are supposedly
accessible by both the internal hosts and external hosts on the accessible by both the internal hosts and external hosts on the
Internet. Does the DMZ belong to the same site as the internal host? Internet. Does the DMZ belong to the same site as the internal host?
skipping to change at page 10, line ? skipping to change at page 10, line ?
The previous section reviewed the arguments against site-local The previous section reviewed the arguments against site-local
addresses. Obviously, site locals also have some benefits, without addresses. Obviously, site locals also have some benefits, without
which they would have been removed from the specification long ago. which they would have been removed from the specification long ago.
The perceived benefits of site local are that they are simple, The perceived benefits of site local are that they are simple,
stable, and private. However, it appears that these benefits can be stable, and private. However, it appears that these benefits can be
also obtained with an alternative architecture, for example also obtained with an alternative architecture, for example
[Hinden/Haberman], in which addresses are not ambiguous and do not [Hinden/Haberman], in which addresses are not ambiguous and do not
have a simple explicit scope. have a simple explicit scope.
Having non-ambiguous address solves a large part of the developers' Having non-ambiguous address solves a large part of the developers'
Carpenter, Huitema. [Page 5]
pain, as it removes the need to manage site identifiers. The pain, as it removes the need to manage site identifiers. The
application can use the addresses as if they were regular global application can use the addresses as if they were regular global
addresses, and the stack will be able to use standard techniques to addresses, and the stack will be able to use standard techniques to
discover which interface should be used. Some level of pain will discover which interface should be used. Some level of pain will
remain, as these addresses will not always be reachable; however, remain, as these addresses will not always be reachable; however,
applications can deal with the un-reachability issues by trying applications can deal with the un-reachability issues by trying
connections at a different time, or with a different address. connections at a different time, or with a different address.
Speculatively, a more sophisticated scope mechanism might be Speculatively, a more sophisticated scope mechanism might be
introduced at a later date. introduced at a later date.
Having non ambiguous addresses will not eliminate the leaks that Having non ambiguous addresses will not eliminate the leaks that
cause management pain. However, since the addresses are not cause management pain. However, since the addresses are not
Carpenter, Huitema. [Page 5]
ambiguous, debugging these leaks will be much simpler. ambiguous, debugging these leaks will be much simpler.
Having non ambiguous addresses will solve a large part of the router Having non ambiguous addresses will solve a large part of the router
issues: since addresses are not ambiguous, routers will be able to issues: since addresses are not ambiguous, routers will be able to
use standard routing techniques, and will not need different routing use standard routing techniques, and will not need different routing
tables for each interface. Some of the pain will remain at border tables for each interface. Some of the pain will remain at border
routers, which will need to filter packets from some ranges of routers, which will need to filter packets from some ranges of
source addresses; this is however a fairly common function. source addresses; this is however a fairly common function.
Avoiding the explicit declaration of scope will remove the issues Avoiding the explicit declaration of scope will remove the issues
skipping to change at page 10, line ? skipping to change at page 10, line ?
addressing architecture [RFC3513] will include this information. addressing architecture [RFC3513] will include this information.
However, router implementations SHOULD be configured to prevent However, router implementations SHOULD be configured to prevent
routing of this prefix by default. routing of this prefix by default.
The references to site local addresses should be removed as soon as The references to site local addresses should be removed as soon as
practical from the revision of the Default Address Selection for practical from the revision of the Default Address Selection for
Internet Protocol version 6 [RFC3484], the revision of the Basic Internet Protocol version 6 [RFC3484], the revision of the Basic
Socket Interface Extensions for IPv6 [RFC3493], and from the Socket Interface Extensions for IPv6 [RFC3493], and from the
revision of the Internet Protocol Version 6 (IPv6) Addressing revision of the Internet Protocol Version 6 (IPv6) Addressing
Carpenter, Huitema. [Page 6]
Architecture [RFC3513]. Incidental references to site local Architecture [RFC3513]. Incidental references to site local
addresses should be removed from other IETF documents if and when addresses should be removed from other IETF documents if and when
they are updated. These documents include [RFC2772, RFC2894, they are updated. These documents include [RFC2772, RFC2894,
RFC3082, RFC3111, RFC3142, RFC3177, RFC3316]. RFC3082, RFC3111, RFC3142, RFC3177, and RFC3316].
Existing implementations and deployments MAY continue to use this Existing implementations and deployments MAY continue to use this
prefix. prefix.
5 Security Considerations 5 Security Considerations
The use of ambiguous site-local addresses has the potential to
adversely affect network security through leaks, ambiguity and
potential misrouting, as documented in section 2. Deprecating the
use of ambiguous addresses helps solving many of these problems.
The site-local unicast prefix allows for some blocking action in The site-local unicast prefix allows for some blocking action in
firewall rules and address selection rules, which are commonly firewall rules and address selection rules, which are commonly
Carpenter, Huitema. [Page 6]
viewed as a security feature since they prevent packets crossing viewed as a security feature since they prevent packets crossing
administrative boundaries. Such blocking rules can be configured for administrative boundaries. Such blocking rules can be configured for
any prefix, including the expected future replacement for the site- any prefix, including the expected future replacement for the site-
local prefix. If these blocking rules are actually enforced, the local prefix. If these blocking rules are actually enforced, the
deprecation of the site-local prefix does not endanger security. deprecation of the site-local prefix does not endanger security.
6 IANA Considerations 6 IANA Considerations
IANA is specifically requested not to reassign the 1111111011 binary IANA is requested to mark the FEC0::/10 prefix as "deprecated",
or FEC0::/10 prefix unless requested to do so by a future IETF pointing to this document. Reassignment of the prefix for any usage
standards action. requires justification via an IETF Standards Action [RFC2434].
7 Copyright 7 Copyright
The following copyright notice is copied from RFC 2026 [Bradner, The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this 1996], Section 10.4, and describes the applicable copyright for this
document. document.
Copyright (C) The Internet Society November 14, 2003. All Rights Copyright (C) The Internet Society March 26, 2004. All Rights
Reserved. Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
Carpenter, Huitema. [Page 7]
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
8 Intellectual Property 8 Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996], The following notice is copied from RFC 2026 [Bradner, 1996],
Section 10.4, and describes the position of the IETF concerning Section 10.4, and describes the position of the IETF concerning
intellectual property claims made against this document. intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Carpenter, Huitema. [Page 7]
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such to obtain a general license or permission for the use of such
skipping to change at page 10, line ? skipping to change at page 10, line ?
Chirayu Patel, Pekka Savola, and Alain Baudot for their review of Chirayu Patel, Pekka Savola, and Alain Baudot for their review of
the initial draft. The text of section 2.2 includes 2 paragraphs the initial draft. The text of section 2.2 includes 2 paragraphs
taken from a draft by Margaret Wasserman describing the impact of taken from a draft by Margaret Wasserman describing the impact of
site local addressing. Alain Durand pointed out the need to revise site local addressing. Alain Durand pointed out the need to revise
existing RFC that make reference to site local addresses. existing RFC that make reference to site local addresses.
10 References 10 References
Normative References Normative References
[RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
Carpenter, Huitema. [Page 8]
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October 1998.
[RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003
Informative references Informative references
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J. and E. Lear, "Address Allocation for Private Internets", RFC J. and E. Lear, "Address Allocation for Private Internets", RFC
1918, February 1996 1918, February 1996
[Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6 [Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6
Unicast Addresses", work in progress. Unicast Addresses", work in progress.
[RFC2772] Rockell, R. and R. Fink. "6Bone Backbone Routing [RFC2772] Rockell, R. and R. Fink. "6Bone Backbone Routing
Guidelines." RFC 2772, February 2000. Guidelines." RFC 2772, February 2000.
[RFC2894] M. Crawford. "Router Renumbering for IPv6." RFC 2894, [RFC2894] M. Crawford. "Router Renumbering for IPv6." RFC 2894,
August 2000. August 2000.
Carpenter, Huitema. [Page 8]
[RFC3082] Kempf, J. and J. Goldschmidt. "Notification and [RFC3082] Kempf, J. and J. Goldschmidt. "Notification and
Subscription for SLP." RFC 3082, March 2001. Subscription for SLP." RFC 3082, March 2001.
[RFC3111] E. Guttman. "Service Location Protocol Modifications for [RFC3111] E. Guttman. "Service Location Protocol Modifications for
IPv6." RFC 3111, May 2001. IPv6." RFC 3111, May 2001.
[RFC3142] Hagino, J. and K. Yamamoto. "An IPv6-to-IPv4 Transport [RFC3142] Hagino, J. and K. Yamamoto. "An IPv6-to-IPv4 Transport
Relay Translator." RFC 3142, June 2001. Relay Translator." RFC 3142, June 2001.
[RFC3177] IAB, IESG. "IAB/IESG Recommendations on IPv6 Address." RFC [RFC3177] IAB, IESG. "IAB/IESG Recommendations on IPv6 Address." RFC
skipping to change at page 10, line ? skipping to change at page 10, line ?
Wiljakka. "Internet Protocol Version 6 (IPv6) for Some Second and Wiljakka. "Internet Protocol Version 6 (IPv6) for Some Second and
Third Generation Cellular Hosts." RFC 3316, April 2003. Third Generation Cellular Hosts." RFC 3316, April 2003.
[RFC3484] R. Draves. "Default Address Selection for Internet [RFC3484] R. Draves. "Default Address Selection for Internet
Protocol version 6 (IPv6)." RFC 3484, February 2003. Protocol version 6 (IPv6)." RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W.
Stevens. "Basic Socket Interface Extensions for IPv6." RFC 3493, Stevens. "Basic Socket Interface Extensions for IPv6." RFC 3493,
February 2003. February 2003.
[RFC3513] Hinden, R. and S. Deering. "Internet Protocol Version 6 [SCOPING] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
(IPv6) Addressing Architecture." RFC 3513, April 2003. B. Zill, "IPv6 Scoped Address Architecture", work in progress.
11 Authors' Addresses 11 Authors' Addresses
Christian Huitema Christian Huitema
Microsoft Corporation Microsoft Corporation
Carpenter, Huitema. [Page 9]
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA USA
Email: huitema@microsoft.com Email: huitema@microsoft.com
Brian Carpenter Brian Carpenter
IBM Corporation IBM Corporation
Sauemerstrasse 4 Sauemerstrasse 4
8803 Rueschlikon 8803 Rueschlikon
Switzerland Switzerland
Email: brc@zurich.ibm.com Email: brc@zurich.ibm.com
12 History of changes 12 History of changes
12.1 Changes from draft-00 to draft-01 12.1 Changes from draft-00 to draft-01
Changed the text in the introduction to say that the decision was Changed the text in the introduction to say that the decision was
"confirmed" in July 2003. "confirmed" in July 2003.
Add some explanatory text in section 2.2, address leak, and section Add some explanatory text in section 2.2, address leak, and section
Carpenter, Huitema. [Page 9]
2.3, routing pain. 2.3, routing pain.
In section 4, and 5 change the erroneous "link local" to "site In section 4, and 5 change the erroneous "link local" to "site
local". local".
Add a reference to RFC 2119 describing the use of keywords. Add a reference to RFC 2119 describing the use of keywords.
In section 5, qualify that the replacement of site local is only as In section 5, qualify that the replacement of site local is only as
secure if blocking rules are actually implemented at site secure if blocking rules are actually implemented at site
boundaries. boundaries.
skipping to change at page 11, line 5 skipping to change at page 10, line ?
application payloads. application payloads.
Added a paragraph in section 4 recommending the removal of Added a paragraph in section 4 recommending the removal of
references to site local addresses from several RFC. Added these RFC references to site local addresses from several RFC. Added these RFC
to the Reference section. to the Reference section.
Removed the reference to the draft "Addressing Requirements for Removed the reference to the draft "Addressing Requirements for
Local Communications within Sites", in order to avoid references to Local Communications within Sites", in order to avoid references to
drafts that may slow down document publication. drafts that may slow down document publication.
Table of Contents: 12.3 Changes from draft-02 to draft-03
1 Introduction .................................................... 1 The changes from draft 02 to draft 03 take into account the IESG
2 Adverse effects of site local addresses ......................... 2 comments.
2.1 Developer pain, scope identifiers ............................. 2
2.2 Developer pain, local addresses ............................... 2 A reference to the scoped addresses architecture draft has been
2.3 Manager pain, leaks ........................................... 3 added to section 2.1, in order to explain the usage of the % sign to
2.4 Router pain, routing tables ................................... 4 document site numbers in site local addresses.
2.5 Site is an ill-defined concept ................................ 4
3 Development of a better alternative ............................. 5 Section 2.4 has been reworded following suggestions by Alex Zinin,
4 Deprecation ..................................................... 6 essentially to change the tone from "this creates a problem" to
5 Security Considerations ......................................... 6 "this would increase router implementation and management
6 IANA Considerations ............................................. 7 complexity".
7 Copyright ....................................................... 7
8 Intellectual Property ........................................... 7 A new paragraph has been added to the security considerations,
9 Acknowledgements ................................................ 8 reiterating the issues due to ambiguity which were brought up in the
10 References ..................................................... 8 preceding sections.
11 Authors' Addresses ............................................. 9
12 History of changes ............................................. 9 The IANA considerations have been rewritten for greater precision.
12.1 Changes from draft-00 to draft-01 ............................ 9
12.2 Changes from draft-01 to draft-02 ............................ 10 A duplicate reference to RFC 3513 has been removed.
 End of changes. 34 change blocks. 
51 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/