idnits 2.17.1 draft-vogt-address-translation-harmfulness-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2009) is 5401 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) ** Downref: Normative reference to an Informational RFC: RFC 2101 (ref. 'CA1997') ** Downref: Normative reference to an Informational RFC: RFC 2775 (ref. 'CA2000') -- Possible downref: Non-RFC (?) normative reference: ref. 'CA2009' -- Possible downref: Non-RFC (?) normative reference: ref. 'CH2006' -- Possible downref: Non-RFC (?) normative reference: ref. 'CH2008' ** Downref: Normative reference to an Informational RFC: RFC 3424 (ref. 'DA2002') ** Downref: Normative reference to an Informational RFC: RFC 2993 (ref. 'HA2000') -- Possible downref: Non-RFC (?) normative reference: ref. 'HU2009' -- Possible downref: Non-RFC (?) normative reference: ref. 'PE2009' -- Possible downref: Non-RFC (?) normative reference: ref. 'RO2007' ** Obsolete normative reference: RFC 5389 (ref. 'RO2008') (Obsoleted by RFC 8489) -- Possible downref: Non-RFC (?) normative reference: ref. 'RO2009' -- Possible downref: Non-RFC (?) normative reference: ref. 'UP2001' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Christian Vogt 3 Internet-Draft Ericsson 4 Expires: January 14, 2010 July 13, 2009 6 Qualifying the Harmfulness of Address Translation 7 draft-vogt-address-translation-harmfulness-03.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 14, 2010. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 Address translation is widely considered harmful because it conflicts 46 with design principles highly regarded within the Internet 47 engineering community. Still, address translation has become common 48 practice despite technical problems because it constitutes an easy- 49 to-deploy solution to a set of common operational needs. Since some 50 of these needs will continue to exist in IP version 6, there is 51 concern within the Internet engineering community about the potential 52 proliferation of harmful technology from IP version 4 to IP version 53 6. This document investigates this concern. It compares feasible 54 address translator designs with respect to the harmful impact they 55 may have, explains why the problems of address translation, as used 56 today, are to a significant extent entailed by the shortage of global 57 addresses in IP version 4, and shows how the problems can be 58 mitigated in IP version 6. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Purposes of Address Translation . . . . . . . . . . . . . . . 3 64 3. Functional Components of Address Translation . . . . . . . . . 5 65 4. Analysis of Problems and Possible Solutions . . . . . . . . . 6 66 4.1. Impact on Host Reachability . . . . . . . . . . . . . . . 6 67 4.2. Impact on Network Functioning . . . . . . . . . . . . . . 8 68 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 One of the design principles most well-heeded by the Internet 76 engineering community is that addresses have end-to-end validity and 77 do not change in packets en route. This principle is being 78 challenged [HA2000][CA2000][CA1997][DA2002] by the widespread use of 79 address translation on the Internet. Address translators rewrite 80 addresses in packets en route, typically at network borders, to 81 satisfy network operators' desire for provider independence, network 82 topology concealment, or conservation of global addresses. The 83 incentives for deploying address translation are strong, even though 84 the technique, as used today for IP version 4, has profound drawbacks 85 and hence is widely considered harmful. Since the purposes of 86 address translation are partly independent of the IP version, there 87 is concern within the Internet engineering community about the 88 potential proliferation of harmful technology from IP version 4 to IP 89 version 6. 91 This document investigates this concern by qualifying the harmfulness 92 of feasible address translator designs in IP versions 4 and 6. The 93 document makes four contributions to this end: First, it explains 94 the purposes for which address translation is used, identifies the 95 components of address translation that achieve these purposes, and 96 distinguishes two main address translator designs based on the 97 components. Second, the document compares the problems that either 98 address translator design may cause, and evaluates the cost of 99 mitigating those problems. Third, it infers that many of the 100 problems of address translation as deployed today are not due to 101 address rewriting as such. They can rather be attributed to address 102 overloading, a technique that helps conserving global addresses. 103 Fourth, the document argues that, while address overloading is 104 inevitable in IP version 4 due to the shortage of global addresses 105 [HU2009], address translation in IP version 6 does not require 106 address overloading and could hence, if designed rightly, be 107 considerably less problematic than address translation in IP version 108 4. 110 2. Purposes of Address Translation 112 Network operators frequently apply address translation to separate 113 the "local" addresses they use inside their networks from the 114 "global" addresses at which the networks are reachable from the 115 Internet. They do this for any of the following three purposes: 117 o Provider independence: Network operators desire the flexibility 118 to change providers at low cost, in order to avoid lock-in to any 119 particular provider. 121 o Topology concealment: Network operators may want to hide a 122 network's internal topology from the rest of the Internet for 123 security reasons. 125 o Global address conservation: Network operators see increasing 126 pressure to conserve global IP version 4 addresses due to the 127 imminent runout of unallocated global IP version 4 addresses. 129 A use case of address translation to achieve provider independence is 130 in networks that cannot afford, or are not eligible for, global 131 provider-independent addresses. Most residential networks and small 132 enterprise and organizational networks belong to this group. They 133 must use addresses assigned by their providers and renumber in the 134 event of a provider change. Experience [CA2009] shows that the 135 process of network renumbering often involves substantial manual 136 labor, and is hence costly and time-consuming. For example, routers 137 and servers typically have statically configured addresses and 138 therefore have to be renumbered manually. Addresses may also have to 139 be manually renumbered in applications, firewalls, and operations and 140 management systems [CH2006]. Address translation eliminates the need 141 to renumber without global provider-independent addresses. It 142 enables network operators to use local provider-independent addresses 143 internally, while retaining external reachability at global addresses 144 assigned by a provider. 146 A security-related use case of address translation is for denial-of- 147 service attack protection. This mostly applies to large enterprise 148 and organizational networks. The standard, network-topological 149 assignment of addresses provides remote hosts with a means to infer 150 the topology of a network. Attackers may use this information to 151 identify attack targets. For example, a denial-of-service attack 152 against a server may more easily be executed via a host on the 153 server's link, and such a host can typically be identified based on 154 comparing its address to the address of the server in question. 155 Firewalls can only partially mitigate this threat. Although they 156 defeat the systematic discovery of a network's internal topology 157 through address scanning, addresses obtained from communications 158 permitted by a firewall continue to reveal information about a 159 network's topology. Address translation can more thoroughly conceal 160 the internal topology of a network, by mapping local and global 161 addresses such that the topological structuring of local addresses 162 cannot be derived from global addresses. 164 The conservation of global addresses provides a third use case for 165 address translation, which is of common interest among operators of 166 IP version 4 networks. The shortage of global IP version 4 addresses 167 makes network expansion difficult, and hence can have a negative 168 impact on revenue. Address translation helps conserving global 169 addresses because it allows multiple hosts with separate local 170 addresses to share one global address. 172 3. Functional Components of Address Translation 174 In order to accomplish the purposes identified above, address 175 translation incorporates two functional components: 177 o Address rewriting: The local and global addresses of a network 178 are mapped, and swapped accordingly in packets leaving or entering 179 the network. 181 o Address overloading: Multiple local addresses are mapped onto a 182 single global address. 184 To enable demultiplexing of packets received at an overloaded global 185 address back onto the right local address, address translators that 186 use address overloading store address mappings as connection-specific 187 "disambiguation state", and they use the connection initiator's port 188 number in received packets as indexes into this state. To ensure 189 uniqueness of this port number across all connections handled by an 190 address translator, the port number may have to be translated. The 191 port mapping is then stored as part of the corresponding 192 disambiguation state. 194 Address rewriting affords provider independence and topology 195 concealment. Provider independence is achieved through the 196 decoupling of a network's local provider-independent addresses from 197 the global addresses assigned by the network's provider. The local 198 addresses consequently do not need to change if the network changes 199 providers, thus eliminating the need to renumber. Topology 200 concealment can be achieved either by overloading a single global 201 address with a large set of local addresses, or by choosing, and 202 keeping secret, a non-trivial permutation to be applied on topology- 203 significant address bits during address rewriting. 205 Simple address rewriting without address overloading requires at 206 least one global address per host. Local addresses then map one-to- 207 one onto their corresponding global addresses. To conserve global 208 addresses, it is necessary for multiple hosts to share one global 209 address. This can be achieved by combining address rewriting with 210 address overloading. 212 Given that address overloading is required for only part of the use 213 cases of address translation, two types of address translation can be 214 distinguished: 216 o One-to-one address translation, which consists of address 217 rewriting without address overloading. This achieves provider 218 independence and topology concealment. 220 o Many-to-one address translation, which combines address rewriting 221 with address overloading. This achieves global address 222 conservation in addition to provider independence and topology 223 concealment. 225 These two types of address translation will be evaluated separately 226 throughout the rest of this document. 228 4. Analysis of Problems and Possible Solutions 230 Since address translation changes the way hosts are addressed and 231 packets are forwarded, it has an impact on host reachability and 232 network functioning. The analysis below explains this impact for 233 one-to-one and many-to-one address translation, identifies problems 234 that may arise from it, and examines the feasibility and cost of 235 mitigating the problems. 237 4.1. Impact on Host Reachability 239 Since hosts behind an address translator effectively have at least 240 two addresses -- a local address and a global address --, peers must 241 have a means to discover one of these addresses that they can reach. 242 Which of the host's addresses are reachable by a given peer then 243 depends on the location of the peer. The peer must use the host's 244 global address if all paths to the host lead through an address 245 translator, and it should use the host's local address otherwise. 246 Failure to choose the right address may lead to non-reachability of 247 the host, or to sub-optimal routing, respectively. 249 Address translation must consequently be accounted for in both of the 250 two main address discovery methods -- DNS-based address discovery and 251 host-based address referrals. Authoritative DNS servers must refer 252 peers to those addresses of a host that the peers can reach, 253 preferably via an optimal path. Hosts must be able to determine 254 their global addresses for address referrals in packets they send to 255 peers, and they must recognize their global addresses in packets 256 received. The following shows that, while both address discovery 257 methods can be adapted to accommodate address translation, the cost 258 and reliability of suitable solutions in either case depends 259 significantly on the type of address translation. 261 Appropriate configuration is sufficient to enable DNS-based address 262 discovery in the presence of one-to-one address translation. Since 263 without address overloading, a host's local and global addresses are 264 both stable and unique, both can be associated with the host's name 265 in the DNS through configuration of the authoritative DNS servers. 267 For many-to-one address translation, DNS-based address discovery is 268 more expensive to enable. Since a host is reachable at a global 269 address only after prior establishment of disambiguation state in an 270 address translator, extra functionality is necessary in authoritative 271 DNS servers to initiate this state establishment prior to referring a 272 peer to the global addresses of a host. This functionality can be 273 either in hosts or in authoritative DNS servers. Standard methods 274 [UP2001][CH2008] exist for hosts to establish disambiguation state. 275 Those define an interface for address translators through which 276 applications can reserve particular global addresses and port 277 numbers. Disambiguation state establishment by authoritative DNS 278 servers has been proposed in [PE2009]. The proposal calls for 279 authoritative DNS servers to establish in a host's address translator 280 a mapping between the host's local and global addresses when 281 receiving a DNS query for the host's name, and for the address 282 translator to bind this mapping to the peer's address and port number 283 when receiving the first packet from the peer. 285 Host-based address referrals require special host support to function 286 in the presence of address translation. Hosts must be enabled to 287 discover their global addresses, and they must use and recognize 288 their global addresses in referrals they send and receive. 289 Furthermore, hosts behind a many-to-one address translator may have 290 to establish demultiplexing state in the address translator prior to 291 sending an address referral. This is necessary when the address 292 referral itself is sent via an overlay instead of to the peer 293 directly, and hence cannot establish the necessary demultiplexing 294 state in the address translator. Applications that may send address 295 referrals via overlays include those that use server-assisted peer- 296 to-peer protocols or the Session Initiation Protocol. 298 While the use and recognition of global addresses is specific to the 299 application protocol, standard methods [RO2007][RO2009][RO2008] 300 exists for hosts to discover their global addresses. These methods 301 were designed for many-to-one address translation, as it is the 302 prevailing address translation type in the existing Internet, and 303 they are hence appropriate to establish disambiguation state in 304 address translators. They discover a global address by inquiring of 305 infrastructure what a packet's source address looks like after 306 translation. 308 Although the existing solutions to enable address discovery in the 309 presence of many-to-one address translation would likewise apply to 310 one-to-one address translation, solutions can be simpler in the case 311 of one-to-one address translation. Since one-to-one address 312 translation does not overload addresses, address discovery methods 313 for one-to-one address translation do not have to establish 314 disambiguation state in address translators. For example, a 315 simplified method for hosts to discover their global addresses is for 316 access routers to announce address mapping rules, based on which 317 hosts derive their global addresses given their local addresses. In 318 the case where addresses are translated by swapping their prefix, a 319 mapping rule could be as simple as a pair of local and global address 320 prefixes. This discovery method would be comparable to the existing 321 practice of auto-configuring addresses based on on-link address 322 prefixes announced by access routers. 324 Both DNS-based and referral-based address discovery are consequently 325 more expensive and less reliable for many-to-one address translation 326 than they can be for one-to-one address translation. Apart from 327 requiring extra complexity, many-to-one address translation assumes 328 that connection initiation happens shortly after address discovery 329 due to the establishment of disambiguation state during address 330 discovery. This assumption is not always the satisfied: 331 Disambiguation state must expire when found unused to make room for 332 new connections. So if the first packet from a connection arrives at 333 the address translator after the corresponding disambiguation state 334 has expired, connection initiation fails. For the same reason, many- 335 to-one address translation does not allow peers to be configured with 336 the global address of a host, since the necessary disambiguation 337 state would likely be unavailable at the time the peer initiates a 338 connection to this address. 340 4.2. Impact on Network Functioning 342 The addition of new components to a network, such as in the form of 343 address translators, can impact the functioning of the network. Two 344 potential problems that may arise are the loss of generic forwarding 345 support for all connection types, and the loss of network robustness. 346 Forwarding support can be reduced to certain connection types if the 347 new component relies on connection-specific properties in packets. 348 This is the case for many-to-one address translators, which rely on 349 modifiable port numbers. Packets without port numbers are dropped, 350 and so are packets with port numbers that are not modifiable due to 351 encryption and authentication. Network robustness can be reduced if 352 the new component constitues a single point of failure. This is the 353 case for both types of address translators. Address translators 354 perform a function that connections depend on, and hence, if not 355 provisioned redundantly, limit a network's ability to reroute traffic 356 in the event of failures. The following shows that, while both 357 problems can be effectively mitigated, the cost and reliability of 358 suitable solutions for either problem depend significantly on the 359 type of address translation. 361 Loss of generic forwarding support for all connection types is a 362 problem that is peculiar to many-to-one address translation, since 363 address overloading requires packets to carry port numbers modifiable 364 by an address translator for use as indexes into disambiguation 365 state. One-to-one address translation does not limit forwarding 366 support because it does not rely on port numbers or other connection- 367 specific properties in packets. 369 A common method to retain support for all connection types in many- 370 to-one address translation is to tunnel packets end-to-end in an 371 extra layer of UDP. This enables connections without accessible port 372 numbers to pass through many-to-one address translators, because the 373 new UDP header in packets adds the port numbers needed by the address 374 translators. Unfortunately, UDP tunneling cannot be expected to 375 always be available. It requires support at both ends of a 376 connection, independent of whether the address of the peer is 377 translated or not. So if either the host which address is being 378 translated or its peer does not support UDP tunneling, connections 379 without modifiable port numbers cannot pass through many-to-one 380 address translators. 382 To avoid loss of network robustness due to the deployment of address 383 translators, one must ensure that address translators do not 384 constitute a single point of failure. Depending on the type of 385 address translation deployed, this may require one or both of the 386 following: 388 o Redundancy of address translators: Redundant provisioning of 389 address translators on alternative paths is necessary to protect 390 against failure of address translators. It enables failover of 391 connections from one path to another. 393 o Refreshes of disambiguation state: Disambiguation state in many- 394 to-one address translators must be refreshed periodically 395 throughout the lifetime of the corresponding connection to prevent 396 premature disposal of the disambiguation state. Idle connections 397 may otherwise be unable to resume. 399 Redundancy is straightforward to provision for one-to-one address 400 translators. Since they operate without connection-specific state, 401 redundantly provisioned one-to-one address translators can substitute 402 for each other without prior synchronization, and hence can be 403 deployed independently on alternative paths. On the other hand, 404 redundantly provisioned many-to-one address translators must be 405 continuously synchronized because the disambiguation state they 406 maintain is connection-specific. 408 Refreshes of disambiguation state are needed for many-to-one address 409 translators. Existing refresh methods [RO2008][RO2007] either ensure 410 that connections periodically exchange "keep-alive" packets end to 411 end, or they introduce infrastructure with which hosts behind address 412 translators can exchange such packets. Unfortunately, neither 413 refresh method can be expected to always be available due to its 414 prerequisites. The methods either require support at both ends of a 415 connection, or they require special infrastructure plus support in 416 the host which address is being translated. If none of these 417 prerequisites is met, connections that go idle temporarily may be 418 unable to resume. Disambiguation state refreshes are not necessary 419 for one-to-one address translation, since this functions without 420 disambiguation state. 422 5. Conclusion 424 This document has shown that the harmfulness of address translation 425 depends significantly on whether or not global addresses are 426 overloaded with mappings to multiple local addresses. Although 427 address translation with and without address overloading can have an 428 impact on host reachability and network functioning, resulting 429 problems have been found to be especially intractable and expensive 430 to solve if address overloading is used. 432 Impacts on host reachability in one-to-one address translation, which 433 functions without address overloading, can be compensated for by 434 appropriate configuration of authoritative DNS servers and special 435 support for address referrals in hosts behind an address translator. 436 Many-to-one address translation, which does perform address 437 overloading, in addition requires the hosts and authoritative DNS 438 servers to interact with address translators. This is necessary to 439 establish disambiguation state that will subsequently permit an 440 address translator to demultiplex packets received at an overloaded 441 global address back onto the right local address. Impacts on network 442 functioning in one-to-one address translation can be compensated for 443 by provisioning address translators redundantly. Many-to-one address 444 translation in addition requires synchronization of disambiguation 445 state across redundantly provisioned address translators, periodic 446 state refreshes, and UDP tunneling of connections without the 447 modifiable port numbers that address translators need as indexes into 448 their disambiguation state. 450 Compensating for the impacts of address translation is hence 451 significantly more expensive, both in deployment and in 452 administration, when address translation is many-to-one compared to 453 when it is one-to-one. The higher complexity involved furthermore 454 constitutes a source of potential failure on its own. And extra 455 requirements for hosts and their peers reduce the likelihood that 456 sufficient functionality will be available when needed. 458 The advantageousness of one-to-one address translation over many-to- 459 one address translation naturally leads to the question whether the 460 former can satisfy the demand for address translation, as it has 461 become apparent through the wide deployment of address translators in 462 today's Internet. Clearly, this depends on the availability of 463 global addresses. One-to-one address translation, which requires one 464 global address per local address, is unsuitable for IP version 4, 465 where the shortage of global addresses necessitates the use of 466 address overloading. For IP version 6, however, one-to-one address 467 translation is suitable, as the sufficient number of global addresses 468 here makes address overloading dispensable. Address translation in 469 IP version 6 could hence, if designed without address overloading, be 470 considerably less harmful than address translation in IP version 4. 472 6. Acknowledgment 474 The author would like to thank Gonzalo Camarillo, Brian Carpenter, 475 Tony Li, Joel Halpern, James Kempf, Alan Kavanagh, Suresh Krishnan, 476 Zoltan Turanyi, and Wassim Haddad for their reviews of this document 477 and their valuable comments. 479 This document was generated using the xml2rfc tool. 481 7. References 483 [CA1997] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address 484 Behaviour Today", RFC 2101, February 1997. 486 [CA2000] Carpenter, B., "Internet Transparency", RFC 2775, 487 February 2000. 489 [CA2009] Carpenter, B., Atkinson, Ran., and H. Flinck, "Renumbering 490 Still Needs Work", IETF Internet draft (work in progress), 491 Februray 2009. 493 [CH2006] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things 494 to Think About When Renumbering an IPv6 Network", IETF 495 Internet draft (work in progress), September 2006. 497 [CH2008] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping 498 Protocol (NAT-PMP)", IETF Internet draft (work in 499 progress), April 2008. 501 [DA2002] Daigle, L., "IAB Considerations for Unilateral Self-Address 502 Fixing (UNSAF) Across Network Address Translation", 503 RFC 3424, November 2002. 505 [HA2000] Hain, T., "Architectural Implications of NAT", RFC 2993, 506 November 2000. 508 [HU2009] Huston, G., "IPv4 Address Report", online 509 at http://www.potaroo.net/tools/ipv4, July 2009. 511 [PE2009] Perkins, C., "Translating IPv4 to IPv6 Based on Source IPv4 512 Address", IETF Internet draft (work in progress), 513 February 2009. 515 [RO2007] Rosenberg, J., "Interactive Connectivity Establishment 516 (ICE): A Protocol for Network Address Translator (NAT) 517 Traversal for Offer/Answer Protocols", IETF Internet 518 draft (work in progress), October 2007. 520 [RO2008] Rosenberg, J., Mahy, R., and D. Wing, "Session Traversal 521 Utilities for NAT (STUN)", RFC 5389, October 2008. 523 [RO2009] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 524 Relays around NAT (TURN): Relay Extensions to Session 525 Traversal Utilities for NAT (STUN)", IETF Internet 526 draft (work in progress), July 2009. 528 [UP2001] "UPnP Forum Internet Gateway Device Protocol", 529 November 2001. 531 Author's Address 533 Christian Vogt 534 Ericsson Research 535 200 Holger Way 536 San Jose, CA 95134 537 United States 539 Email: christian.vogt@ericsson.com