idnits 2.17.1 draft-thaler-intarea-multilink-subnet-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 515. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 479), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 266: '...says "the client MUST silently discard...' RFC 2119 keyword, line 307: '...nk-local address MUST be tested for un...' RFC 2119 keyword, line 308: '...detected, an implementation MAY choose...' RFC 2119 keyword, line 316: '... unicast address SHOULD be tested for ...' RFC 2119 keyword, line 322: '...mization" is NOT RECOMMENDED, and new ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 2006) is 6464 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) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) == Outdated reference: A later version (-47) exists of draft-ietf-dnsext-mdns-45 -- Obsolete informational reference (is this intentional?): RFC 1884 (Obsoleted by RFC 2373) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft D. Thaler 3 February 15, 2006 Microsoft 4 Expires August 2006 6 Issues With Protocols Proposing Multilink Subnets 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2006). All Rights Reserved. 36 Abstract 38 There have been several proposals around the notion that a subnet 39 may span multiple links connected by routers. This memo documents 40 the issues and potential problems that have been raised with such an 41 approach. 43 1. Introduction 45 The original IPv4 address definition [RFC791] consisted of a Network 46 field, identifying a network number, and a Local Address field, 47 identifying a host within that network. As organizations grew to 48 want many links within their network, their choices were (from 49 [RFC950]) to: 51 1. Acquire a distinct Internet network number for each cable; 52 subnets are not used at all. 54 Draft Multilink Subnet Issues February 2006 56 2. Use a single network number for the entire organization, but 57 assign host numbers without regard to which LAN a host is on 58 ("transparent subnets"). 60 3. Use a single network number, and partition the host address 61 space by assigning subnet numbers to the LANs ("explicit 62 subnets"). 64 [RFC925] was a proposal for option 2 which defined a specific type 65 of ARP proxy behavior, where the forwarding plane had the properties 66 of decrementing the TTL to prevent loops when forwarding, not 67 forwarding packets destined to 255.255.255.255, and supporting 68 subnet broadcast by requiring that the ARP-based bridge maintain a 69 list of recent broadcast packets. This approach was never 70 standardized. 72 Instead, the IETF standardized option 3 with [RFC950], whereby hosts 73 were required to learn a subnet mask, and this became the IPv4 74 model. 76 Over the recent past there have been several newer protocols 77 proposing to extend the notion of a subnet to be able to span 78 multiple links, similar to [RFC925]. 80 Early drafts of the IPv6 scoped address architecture [SCOPID] 81 proposed a subnet scope above the link scope, to allow for multi- 82 link subnets. This notion was rejected by the WG due to the issues 83 discussed in this memo, and as a result the final version [RFC4007] 84 has no such notion. 86 There was also a proposal to define multi-link subnets [MLSR] for 87 IPv6. However this notion was abandoned by the IPv6 WG due to the 88 issues discussed in this memo, and that proposal was replaced by a 89 different mechanism which preserves the notion that a subnet spans 90 only one link [RFC4389]. 92 However, other WGs continued to allow for this concept even though 93 it had been rejected in the IPv6 WG. Mobile IPv6 [RFC3775] allows 94 tunnels to mobile nodes to use the same subnet as a home link, with 95 the Home Agent doing layer-3 forwarding between them. 97 The notion also arises in Mobile Ad-hoc NETworks (MANETs) with 98 proposals that an entire MANET is a subnet, with routers doing 99 layer-3 forwarding within it. 101 In this memo we document the issues raised in the IPv6 WG which 102 motivated the abandonment of the multi-link subnet concept, so that 103 designers of other protocols can (and should) be aware of the 104 issues. 106 Draft Multilink Subnet Issues February 2006 108 2. Issues 110 2.1. IP Model 112 The term "link" is generally used to refer to a topological area 113 bounded by routers which decrement the IPv4 TTL or IPv6 Hop Limit 114 when forwarding the packet. A link-local address prefix is defined 115 in both IPv4 [RFC3927] and IPv6 [RFC3513]. 117 The term "subnet" is generally used to refer to a topological area 118 that uses the same address prefix, where that prefix is not further 119 subdivided except into individual addresses. 121 In December 1995, the original IP Version 6 Addressing Architecture 122 [RFC1884] was published, stating: "IPv6 continues the IPv4 model 123 that a subnet is associated with one link. Multiple subnets may be 124 assigned to the same link." 126 Thus it explicitly acknowledges that the current IPv4 model has been 127 that a subnet is associated with one link, and that IPv6 does not 128 change this model. Furthermore, a subnet is sometimes considered to 129 be only a subset of a link, when multiple subnets are assigned to 130 the same link. 132 The IPv6 addressing architecture has since been updated twice, first 133 in July 1998 [RFC2373] and again in April 2003 [RFC3513]. Both 134 updates include the language: "Currently IPv6 continues the IPv4 135 model that a subnet prefix is associated with one link. Multiple 136 subnet prefixes may be assigned to the same link." 138 Clearly the notion of a multi-link subnet would be a change to the 139 existing IP model. 141 Similarly, the Mobility Related Terminology [RFC3753] defines a 142 Foreign subnet prefix as "A bit string that consists of some number 143 of initial bits of an IP address which identifies a node's foreign 144 link within the Internet topology" with a similar definition for a 145 Home subnet prefix. These both state that the subnet prefix 146 identifies a (singular) link. 148 2.2. TTL/Hop Limit Issues 150 Since a link is bounded by routers that decrement the IPv4 TTL or 151 IPv6 Hop Limit, there may be issues with applications and protocols 152 that make any assumption about the relationship between TTL/Hop 153 Limit and subnet prefix. 155 There are two main cases which may arise. Some applications and 156 protocols may send packets with a TTL/Hop Limit of 1. Other 157 applications and protocols may send packets with a TTL/Hop Limit of 158 255, and verify that the value is 255 on receipt. Both are ways of 159 limiting communication to within a single link. 161 Draft Multilink Subnet Issues February 2006 163 As for assumptions about the relationship between TTL/Hop Limit and 164 subnet, let's look at some example references familiar to many 165 protocol and application developers. 167 Stevens' "Unix Network Programming, 2nd ed." [UNP] states on page 168 490 "a TTL if 0 means node-local, 1 means link-local" (this of 169 course being true by the definition of link). Then page 498 states, 170 regarding IP_MULTICAST_TTL and IPV6_MULTICAST_HOPS, "If this is not 171 specified, both default to 1, which restricts the datagram to the 172 local subnet." Here, Unix programmers learn that TTL=1 packets are 173 restricted to a subnet (as opposed to a link). This is typical of 174 many documents which use the terms interchangeably due to the IP 175 Model described earlier. 177 Similarly, "TCP/IP Illustrated, Volume 1" [TCPILL] states on page 178 182: "By default, multicast datagrams are sent with a TTL of 1. This 179 restricts the datagram to the same subnet." 181 Steve Deering's original multicast README file [DEERING] contained 182 the statement "multicast datagrams with initial TTL 1 are restricted 183 to the same subnet", and similar statements now appear in many 184 vendors' documentation, including documentation for Windows (e.g., 185 [TCPIP2K]) and Linux (e.g., [LINUX] says a TTL of 1 is "Restricted 186 to the same subnet. Won't be forwarded by a router.") 188 The above are only some examples. There is no shortage of places 189 where application developers are being taught that a subnet is 190 confined to a single link, and so we must expect that arbitrary 191 applications may embed such assumptions. 193 Some examples of protocols today that are known to embed some 194 assumption about the relationship between TTL and subnet prefix are: 196 o Neighbor Discovery [RFC2461] uses messages with Hop Limit 255 197 checked on receipt, to resolve the link-layer address of any IP 198 address in the subnet. 200 o Apple's Bonjour [MDNS] uses messages with TTL 255 checked on 201 receipt, and only responds to queries from addresses in the same 202 subnet. (Note that multilink subnets do not necessarily break 203 this, as this behavior is to constrain communication to within a 204 subnet, where a subnet is only a subset of a link; however it 205 will not work across a multi-link subnet.) 207 Some other examples of protocols today that are known to use a TTL 1 208 or 255, but do not appear to explicitly have any assumption about the 209 relationship to subnet prefixes (other than the well-known link-local 210 prefix) include: 212 o [LLMNR] uses a TTL/Hop Limit of 1. 214 o MLDv2 [RFC3810] uses a Hop Limit of 1. 216 Draft Multilink Subnet Issues February 2006 218 o Reverse tunneling for Mobile IPv4 [RFC3024] uses TTL 255 checked 219 on receipt for Registration Requests sent to foreign agents. 221 o [RFC3927] discusses the use of TTL=1 and TTL=255 within the IPv4 222 link-local address prefix. 224 It is unknown whether any implementations of such protocols exist 225 that add such assumptions about the relationship to subnet prefixes 226 for other reasons. 228 2.3. Link-scoped multicast and broadcast 230 Because multicast routing is not ubiquitous, the notion of a subnet 231 which spans multiple links tends to result in cases where multicast 232 does not work across the subnet. Per [RFC2644], the default 233 behavior is that routers do not forward broadcast packets either. 235 There are many protocols and applications today that use link-scoped 236 multicast. The list of such applications and protocols that have 237 been assigned their own link-scoped multicast group address (and may 238 also have assumptions about the TTL/Hop Limit as noted above) can be 239 found at: 241 http://www.iana.org/assignments/multicast-addresses 243 http://www.iana.org/assignments/ipv6-multicast-addresses 245 In addition, an arbitrarily large number of other applications may 246 be using the all-1's broadcast address, or the all-hosts link-scoped 247 multicast address, rather than their own group address. 249 The well-known examples of protocols using link-scoped multicast or 250 broadcast generally fall into one of the following groups: 252 o Routing protocols: DVMRP, OSPF, RIP, EIGRP, etc. These 253 protocols exchange routes to subnet prefixes. 255 o Addressing protocols: ND, DHCPv4, DHCPv6, Teredo, etc. By their 256 nature this group tends to embed assumptions about the 257 relationship between a link and a subnet prefix. For example, 258 ND [RFC2461] uses link-scoped multicast to resolve the link- 259 layer address of an IP address in the same subnet prefix, and to 260 do duplicate address detection (see section 2.4 below) within 261 the subnet. DHCP uses link-scoped multicast or broadcast to 262 obtain an address in the subnet. Teredo [RFC4380] states: "An 263 IPv4 multicast address used to discover other Teredo clients on 264 the same IPv4 subnet. The value of this address is 265 224.0.0.253", which is a link-scoped multicast address. It also 266 says "the client MUST silently discard all local discovery 267 bubbles [...] whose IPv4 source address does not belong to the 268 local IPv4 subnet". 270 Draft Multilink Subnet Issues February 2006 272 o Service discovery protocols: SSDP, Bonjour, WS-Discovery, etc. 273 These often do not define any explicit assumption about the 274 relationship to subnet prefix. 276 o Name resolution protocols: NetBios [RFC1001], Bonjour [MDNS], 277 LLMNR, etc. Most often these do not define any explicit 278 assumption about the relationship to subnet prefix, but [MDNS] 279 only responds to queries from addresses within the same subnet 280 prefix. 282 Note that protocols such as Bonjour and Teredo which drop packets 283 which don't come from an address within the subnet are not 284 necessarily broken by multilink subnets, as this behavior is meant to 285 constrain the behavior to within a subnet, when a link is larger than 286 a single subnet. 288 However, regardless of whether any assumption about the relationship 289 to subnet prefixes exists, all protocols mentioned above or on the 290 IANA assignments list will not work across a multilink subnet without 291 protocol-specific proxying functionality in routers, and adding 292 proxying for an arbitrary number of protocols and applications does 293 not scale. Furthermore, it may hinder the development and use of 294 future protocols using link-scoped multicast. 296 2.4. Duplicate Address Detection Issues 298 Duplicate Address Detection (DAD) uses link-scoped multicast in 299 IPv6, and link-scoped broadcast in IPv4 and so has the issues 300 mentioned in Section 2.3 above. 302 In addition, [RFC2461] contains the statement: 304 "Thus, for a set of addresses formed from the same interface 305 identifier, it is sufficient to check that the link-local address 306 generated from the identifier is unique on the link. In such 307 cases, the link-local address MUST be tested for uniqueness, and 308 if no duplicate address is detected, an implementation MAY choose 309 to skip Duplicate Address Detection for additional addresses 310 derived from the same interface identifier." 312 The last possibility, sometimes referred to as Duplicate Interface 313 Identifier Detection (DIID), has been a matter of much debate, and 314 the current draft in progress states: 316 Each individual unicast address SHOULD be tested for uniqueness. 317 Note that there are implementations deployed that only perform 318 Duplicate Address Detection for the link-local address and skip 319 the test for the global address using the same interface 320 identifier as that of the link-local address. Whereas this 321 document does not invalidate such implementations, this kind of 322 "optimization" is NOT RECOMMENDED, and new implementations MUST 323 NOT do that optimization. 325 Draft Multilink Subnet Issues February 2006 327 The existence of such implementations also causes problems with 328 multilink subnets. Specifically, a link-local address is only valid 329 within a link, and hence is only tested for uniqueness within a 330 single link. If the same interface identifier is then assumed to be 331 unique across all links within a multilink subnet, address conflicts 332 can occur. 334 3. Security Considerations 336 The notion of multilink subnets can cause problems with any security 337 protocols which either rely on the assumption that a subnet only 338 spans a single link, or can leave gaps in the security solution 339 where protocols are only defined for use on a single link. 341 Secure Neighbor Discovery [RFC3971], in particular, is currently 342 only defined within a single link. If a subnet were to span 343 multiple links, SEND would not work as currently specified. This 344 same problem also exists in cases where a subnet does not span 345 multiple links but where Neighbor Discovery is proxied within a 346 link. Section 9 of [RFC4389] discusses some possible future 347 directions in this regard. 349 Furthermore, as noted above some applications and protocols (ND, 350 Bonjour, Mobile IPv4, etc.) mitigate against off-link spoofing 351 attempts by requiring a TTL or Hop Limit of 255 on receipt. If this 352 restriction were removed, or if alternative protocols were used, 353 then off-link spoofing attempts would become easier, and some 354 alternative way to mitigate against such attacks would be needed. 356 4. IANA Considerations 358 This document has no actions for IANA. 360 5. Normative References 362 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 363 1981. 365 [RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting 366 Procedure", STD 5, RFC 950, August 1985. 368 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 369 Discovery for IP Version 6 (IPv6)", RFC 2461, December 370 1998. 372 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 373 in Routers", BCP 34, RFC 2644, August 1999. 375 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 376 (IPv6) Addressing Architecture", RFC 3513, April 2003. 378 Draft Multilink Subnet Issues February 2006 380 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 381 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 382 2005. 384 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 385 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 387 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 388 B. Zill. "IPv6 Scoped Address Architecture", RFC 4007, 389 March 2005. 391 6. Informative References 393 [DEERING] Deering, S., "IP Multicast Extensions for 4.3BSD UNIX and 394 related systems (MULTICAST 1.2 Release)", June 1989. 395 http://www.kohala.com/start/mcast.api.txt 397 [LINUX] Juan-Mariano de Goyeneche, "Multicast over TCP/IP HOWTO", 398 March 1998. http://www.linux.com/howtos/Multicast-HOWTO- 399 2.shtml 401 [LLMNR] Aboba, B., Thaler, D. and L. Esibov, "Linklocal Multicast 402 Name Resolution (LLMNR)", draft-ietf-dnsext-mdns-45.txt, 403 October 2005. 405 [MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet 406 Draft, June 2005. http://files.multicastdns.org/draft- 407 cheshire-dnsext-multicastdns.txt 409 [MLSR] Thaler, D. and C. Huitema, "Multi-link Subnet Support in 410 IPv6", draft-ietf-ipv6-multilink-subnets-00.txt (expired), 411 June 2002. http://www.ietf.org/proceedings/02jul/I- 412 D/draft-ietf-ipv6-multilink-subnets-00.txt 414 [RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, 415 October 1984. 417 [RFC1001] NetBIOS Working Group in the Defense Advanced Research 418 Projects Agency, Internet Activities Board, End-to-End 419 Services Task Force, "Protocol standard for a NetBIOS 420 service on a TCP/UDP transport: Concepts and methods", RFC 421 1001, March 1987. 423 [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing 424 Architecture", RFC 1884, December 1995. 426 [RFC2373] R. Hinden, S. Deering, "IP Version 6 Addressing 427 Architecture", RFC 2373, July 1998. 429 [RFC3024] G. Montenegro, Ed., "Reverse Tunneling for Mobile IP, 430 revised", RFC 3024, January 2001. 432 Draft Multilink Subnet Issues February 2006 434 [RFC3753] J. Manner, Ed., M. Kojo, Ed., "Mobility Related 435 Terminology", RFC 3753, June 2004. 437 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 438 in IPv6", RFC 3775, June 2004. 440 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 441 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 443 [RFC4380] C. Huitema, "Teredo: Tunneling IPv6 over UDP through 444 Network Address Translations (NATs)", RFC 4380, February 445 2006. 447 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 448 Proxies (ND Proxy)", RFC 4389, February 2006. 450 [SCOPID] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, 451 A., and B. Zill. "IPv6 Scoped Address Architecture", 452 Internet-Draft (Obsolete), March 2005. 453 http://www.ietf.org/proceedings/02jul/I-D/draft-ietf- 454 ipngwg-scoping-arch-04.txt 456 [TCPILL] Stevens, W. Richard, "TCP/IP Illustrated, Volume 1", 457 Addison-Wesley, 1994. 459 [TCPIP2K] MacDonald, D. and W. Barkley, "Microsoft Windows 2000 460 TCP/IP Implementation Details". 461 http://www.microsoft.com/technet/itsolutions/network/deplo 462 y/depovg/tcpip2k.mspx 464 [UNP] Stevens, W. Richard, "Unix Network Programming, Volume 1, 465 Second Edition", Prentice Hall, 1998. 467 Authors' Addresses 469 Dave Thaler 470 Microsoft 471 One Microsoft Way 472 Redmond, WA 98052 473 Phone: +1 425 703 8835 474 Email: dthaler@microsoft.com 475 Draft Multilink Subnet Issues February 2006 477 Full Copyright Statement 479 Copyright (C) The Internet Society (2006). 481 This document is subject to the rights, licenses and restrictions 482 contained in BCP 78, and except as set forth therein, the authors 483 retain all their rights. 485 This document and the information contained herein are provided on 486 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 487 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 488 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 489 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 490 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 491 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 493 Intellectual Property 495 The IETF takes no position regarding the validity or scope of any 496 Intellectual Property Rights or other rights that might be claimed 497 to pertain to the implementation or use of the technology described 498 in this document or the extent to which any license under such 499 rights might or might not be available; nor does it represent that 500 it has made any independent effort to identify any such rights. 501 Information on the procedures with respect to rights in RFC 502 documents can be found in BCP 78 and BCP 79. 504 Copies of IPR disclosures made to the IETF Secretariat and any 505 assurances of licenses to be made available, or the result of an 506 attempt made to obtain a general license or permission for the use 507 of such proprietary rights by implementers or users of this 508 specification can be obtained from the IETF on-line IPR repository 509 at http://www.ietf.org/ipr. 511 The IETF invites any interested party to bring to its attention any 512 copyrights, patents or patent applications, or other proprietary 513 rights that may cover technology that may be required to implement 514 this standard. Please address the information to the IETF at ietf- 515 ipr@ietf.org. 517 Thaler Expires August 2006 10