idnits 2.17.1 draft-hinden-ipv6-sl-moderate-01.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. ** 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. 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 (February 28, 2003) is 7727 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: 'DEFAULT' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'IPV6' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 279, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDARCH' ** Obsolete normative reference: RFC 2462 (ref. 'ADDAUTO') (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. 'DEFAULT' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCP6' ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3041 (ref. 'PRIV') (Obsoleted by RFC 4941) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 February 28, 2003 4 Moderate Use Case for IPv6 Site-Local Addresses 6 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. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the list Internet-Draft Shadow Directories, see 22 http://www.ietf.org/shadow.html. 24 This internet draft expires on August 28, 2003. 26 Abstract 28 This internet draft describes the moderate use case for IPv6 Site- 29 Local Addresses. 31 1.0 Introduction 33 This internet draft describes the Moderate use case for IPv6 Site- 34 Local addresses. Site-Local addresses are defined in the IPv6 35 Addressing Architecture [ADDARCH]. The IPv6 working group has been 36 discussing what is the appropriate use scenario for IPv6 Site-Local 37 addresses. The draft describes a possible scenario. 39 The Moderate use case for IPv6 Site-Local addresses allows Site-Local 40 addresses to be used inside of a site for services and applications 41 that prefer to use Site-Local addresses for communication inside of 42 the site. Sites may use site-local addresses concurrently with 43 global routable addresses or may use them exclusively if they are 44 disconnected from the Internet and do not have any IPv6 global 45 routable addresses. 47 The moderate use scenario limits site-local usage to cases where 48 site-local addresses are purposely enabled and configured by an 49 administrator. Site-local addresses will not be used if the source 50 and destination hosts could have used global addresses instead. 52 The moderate use scenario document includes approaches for keeping 53 site-local addresses and DNS names inside of a site, site border 54 router issues, site-local uniqueness issues, and changes and/or 55 extensions to existing IPv6 documents. 57 2.0 Acknowledgments 59 The author would like to thank Andrew White, Bob Fink, Hiroki 60 Ishibashi, Juha Wiljakka Pekka Savola, Rich Draves, Rob Austein, and 61 Tony Hain for their comments and suggestions on this document. 63 3.0 Site Definition 65 The document doesn't attempt to define a site in exact terms. A site 66 is a set of associated subnets. Sites do not overlap each other. 67 Sites typically range from home or small office to a campus of a 68 large organization. In most cases the site boundary is where there 69 is an administrative or geographic boundary such as where the 70 connection to an ISP is or a campus in a specific geographic 71 location. In many IPv6 transition scenarios an IPv6 over IPv4 tunnel 72 will be created at the edge of a site. In routing protocol terms 73 this is where typically there is an IGP/EGP boundary or between areas 74 in an IGP like OSPF. 76 4.0 Site-Local Moderate Use Scenario 78 The moderate use scenario for IPv6 site-local addresses allows for 79 the use of site-local addresses concurrently with global IPv6 80 addresses. The use of site-local addresses is limited to cases where 81 an administrator has configured hosts and services to use them. They 82 will not be used if the source and destination hosts could have used 83 global addresses instead. 85 The motivation for this use case is to restrict the use of site-local 86 addresses to communication inside of the site and insure that they 87 are very unlikely to be used for any site to site communication. 88 Using limited scope addresses for site to site communication, while 89 possible (i.e., via tunneling or VPN technologies), is problematic 90 and makes it hard to debug problems. Overall it is simpler to use 91 global addresses. 93 4.1 Site-Local Address Assignment 95 IPv6 site-local addresses, like global scope unicast addresses, are 96 only assigned to nodes if their use has been enabled (via IPv6 97 address autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually) and 98 configured in the DNS. They are not created automatically the way 99 that IPv6 link-local addresses are and will not appear or be used 100 unless they are purposely configured. 102 In order for hosts to autoconfigure site-local addresses routers have 103 to be configured to advertise site-local /64 prefixes in router 104 advertisements. Likewise, a DHCPv6 server must have been configured 105 to assign them. In order for a node to learn the site-local address 106 of another node, the Site-local address must have been installed in 107 the DNS. For these reasons, it is straight forward to control their 108 usage in a site. 110 To limit the use of site-local addresses the following guidelines 111 apply: 113 - Nodes that are to only be reachable inside of a site, the local 114 DNS should be configured to only include the site-local 115 addresses of these nodes. Nodes with only site-local addresses 116 must not be installed in the global DNS. 118 - Nodes that are to be limited to only communicate with other 119 nodes in the site should be set to only autoconfigure site-local 120 addresses via [ADDAUTO] or to only receive site-local addresses 121 via [DHCP6]. Note: For the case where both global and site- 122 local prefixes are being advertised on a subnet, this will 123 require a switch in the devices to only autoconfigure site-local 124 addresses. See section 5.1 for more details on this. 126 - Nodes that are to be reachable from inside of the site and 127 outside of the site, the DNS should be configured to include the 128 global addresses of these nodes. The local DNS may be 129 configured to also include the site-local addresses of these 130 nodes. 132 - Nodes that can communicate with other nodes inside of the site 133 and outside of the site, should autoconfigure global addresses 134 via [ADDAUTO] or receive global address via [DHCP6]. They may 135 also obtain site-local addresses via the same mechanisms. 137 4.2 Site Local Address Selection 139 In order for nodes to limit their use of site-locals to specific 140 configured cases the following address selection rules are needed: 142 - If the destination only has a site-local address, the source 143 should prefer to use a site-local source address. 145 - If the destination only has a global address, the source should 146 prefer to use a global source address. 148 - If a source has a site-local and global addresses, and the 149 destination has site-local and global addresses, the source 150 should use the global address as the source address and use the 151 global address of the destination as the destination address. 153 Note, this is a change to IPv6 Default Address Selection. See 154 section 5.2 for details of these changes. 156 4.3 Site Border Router Filtering 158 It is important to keep any packets with site-local source or 159 destination addresses from leaking outside of the site and to keep 160 any site-local prefixes from being advertised outside of their site. 162 There are two cases to implement this filtering requirements: Site- 163 Border routers and firewalls. 165 4.3.1 Site Border Routers 167 Site border routers must install a black hole route for the Site- 168 Local prefix FEC0::/10. This will insure that packets with Site- 169 Local destination addresses will not be forwarded outside of the site 170 via a default route. 172 Site border routers must not forward any packets with site-local 173 source or destination addresses outside of the site. This requires a 174 filter to be installed in the site-border router. 176 A simple approach to creating a site border router is to allow an 177 interface to be configured in a "no site" site. If an interface is 178 in the "no site" site, then the router will not forward any packets 179 with site-local source and/or destination addresses to or from this 180 interface. 182 If BGP is being used at the site border with an ISP, filters must be 183 installed in the BGP configuration to keep any site-local prefixes 184 from being advertised outside of the site or for site-local prefixes 185 to be learned from another site. 187 4.3.2 Firewalls 189 Firewalls are commonly used in IPv4 to create site boundaries and are 190 sometimes used to limit the scope of IPv4 addresses. This includes 191 filtering packets with private IPv4 source or destination addresses. 193 If IPv6 firewalls are used to connect the site to other sites 194 (including ISPs), then the firewall must install filters to drop 195 packets with site-local source and/or destination addresses to keep 196 them from entering or exiting the site. 198 4.4 Routing 200 Site-local addresses should be routed inside the site just like any 201 other unicast addresses. They can be carried in any IPv6 routing 202 protocol without any change. It is expected that an instance of an 203 IGP routing protocols will be run inside of a single site. 205 Any routing protocol that is used between sites is required to filter 206 out any incoming or outgoing site-local routes. For example, if BGP 207 is being used at the site border with an ISP, filters must be 208 installed in the BGP configuration to keep any site-local prefixes 209 from being advertised outside of the site or for site-local prefixes 210 to be learned from another site. 212 4.5 DNS Naming Issues 214 Site-Local addresses must not be installed in the global DNS. They 215 may be installed in a naming system local to the site or kept 216 separate from the global DNS using techniques such as "two-faced" 217 DNS. Approaches for doing this are common in the IPv4 Internet 218 today. 220 4.6 Site-Local Uniqueness Issues 222 Site-local addresses as defined in [ADDARCH] all share a common 223 prefix (i.e., FEC0::/10). There is a potential for confusion if 224 packets containing these type of address were to escape the site. 225 Due to the the way that addresses are autoconfigured in IPv6 with 226 IPv6 IPv6 autoconfiguration [ADDAUTO] is very unlikely that two 227 complete 128-bit site-local addresses would ever conflict with each 228 other. It is unlikely to be a problem in practice. This is also 229 true if temporary address were created using the privacy extensions 230 defined in [PRIV]. IPv6 addresses created manually or with stateful 231 methods such as [DHCP6] might have some potential for conflict. For 232 this reason it is preferable to only create IPv6 site-local addresses 233 with [ADDAUTO] or [PRIV]. 235 5.0 Changes and Extensions to Existing Specifications 237 5.1 IPv6 Node Requirements 239 Nodes that are to intended to have the capability to be limited to 240 only communicate with other nodes inside of the site (e.g., no global 241 communication) should include a switch that has a site-only setting. 242 This could be a software configuration or a hardware toggle switch 243 for simple appliances. 245 Support for multi-sited nodes is not required. Routers that are 246 designed to be used at site borders should implement the "no site" 247 site and firewalls should support site border filtering. 249 5.2 Default Address Selection 251 TBD [Document changes to default address selection] 253 6.0 Security Considerations 255 TBD 256 REFERENCES 258 [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing 259 Architecture", Internet Draft, , October 2002. 262 [ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address 263 Autoconfiguration", RFC2462, December 1998. 265 [DEFAULT] Draves, R., "Default Address Selection for IPv6", 266 Internet Draft, , November 2002. 273 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 274 (IPv6) Specification", RFC2460, December 1998. 276 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 277 3", RFC2026, BCP00009, October 1996. 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", RFC2119, BCP14, March 1997. 282 [PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless 283 Address Autoconfiguration in IPv6" RFC3041, January 284 2001. 286 AUTHOR'S ADDRESS 288 Robert M. Hinden 289 Nokia 290 313 Fairchild Drive 291 Mountain View, CA 94043 292 USA 294 phone: +1 650 625-2004 295 email: hinden@iprg.nokia.com