idnits 2.17.1 draft-iab-net-transparent-05.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 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 686. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 371 has weird spacing: '..." sites which...' -- 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 (22 March 2007) is 6244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 474 -- Looks like a reference, but probably isn't: '2' on line 477 -- Looks like a reference, but probably isn't: '3' on line 484 -- Looks like a reference, but probably isn't: '4' on line 489 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Aboba, Ed. 3 INTERNET-DRAFT Elwyn Davies 4 Category: Informational Internet Architecture Board 5 6 22 March 2007 8 Reflections on Internet Transparency 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 28, 2007. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). All Rights Reserved. 37 Abstract 39 This document provides a review of previous IAB statements on 40 Internet transparency, as well a discussion of new transparency 41 issues. Far from having lessened in relevance, technical 42 implications of intentionally or inadvertently impeding network 43 transparency play a critical role in the Internet's ability to 44 support innovation and global communication. This document provides 45 some specific illustrations of those potential impacts. 47 Table of Contents 49 1. Introduction .......................................... 3 50 2. Additional Transparency Issues ........................ 5 51 2.1 Application Restriction ......................... 5 52 2.2 Quality of Service .............................. 7 53 2.3 Application Layer Gateways ...................... 8 54 2.4 IPv6 Address Restrictions ....................... 8 55 2.5 DNS Issues ...................................... 10 56 2.6 Load Balancing and Redirection .................. 11 57 3. Security Considerations ............................... 11 58 4. IANA Considerations ................................... 12 59 5. References ............................................ 12 60 5.1 Informative References .......................... 12 61 Acknowledgments .............................................. 14 62 Appendix A - IAB Members ..................................... 14 63 Authors' Addresses ........................................... 15 64 Full Copyright Statement ..................................... 15 65 Intellectual Property ........................................ 16 66 1. Introduction 68 In the past, the IAB has published a number of documents relating to 69 Internet transparency and the end-to-end principle, and other IETF 70 documents have also touched on these issues as well. These documents 71 articulate the general principles on which the Internet architecture 72 is based, as well as the core values which the Internet community 73 seeks to protect going forward. This document reaffirms those 74 principles, describes the concept of "oblivious transport" as 75 developed in the DARPA NewArch project [NewArch] and addresses a 76 number of new transparency issues. 78 A network that does not filter or transform the data that it carries 79 may be said to be "transparent" or "oblivious" to the content of 80 packets. Networks that provide oblivious transport enable the 81 deployment of new services without requiring changes to the core. It 82 is this flexibility which is perhaps both the Internet's most 83 essential characteristic as well as one of the most important 84 contributors to its success. 86 "Architectural Principles of the Internet" [RFC1958] Section 2 87 describes the core tenets of the Internet architecture: 89 However, in very general terms, the community believes that the 90 goal is connectivity, the tool is the Internet Protocol, and the 91 intelligence is end to end rather than hidden in the network. 93 The current exponential growth of the network seems to show that 94 connectivity is its own reward, and is more valuable than any 95 individual application such as mail or the World-Wide Web. This 96 connectivity requires technical cooperation between service 97 providers, and flourishes in the increasingly liberal and 98 competitive commercial telecommunications environment. 100 "The Rise of the Middle and the Future of End-to-End: Reflections on 101 the Evolution of the Internet Architecture" [RFC3724] Section 4.1.1 102 describes some of the desirable consequences of this approach: 104 One desirable consequence of the end-to-end principle is 105 protection of innovation. Requiring modification in the network 106 in order to deploy new services is still typically more difficult 107 than modifying end nodes. The counterargument - that many end 108 nodes are now essentially closed boxes which are not updatable and 109 that most users don't want to update them anyway - does not apply 110 to all nodes and all users. Many end nodes are still user 111 configurable and a sizable percentage of users are "early 112 adopters," who are willing to put up with a certain amount of 113 technological grief in order to try out a new idea. And, even for 114 the closed boxes and uninvolved users, downloadable code that 115 abides by the end-to-end principle can provide fast service 116 innovation. Requiring someone with a new idea for a service to 117 convince a bunch of ISPs or corporate network administrators to 118 modify their networks is much more difficult than simply putting 119 up a Web page with some downloadable software implementing the 120 service. 122 Yet even while the Internet has greatly expanded both in size and in 123 application diversity, the degree of transparency has diminished. 124 "Internet Transparency" [RFC2775] notes some of the causes for the 125 loss of Internet transparency and analyzes their impact. This 126 includes discussion of Network Address Translators (NATs), firewalls, 127 application level gateways (ALGs), relays, proxies, caches, split 128 Domain Name Service (DNS), load balancers, etc. [RFC2775] also 129 analyzes potential future directions that could lead to the 130 restoration of transparency. Section 6 summarizes the conclusions: 132 Although the pure IPv6 scenario is the cleanest and simplest, it 133 is not straightforward to reach it. The various scenarios without 134 use of IPv6 are all messy and ultimately seem to lead to dead ends 135 of one kind or another. Partial deployment of IPv6, which is a 136 required step on the road to full deployment, is also messy but 137 avoids the dead ends. 139 While full restoration of Internet transparency through the 140 deployment of IPv6 remains a goal, the Internet's growing role in 141 society, the increasing diversity of applications and the continued 142 growth in security threats has altered the balance between 143 transparency and security, and the disparate goals of interested 144 parties make these tradeoffs inherently complex. 146 While transparency provides great flexibility, it also makes it 147 easier to deliver unwanted as well as wanted traffic. Unwanted 148 traffic is increasingly cited as a justification for limiting 149 transparency. If taken to its logical conclusion, this argument will 150 lead to the development of ever more complex transparency barriers to 151 counter increasingly sophisticated security threats. Transparency, 152 once lost, is hard to regain, so that such an approach, if 153 unsuccessful, would lead to an Internet that is both insecure and 154 lacking in transparency. The alternative is to develop increasingly 155 sophisticated host-based security mechanisms; while such an approach 156 may also fail to keep up with increasingly sophisticated security 157 threats, it is less likely to sacrifice transparency in the process. 159 Since many of the fundamental forces that have led to a reduction in 160 the transparency of the IPv4 Internet also may play a role in the 161 IPv6 Internet, the transparency of the IPv6 Internet is not pre- 162 ordained, but rather represents an ideal whose maintenance will 163 require significant ongoing effort. 165 As noted in [NewArch], the technical cooperation which once 166 characterized the development of the Internet has increasingly given 167 way to a tussle between the interests of subscribers, vendors, 168 providers and society at large. Oblivious transport may be desired 169 by developers seeking to deploy new services; providers may desire to 170 block unwanted traffic in the core before it impacts subscribers; 171 vendors and providers may wish to enable delivery of "value added" 172 services in the network that enable them to differentiate their 173 offerings; subscribers may be sympathetic to either point of view, 174 depending on their interests; society at large may wish to block 175 "offensive" material and monitor traffic that shows malicious intent. 177 While there is no architectural "fix" that can restore oblivious 178 transport while satisfying the interests of all parties, it is 179 possible for providers to provide subscribers with information about 180 the nature of the services being provided. Subscribers need to be 181 aware of whether they are receiving oblivious transport, and if not, 182 how the service affects their traffic. 184 Since the publication of the previously cited IAB statements, new 185 technologies have been developed, and views on existing technology 186 have changed. In some cases, these new technologies impact oblivious 187 transport, and subscribers need to be aware of the implications for 188 their service. 190 2. Additional Transparency Issues 192 2.1. Application Restriction 194 Since one of the virtues of the Internet architecture is the ease 195 with which new applications can be deployed, practices which restrict 196 the ability to deploy new applications have the potential to reduce 197 innovation. 199 One such practice is filtering designed to block or restrict 200 application usage, implemented without customer consent. This 201 includes Internet, Transport and Application layer filtering designed 202 to block or restrict traffic associated with one or more 203 applications. 205 While provider filtering may be useful to address security issues 206 such as attacks on provider infrastructure or denial of service 207 attacks, greater flexibility is provided by allowing filtering to be 208 determined by the customer. Typically this would be implemented at 209 the edges, such as within provider access routers (e.g. outsourced 210 firewall services), customer premise equipment (e.g. access 211 firewalls), or on hosts (e.g. host firewalls). Deployment of 212 filtering at the edges provides customers with the flexibility to 213 choose which applications they wish to block or restrict, whereas 214 filtering in the core may not permit hosts to communicate even when 215 the communication would conform to the appropriate use policies of 216 the administrative domains to which those hosts belong. 218 In practice, filtering intended to block or restrict application 219 usage is difficult to successfully implement without customer 220 consent, since over time developers will tend to re-engineer filtered 221 protocols so as to avoid the filters. Thus over time, filtering is 222 likely to result in interoperability issues or unnecessary 223 complexity. These costs come without the benefit of effective 224 filtering since many application protocols began to use HTTP as a 225 transport protocol after application developers observed that 226 firewalls allow HTTP traffic while dropping packets for unknown 227 protocols. 229 In addition to architectural concerns, filtering to block or restrict 230 application usage also raises issues of disclosure and end user 231 consent. As pointed out in "Terminology for Describing Internet 232 Connectivity" [RFC4084] services advertised as providing "Internet 233 connectivity" differ considerably in their capabilities, leading to 234 confusion. The document defines terminology relating to Internet 235 connectivity, including "Web connectivity", "Client connectivity 236 only, without a public address", "Client only, public address", 237 "Firewalled Internet Connectivity", and "Full Internet Connectivity". 238 With respect to "Full Internet Connectivity", [RFC4084] Section 2 239 notes: 241 Filtering Web proxies, interception proxies, NAT, and other 242 provider-imposed restrictions on inbound or outbound ports and 243 traffic are incompatible with this type of service. Servers ... 244 are typically considered normal. The only compatible restrictions 245 are bandwidth limitations and prohibitions against network abuse 246 or illegal activities. 248 [RFC4084] Section 4 describes disclosure obligations that apply to 249 all forms of service limitation, whether applied on outbound or 250 inbound traffic: 252 More generally, the provider should identify any actions of the 253 service to block, restrict, or alter the destination of, the 254 outbound use (i.e., the use of services not supplied by the 255 provider or on the provider's network) of applications services. 257 In essence, [RFC4084] calls for providers to declare the ways in 258 which the service provided departs from oblivious transport. Since 259 the lack of oblivious transport within transit networks will also 260 affect transparency, this also applies to providers over whose 261 network the subscriber's traffic may travel. 263 2.2. Quality of Service 265 While [RFC4084] notes that bandwidth limitations are compatible with 266 "Full Internet Connectivity", in some cases QoS restrictions may go 267 beyond simple average or peak bandwidth limitations. When used to 268 restrict the ability to deploy new applications, QoS mechanisms are 269 incompatible with "Full Internet Connectivity" as defined in 270 [RFC4084]. The disclosure and consent obligations referred to in 271 [RFC4084] Section 4 also apply to QoS mechanisms. 273 Deployment of Quality of Service (QoS) technology has potential 274 implications for Internet transparency, since the QoS experienced by 275 a flow can make the Internet more or less oblivious to that flow. 276 While QoS support is highly desirble in order for real time services 277 to coexist with elastic services, it is not without impact on packet 278 delivery. 280 Specifically, QoS classes such as "default" [RFC2474] or "lower 281 effort" [RFC3662] may experience higher random loss rates than others 282 such as "assured forwarding" [RFC2597]. Conversely, bandwidth- 283 limited QoS classes such as "expedited forwarding" [RFC3246] may 284 experience systematic packet loss if they exceed their assigned 285 bandwidth. Other QoS mechanisms such as load balancing may have 286 side-effects such as re-ordering of packets, which may have serious 287 impact on perceived performance. 289 QoS implementations that reduce the ability to deploy new 290 applications on the Internet are similar in effect to other 291 transparency barriers. Since arbitrary or severe bandwidth 292 limitations can make an application unusable, the introduction of 293 application-specific bandwidth limitations is equivalent to 294 application blocking or restriction from a user's standpoint. 296 Using QoS mechanisms to discriminate against traffic not matching a 297 set of services or addresses has a similar effect to deployment of a 298 highly restrictive firewall. Requiring an authenticated RSVP 299 reservation [RFC2747][RFC3182] for a flow to avoid severe packet loss 300 has a similar effect to deployment of authenticated firewall 301 traversal. 303 As with filtering, there may be valid uses for customer-imposed QoS 304 restrictions. For example, a customer may wish to limit the 305 bandwidth consumed by peer-to-peer file sharing services, so as to 306 limit the impact on mission critical applications. 308 2.3. Application Layer Gateways (ALGs) 310 The IAB has devoted considerable attention to Network Address 311 Translation (NAT), so that there is little need to repeat that 312 discussion here. However, with the passage of time, it has become 313 apparent that there are problems inherent in the deployment of 314 Application Layer Gateways (ALGs) (frequently embedded within 315 firewalls and devices implementing NAT). 317 [RFC2775] Section 3.5 states: 319 If the full range of Internet applications is to be used, NATs 320 have to be coupled with application level gateways (ALGs) or 321 proxies. Furthermore, the ALG or proxy must be updated whenever a 322 new address-dependent application comes along. In practice, NAT 323 functionality is built into many firewall products, and all useful 324 NATs have associated ALGs, so it is difficult to disentangle their 325 various impacts. 327 With the passage of time and development of NAT traversal 328 technologies such as IKE NAT-T [RFC3947], Teredo [RFC4380] and STUN 329 [RFC3489], it has become apparent that ALGs represent an additional 330 barrier to transparency. In addition to posing barriers to the 331 deployment of new applications not yet supported by ALGs, ALGs may 332 create difficulties in the deployment of existing applications as 333 well as updated versions. For example, in the development of IKE 334 NAT-T, additional difficulties were presented by "IPsec Helper" ALGs 335 embedded within NATs. 337 It should be stressed that these difficulties are inherent in the 338 architecture of ALGs, rather than merely an artifact of poor 339 implementations. No matter how well an ALG is implemented, over time 340 barriers to transparency will emerge, so that the notion of a 341 "transparent ALG" is a contradiction in terms. 343 In particular, DNS ALGs present a host of issues, including 344 incompatibilities with DNSSEC that prevent deployment of a secure 345 naming infrastructure even if all the endpoints are upgraded. For 346 details, see "Reasons to Move NAT-PT to Historic Status" [NATPT] 347 Section 3. 349 2.4. IPv6 Address Restrictions 351 [RFC2775] Section 5.1 states: 353 Note that it is a basic assumption of IPv6 that no artificial 354 constraints will be placed on the supply of addresses, given that 355 there are so many of them. Current practices by which some ISPs 356 strongly limit the number of IPv4 addresses per client will have 357 no reason to exist for IPv6. 359 Constraints on the supply of IPv6 addresses provide an incentive for 360 the deployment of NAT with IPv6. The introduction of NAT for IPv6 361 would represent a barrier to transparency, and therefore is to be 362 avoided if at all possible. 364 2.4.1. Allocation of IPv6 Addresses by Providers 366 In order to encourage deployments of IPv6 to provide oblivious 367 transport, it is important that IPv6 networks of all sizes be 368 supplied with a prefix sufficient to enable allocation of addresses 369 and sub-networks for all the hosts and links within their network. 370 Initial address allocation policy suggested allocating a /48 prefix 371 to "small" sites which should handle typical requirements. Any 372 changes to allocation policy should take into account the 373 transparency reduction that will result from further restriction. 374 For example, provider provisioning of a single /64 without support 375 for prefix delegation or (worse still) a longer prefix (prohibited by 376 [RFC4291] section 2.5.4 for non-000/3 unicast prefixes), would 377 represent a restriction on the availability of IPv6 addresses that 378 could represent a barrier to transparency. 380 2.4.2. IKEv2 382 Issues with IPv6 address assignment mechanisms in IKEv2 [RFC4306] are 383 described in [RFC4718]: 385 IKEv2 also defines configuration payloads for IPv6. However, they 386 are based on the corresponding IPv4 payloads, and do not fully 387 follow the "normal IPv6 way of doing things"... In particular, 388 IPv6 stateless autoconfiguration or router advertisement messages 389 are not used; neither is neighbor discovery. 391 IKEv2 provides for the assignment of a single IPv6 address, using the 392 INTERNAL_IP6_ADDRESS attribute. If this is the only attribute 393 supported for IPv6 address assignment, then only a single IPv6 394 address will be available. The INTERNAL_IP6_SUBNET attribute enables 395 the host to determine the sub-networks accessible directly through 396 the secure tunnel created; it could potentially be used to assign one 397 or more prefixes to the IKEv2 initiator that could be used for 398 address creation. 400 However, this does not enable the host to obtain prefixes that can be 401 delegated. The INTERNAL_IP6_DHCP attribute provides the address of a 402 DHCPv6 server, potentially enabling use of DHCPv6 prefix delegation 403 [RFC3633] to obtain additional prefixes. However, in order for 404 implementers to utilize these options in an interoperable way, 405 clarifications to the IKEv2 specification appear to be needed. 407 2.5. DNS Issues 409 2.5.1. Unique Root 411 In "IAB Technical Comment on the Unique DNS Root" [RFC2826] the 412 technical arguments for a unique root were presented. 414 One of the premises in [RFC2826] is that a common namespace and 415 common semantics applied to these names, is needed for effective 416 communication between two parties. The document argues that this 417 principle can only be met when one unique root is being used and when 418 the domains are maintained by single owners or maintainers. 420 Because [RFC4084] targets only on IP service terms and does not talk 421 about namespace issues, it does not refer to [RFC2826]. We stress 422 that for proper IP service the use of a unique root for the DNS 423 namespace is essential. 425 2.5.2. Namespace Mangling 427 Since the publication of [RFC2826] there have been reports of 428 providers implementing recursive nameservers and/or DNS forwarders 429 that replace answers that indicate that a name does not exist in the 430 DNS hierarchy with a name and an address record that hosts a web 431 service that is supposed to be useful for end-users. 433 The effect of this modification is similar to placement of a wildcard 434 in top-level domains. Although wildcard labels in top-level domains 435 lead to problems that are described elsewhere (such as "The Role of 436 Wildcards in the Domain Name System" [RFC4592]) they do not strictly 437 violate the DNS protocol. This is not the case where modification of 438 answers takes place in the middle of the path between authoritative 439 servers and the stub resolvers that provide the answers to 440 applications. 442 [RFC2826] section 1.3 states: 444 Both the design and implementations of the DNS protocol are 445 heavily based on the assumption that there is a single owner or 446 maintainer for every domain, and that any set of resources records 447 associated with a domain is modified in a single-copy serializable 448 fashion. 450 In particular the DNSSEC protocol described in "Protocol 451 Modifications for the DNS Security Extensions" [RFC4035] has been 452 designed to verify that DNS information has not been modified between 453 the moment they have been published on an authoritative server and 454 the moment the validation takes place. Since that verification can 455 take place at the application level, any modification by a recursive 456 forwarder or other intermediary will cause validation failures, 457 disabling the improved security DNSSEC is intended to provide. 459 2.6. Load Balancing and Redirection 461 In order to provide information that is adapted to the locale from 462 which a request is made or to provide a speedier service, techniques 463 have been deployed which result in packets being redirected or taking 464 a different path dependent on where the request originates. For 465 example, requests may be distributed among servers using "reverse 466 NAT" (which modifies the destination rather than the source address); 467 responses to DNS requests may be altered; HTTP "gets" may be re- 468 directed; or specific packets may be diverted onto overlay networks. 470 Provided these services are well-implemented they can provide value; 471 however, transparency reduction or service disruption can also 472 result: 474 [1] The use of "reverse NAT" to balance load among servers supporting 475 IPv6 would adversely affect the transparency of the IPv6 Internet. 477 [2] DNS re-direction is typically based on the source address of the 478 query, which may not provide information on the location of the 479 host originating the query. As a result, a host configured with 480 the address of a distant DNS server could find itself pointed to a 481 server near the DNS server, rather a server near to the host. HTTP 482 re-direction does not encounter this issue. 484 [3] If the packet filters that divert packets onto overlay networks are 485 misconfigured, this can lead to packets being misdirected onto the 486 overlay and delayed or lost if the far end cannot return them to 487 the global Internet. 489 [4] The use of anycast needs to be carefully thought out so that 490 service can be maintained in the face of routing changes. 492 3. Security Considerations 494 Several transparency issues discussed in this document (NATs, 495 transparent proxies, DNS namespace mangling) weaken existing end-to- 496 end security guarantees and interfere with the deployment of 497 protocols that would strengthen end-to-end security. 499 [RFC2775] Section 7 states: 501 The loss of transparency at the Intranet/Internet boundary may be 502 considered a security feature, since it provides a well defined 503 point at which to apply restrictions. This form of security is 504 subject to the "crunchy outside, soft inside" risk, whereby any 505 successful penetration of the boundary exposes the entire Intranet 506 to trivial attack. The lack of end-to-end security applied within 507 the Intranet also ignores insider threats. 509 Today, malware has evolved to increasingly take advantage of the 510 application-layer as a rich and financially attractive source of 511 security vulnerabilities, as well as a mechanism for penetration of 512 the Intranet/Internet boundary. This has lessened the security value 513 of existing transparency barriers and made it increasingly difficult 514 to prevent the propagation of malware without imposing restrictions 515 on application behavior. However, as with other approaches to 516 application restriction (see Section 2.1), these limitations are most 517 flexibly imposed at the edge. 519 4. IANA Considerations 521 This document has no actions for IANA. 523 5. References 525 5.1. Informative References 527 [NATPT] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Historic 528 Status", Internet draft (work in progress), draft-ietf- 529 v6ops-natpt-to-historic-00.txt, February 2007. 531 [NewArch] Clark, D. et al., "New Arch: Future Generation Internet 532 Architecture", 533 http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf 535 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 536 RFC 1958, June 1996. 538 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition 539 of the Differentiated Services Field (DS Field) in the IPv4 540 and IPv6 Headers", RFC 2474, December 1998. 542 [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, 543 "Assured Forwarding PHB Group", RFC 2597, June 1999. 545 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 546 Authentication", RFC 2747, January 2000. 548 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 549 2000. 551 [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 552 2826, May 2000. 554 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 555 Herzog, S., and R. Hess, "Identity Representation for RSVP", 556 RFC 3182, October 2001. 558 [RFC3246] Davie, B., Charny, A., Bennett, J., Benson, K., Le Boudec, 559 J., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, 560 "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, 561 March 2002. 563 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, 564 "STUN - Simple Traversal of User Datagram Protocol (UDP) 565 Through Network Address Translators (NATs)", RFC 3489, March 566 2003. 568 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 569 Host Configuration Protocol (DHCP) version 6", RFC 3633, 570 December 2003. 572 [RFC3662] Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort Per- 573 Domain Behavior (PDB) for Differentiated Services", RFC 574 3662, December 2003. 576 [RFC3724] Kempf, J. and R. Austein, "The Rise of the Middle and the 577 Future of End-to-End: Reflections on the Evolution of the 578 Internet Architecture", RFC 3724, March 2004. 580 [RFC3947] Kivinen, T., Swander, B., Huttunen, A. and V. Volpe, 581 "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 582 2005. 584 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, 585 "Protocol Modifications for the DNS Security Extensions", 586 RFC 4035, March 2005. 588 [RFC4084] Klensin, J., "Terminology for Describing Internet 589 Connectivity", RFC 4084, May 2005. 591 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 592 Architecture", RFC 4291, February 2006. 594 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 595 4306, December 2005. 597 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP", RFC 4380, 598 February 2006. 600 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 601 System", RFC 4592, July 2006. 603 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 604 Implementation Guidelines", RFC 4718, October 2006. 606 Acknowledgments 608 The authors would like to acknowledge Jari Arkko, Stephane 609 Bortzmeyer, Brian Carpenter, Spencer Dawkins, Stephen Kent, Carl 610 Malamud, Danny McPherson, Phil Roberts and Pekka Savola for 611 contributions to this document. 613 Appendix A - IAB Members at the time of this writing 615 Bernard Aboba 616 Loa Andersson 617 Brian Carpenter 618 Leslie Daigle 619 Elwyn Davies 620 Kevin Fall 621 Olaf Kolkman 622 Kurtis Lindqvist 623 David Meyer 624 David Oran 625 Eric Rescorla 626 Dave Thaler 627 Lixia Zhang 629 Authors' Addresses 631 Bernard Aboba 632 Microsoft Corporation 633 One Microsoft Way 634 Redmond, WA 98052 636 EMail: bernarda@microsoft.com 637 Phone: +1 425 706 6605 638 Fax: +1 425 936 7329 640 Elwyn B. Davies 641 Consultant 642 Soham, Cambs 643 UK 645 Phone: +44 7889 488 335 646 EMail: elwynd@dial.pipex.com 648 Full Copyright Statement 650 Copyright (C) The IETF Trust (2007). 652 This document is subject to the rights, licenses and restrictions 653 contained in BCP 78, and except as set forth therein, the authors 654 retain all their rights. 656 This document and the information contained herein are provided on an 657 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 658 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 659 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 660 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 661 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 662 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 664 Intellectual Property 666 The IETF takes no position regarding the validity or scope of any 667 Intellectual Property Rights or other rights that might be claimed to 668 pertain to the implementation or use of the technology described in 669 this document or the extent to which any license under such rights 670 might or might not be available; nor does it represent that it has 671 made any independent effort to identify any such rights. Information 672 on the procedures with respect to rights in RFC documents can be 673 found in BCP 78 and BCP 79. 675 Copies of IPR disclosures made to the IETF Secretariat and any 676 assurances of licenses to be made available, or the result of an 677 attempt made to obtain a general license or permission for the use of 678 such proprietary rights by implementers or users of this 679 specification can be obtained from the IETF on-line IPR repository at 680 http://www.ietf.org/ipr. 682 The IETF invites any interested party to bring to its attention any 683 copyrights, patents or patent applications, or other proprietary 684 rights that may cover technology that may be required to implement 685 this standard. Please address the information to the IETF at 686 ietf-ipr@ietf.org. 688 Acknowledgment 690 Funding for the RFC Editor function is provided by the IETF 691 Administrative Support Activity (IASA).