idnits 2.17.1 draft-elmalki-sipping-3gpp-translator-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 357 has weird spacing: '...erefore we ar...' -- 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 (December 3, 2003) is 7442 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 3574 (ref. '1') -- No information found for draft-ietf-v6ops-analysis - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3314 (ref. '3') ** Obsolete normative reference: RFC 2327 (ref. '6') (Obsoleted by RFC 4566) -- Possible downref: Normative reference to a draft: ref. '7' -- No information found for draft-rosenberg-midcom - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' ** Downref: Normative reference to an Experimental RFC: RFC 3102 (ref. '9') ** Obsolete normative reference: RFC 3489 (ref. '10') (Obsoleted by RFC 5389) == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-00 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-00 == Outdated reference: A later version (-02) exists of draft-ietf-sipping-session-policy-req-00 -- Possible downref: Normative reference to a draft: ref. '13' ** Obsolete normative reference: RFC 3525 (ref. '14') (Obsoleted by RFC 5125) ** Downref: Normative reference to an Informational RFC: RFC 3303 (ref. '15') ** Obsolete normative reference: RFC 2766 (ref. '16') (Obsoleted by RFC 4966) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Karim El Malki 2 INTERNET-DRAFT Gonzalo Camarillo 3 Expires: June 2004 Ericsson 4 Jasminko Mulahusic 5 Mikael Lind 6 TeliaSonera 7 Hesham Soliman 8 Flarion 10 December 3, 2003 12 IPv6-IPv4 Translation mechanism for SIP-based services in 13 Third Generation Partnership Project (3GPP) Networks 14 16 Status of this memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is an individual submission to the IETF. Comments 37 should be directed to the authors. 39 Abstract 41 There have been discussions on the v6ops mailing list and at IETF 42 meetings regarding the suitability of translators (i.e. NAT-PT) as 43 mechanisms for IPv4 to IPv6 transition. It has often been stated that 44 NAT-PT is not a mechanism to be recommended in general to solve the 45 IPv6-IPv4 transition problem. There have also been discussions 46 regarding special scenarios where some form of translators could be 47 deployed if their use is documented appropriately. The aim of this 48 draft is to document the rationale for using translators in 3GPP 49 (Third Generation Partnership Project) networks for IPv6-only SIP- 50 based IP Multimedia Subsystem (IMS) services and to describe a 51 solution to the problem. 53 TABLE OF CONTENTS 55 1. Introduction.....................................................2 56 2. 3GPP Network Requirements, SIP Requirements and constraints......3 57 3. Analysis of current SIP solutions for IPv6/v4 transition.........4 58 3.1 SIP Layer....................................................4 59 3.2 Media Layer..................................................4 60 4. IPv4/v6 Transition Solution for IMS..............................5 61 4.1 Reference Architecture for the solution......................6 62 4.1.1 SIP Edge Proxy...........................................6 63 4.1.2 IP Address and Port Mapper (IPAPM).......................7 64 4.2 IMS Generated INVITE.........................................7 65 4.2.1. Session Policies Usage..................................9 66 4.3 Internet Generated INVITE...................................10 67 4.4 IPAPM Operation and State Installation......................11 68 4.5 Private Addressing in IPv4 User Agent.......................12 69 4.5.1 IMS Generated INVITE....................................13 70 4.5.2 Internet (private IPv4) Generated INVITE................15 71 4.6 Examples....................................................18 72 5. Security Considerations.........................................18 73 6. IANA Considerations.............................................18 74 7. Contributors & Acknowledgements.................................18 75 8. Authors' Addresses..............................................18 76 9. References......................................................19 78 1. Introduction 80 The Third Generation Partnership Project (3GPP) has adopted IPv6 as 81 the protocol to be used to deploy new IP multimedia subsystem (IMS) 82 services such as messaging or voice and video over IP. 3GPP networks 83 have different constraints from other types of networks, therefore it 84 is important to consider the special requirements which make 85 translators an attractive solution for transitioning 3GPP networks. 86 The 3GPP scenarios and analysis drafts [1][2] describe the 3GPP 87 network and transition mechanisms which could be used in such 88 networks. These should be used as reference together with RFC 3114 89 [3] when reading this document. The aim of this draft is to document 90 the reasons why translation can be an attractive mechanism in 3GPP 91 networks and to formulate a solution to the 3GPP IPv6-to-IPv4 92 translation problem. This solution considers the impacts on SIP, 93 which is used in the IPv6-only 3GPP IMS, and aims to reuse solutions 94 and approaches from the SIP and SIPPING WGs. 96 2. 3GPP Network Requirements, SIP Requirements and constraints 98 A 3GPP host communicates using PDP Contexts, which are layer-2 point- 99 to-point communication channels between 3GPP hosts and the 3GPP 100 network. Before being able to send any IP packets, a host needs to 101 activate a PDP Context. It is during the PDP context activation that 102 a host normally acquires an IP address. One of the special 103 characteristics of PDP Contexts is that a PDP context can only be 104 used to carry IPv4 or IPv6 packets but not both. The "PDP Type" which 105 is requested by the 3GPP host when establishing a PDP Context will be 106 either set to "IPv4" or "IPv6". 108 The 3GPP IMS (IP Multimedia Subsystem) will be used to provide new 109 multimedia services (e.g. messaging, video, voice, audio) to 3GPP 110 hosts. In order to access IMS services the 3GPP host uses a PDP 111 Context of type IPv6 (we will call this an IPv6 PDP Context from now 112 on). The IMS is based on SIP [4]. 114 One essential requirement in 3GPP networks is that 3GPP hosts using 115 IMS applications over IPv6 must be able to communicate with non-3GPP 116 IPv4 hosts (e.g. on Internet) that use SIP applications. In order to 117 achieve this, some kind of translation must be available between 3GPP 118 network realms and the Internet. 120 Another important requirement is to minimize the number of active PDP 121 Contexts a host has on any given time. A reason for this is that 122 there are practical constraints on the number of PDP Contexts which a 123 3GPP host may establish. If a host uses many PDP Contexts it consumes 124 extra resources in the 3GPP network. That is because each PDP Context 125 requires a state to be maintained in the 3GPP network. In addition, 126 each PDP Context would normally require radio signaling and a new 127 radio channel to be established to the 3GPP host. Therefore each 128 additional PDP Context also consumes extra radio resources required 129 to establish the radio channel. For these reasons, any transition 130 solution should support the case where a 3GPP host utilises only one 131 IPv6 PDP Context, without the need to activate additional IPv4 PDP 132 Contexts. 134 As specified in [4], media parameters such as transport addresses are 135 carried in the body of SIP message bodies. These bodies may be 136 end-to-end integrity protected, therefore it may not possible to 137 modify them en-route. In general the SIP WG discourages the use of 138 intermediaries which alter the contents of SIP message bodies. This 139 is a very important consideration for a 3GPP Translator solution. 141 Also, it is preferred to limit impacts to the installed IPv4 user 142 agent base and aim for a solution where most of the changes are made 143 to the 3GPP user agent and IMS. That is because it will obviously be 144 harder to require changes to SIP user agents on Internet than to 145 require new functionality in 3GPP user agents which still have to be 146 deployed. 148 3. Analysis of current SIP solutions for IPv6/v4 transition 150 A complete solution for IPv6/v4 transition needs to handle both the 151 SIP layer and the media layer (e.g. RTP). Vanilla SIP can handle 152 heterogeneous IPv6/v4 networks at the SIP layer as long as proxies 153 are properly configured. However, end-points using different address 154 spaces need to implement extensions in order to exchange media 155 between them. These extensions affect the session description 156 protocol in use (e.g. SDP) and the SIP offer/answer state machine. 158 3.1 SIP Layer 160 A SIP user agent is typically reachable through the SIP server that 161 handles its domain. If the publicly available SIP URI for a 162 particular user is sip:user@example.com, requests sent to that user 163 will be routed to the SIP server at example.com. The proxy or user 164 agent sending the request will perform a DNS lookup for example.com 165 in order to obtain the IP address of the SIP server. Therefore, if 166 the SIP server of a domain is a dual-stack proxy that supports IPv4 167 and IPv6, it will be able to receive requests from IPv4-only and from 168 IPv6-only hosts. Then, the SIP server will relay the request to the 169 user agent using the address provided by the user agent at 170 registration time (which could be IPv4 or IPv6). 172 The SIP server that receives a request using IPv6 and relays it to 173 the user agent using IPv4, or vice versa, needs to remain in the path 174 traversed by subsequent requests between both user agents. Therefore, 175 such a SIP server should always be configured to Record-Route in that 176 situation. 178 3.2 Media Layer 180 SIP establishes media sessions using the offer/answer model [5]. One 181 end-point, the offerer, sends a session description (the offer) to 182 the other end-point, the answerer. The offer contains all the media 183 parameters needed to exchange media with the offerer; codecs, 184 transport addresses, protocols to transfer media, etc. 186 When the answerer receives an offer, it elaborates an answer and 187 sends it back to the offerer. The answer contains the media 188 parameters that the answerer is willing to use for that particular 189 session. Offer and answer are written using a session description 190 protocol. The most widespread session description protocol at present 191 is SDP [6] and 3GPP IMS uses SDP, thus we will focus on it. Session 192 descriptions are transmitted end-to-end and are not modified by 193 proxies. In this document we sometimes use SIP INVITEs and 200 (OK) 194 Responses for simplicity to identify the offer and response model, 195 but it should be noted that support for other SIP messages carrying 196 the SDP offer/answer is implied. 198 Vanilla SDP only allows an end-point to provide a single IP address 199 per media stream. However, using the ALT extension [7] it is possible 200 to include several IP addresses in the description of a media stream. 201 Using ALT, an offerer can provide, for instance, an IPv4 and an IPv6 202 address for a particular media stream. The answerer will choose the 203 address of the type it supports or prefers. 205 An end-point can use several mechanisms to obtain the different 206 addresses to be placed in its ALT group in its session description. 207 It can be a dual-stack host that configures IPv4 and IPv6 addresses 208 or it can use protocols like TURN [8], RSIP [9], STUN [10] or TEREDO 209 [11] to discover extra IP addresses which it is reachable at. 211 ICE [12] describes how to couple address discovery procedures with 212 the offer/answer model. ICE is useful when the user agents are in 213 different private addresses spaces, where more than one offer/answer 214 exchange is needed to discover a reachable address for the peer. 216 4. IPv4/v6 Transition Solution for IMS 218 As mentioned previously, one important requirement for 3GPP networks 219 is that 3GPP hosts running SIP-based IMS applications over IPv6 must 220 be able to communicate with IPv4 SIP hosts on the Internet. This 221 requires the following to be performed at the borders of the 3GPP 222 network: 224 1. Ensure that the IP addresses in SDP offers/answers are of the 225 appropriate type for a communication to proceed. 227 2. Enable media communication by performing IP address and port 228 mapping of the media traffic (e.g. RTP/UDP) exchanged between the 229 IPv6 IMS user agent and the non-3GPP IPv4 user agent. 231 3. Ensure that IP version 4 is used for transport of SIP messages 232 between the IMS domain and external IPv4 domains. 234 IMS user agents need a means to obtain a public IPv4 address plus a 235 port number to place in their session descriptions in order to 236 receive media and an IPv6 address plus port number to send media to. 237 For incoming (to IMS) media packets, the public destination IPv4 238 address plus port number will be mapped to the 3GPP user agent's own 239 IPv6 address plus port number at the edge of the 3GPP network. For 240 outgoing (from IMS) media packets, the destination IPv6 address plus 241 port number will be mapped to the public IPv4 address plus port 242 number of the non-3GPP IPv4 user agent. 244 A solution to these problems is given in the following sections. 246 4.1 Reference Architecture for the solution 248 We introduce two network elements: the SIP Edge Proxy and the IP 249 Address and Port Mapper (IPAPM). The reference architecture is shown 250 in Figure 1. 252 ------- ------ 253 | IMS | | SIP | 254 IPv6 | SIP | | Edge | -------- 255 ---| proxy | | Proxy| IPv4| | 256 ------ ------ / | (CSCF)|--| |-----| | 257 | | | | / ------- ------ | | 258 | 3GPP | | GGSN |/ IPv6 | | | 259 | IPv6 |=============| |\ | | IPv4 | 260 | host | IPv6-only | | \ ------- | Net | 261 | | PDP Context | | \ IPv6 | | IPv4 | | 262 ------ ------ -----------| IPAPM |-------| | 263 | | | | 264 ------- -------- 266 Figure 1 - SIP Edge Proxy and IP Address/Port Mapper (IPAPM) in the 267 3GPP Network 269 We will refer to "Incoming" SIP messages as IPv4 messages going from 270 an IPv4 host towards the SIP Edge Proxy, while "Outgoing" messages 271 are from the SIP Edge Proxy towards the IPv4 host. 273 Note that a user agent on the IPv4 network (Internet) may support 274 receiving and transmitting media over both IPv4 and IPv6 (dual-stack) 275 or only over IPv4. This is independent of whether the user agent is 276 using dual-stack or IPv4-only SIP proxies and registrars. Therefore 277 an intermediate node cannot deduce the media IP-type capability of a 278 user agent from these characteristics. 280 4.1.1 SIP Edge Proxy 282 The SIP Edge Proxy will naturally be a dual-stack node with both IPv6 283 and public IPv4 addresses configured on its interfaces. It will 284 perform Record-Routing, as described in Section 3.1 and will be in 285 the path of all the requests coming from and going to the IPv4 286 network. 288 The SIP Edge Proxy must store and manage a local pool of IPv6 and 289 public IPv4 addresses which have been previously configured on the 290 interfaces of an IPAPM node. The SIP Edge Proxy may have multiple 291 IPv6/v4 address pools each belonging to different physical IPAPM 292 nodes. This would enable the SIP Edge Proxy to perform load sharing 293 or utilise IPAPMs which are best placed for the communication (e.g. 294 by comparing IP addresses). 296 Note that the SIP Edge Proxy is a logical entity which may be 297 implemented as a part of other SIP proxies. The IPv4 DNS records for 298 the domain will point to the SIP Edge Proxy and all the outgoing 299 requests with an IPv4 address as the SIP next-hop will be routed to 300 it. Since in the 3GPP model it is the S-CSCF proxy which receives all 301 incoming SIP messages to the IMS domain, the SIP Edge Proxy could be 302 integrated in that node. 304 4.1.2 IP Address and Port Mapper (IPAPM) 306 The IPAPM (IP Address and Port Mapper) is needed because the 3GPP 307 IPv6-only host and the IPv4-only host cannot send media traffic to 308 each other due to IP layer incompatibility. The IPAPM will simply 309 perform the IP address mapping for the appropriate IP address, port, 310 protocol tuples on both incoming and outgoing media (RTP) packets. 311 The SIP Edge Proxy will install and delete this bidirectional state 312 in the IPAPM (see 4.4). It should be noted that the IPAPM operation 313 is similar to that of a bidirectional NA(P)T-PT [16] after having 314 installed state for a particular connection. That is, the translation 315 algorithm (SIIT) is the same. Hence, if needed, an IPAPM device may 316 also operate as a normal NA(P)T-PT for a specific limited set of 317 (non-IMS) application traffic, but this is not necessarily 318 recommended and is outside the scope of this draft (see [2]). There 319 are also important differences between IPAPM and NAT-PT, including 320 the absence of Application Layer Gateways (ALGs) and the method used 321 to install state in the translator. Therefore the use of IPAPMs 322 avoids many of the problems normally associated with NAT-PT. 324 4.2 IMS Generated INVITE 326 When a 3GPP user agent sends an SDP offer (e.g. in an INVITE) to an 327 Internet user agent with only IPv6 addresses in the SDP, the Internet 328 user may be dual-stack (in which case there should be no address 329 incompatibility problem) or it may be IPv4-only. If it is IPv4-only, 330 the 3GPP user agent will get a final error response back. This final 331 error response will typically be a 488 (Not acceptable here) response 332 with a warning header with warn code 300 (Incompatible network 333 protocol). 335 This response will traverse the SIP Edge Proxy, which will locally 336 assign a public IPv4 address and port number to the IPv6 3GPP user 337 agent for this session (Call-id, To tag, From tag) from a local pool 338 of addresses/ports. The unique address/port combination should stay 339 allocated to the same 3GPP IPv6 user agent for the duration of the 340 SIP session. The SIP Edge Proxy must install this mapping state 341 information in the IPAPM when it also obtains the 3GPP user's IPv6 342 address (in the successive SDP offer, see below). 344 The SIP Edge Proxy should add the assigned IPv4 media address and 345 port assigned to the 3GPP user agent to the 488 (Not Acceptable Here) 346 response. Note that the SIP Edge Proxy should not modify the contents 347 of SDP, but append the IPv4 media address to the message using 348 session policies [13]. This is in line with what is described in 349 [13], which recommends against SDP editing and puts requirements to 350 achieve the same goal using a better solution. Therefore this work in 351 the SIPPING WG addresses our problem and its completion should be 352 encouraged. The SIP Edge Proxy utilises session policies to append 353 the assigned IPv4 media address and port to the response. The IPv4 354 address must be public. The 3GPP user agent will, upon reception of 355 this response, generate a new SDP offer that contains both the IPv4 356 and the original IPv6 addresses and uses ALT [7]. This SDP offer will 357 traverse the SIP Edge Proxy. Therefore we are effectively adding a 358 requirement to [13] that the solution should allow proxies to request 359 the use of certain IP addresses and ports in SDP offers and answers. 360 The SIP Edge Proxy can now install a bidirectional mapping in the 361 IPAPM between the 3GPP user's IPv6 media address/port and the 362 assigned public IPv4 address/port for the session. 364 When the IPv4-only user agent sends back a SDP answer containing at 365 least a public IPv4 address/port pair, the SIP Edge Proxy locally 366 assigns an IPv6 address and port to the IPv4 user agent from a local 367 pool of addresses/ports. The unique address/port combination should 368 stay allocated to the same IPv4 user agent for the duration of the 369 SIP session. The SIP Edge Proxy must install this bidirectional 370 mapping state information in the IPAPM. Then the SIP Edge Proxy 371 appends this IPv6 address plus port number to the SDP answer. As 372 mentioned previously, SDP editing should be avoided and a solution 373 satisfying the requirements in [13] should be used. This IPv6 address 374 and port will be used by the 3GPP IPv6-only user agent to send media 375 to the IPv4 user agent. The IPAPM will map this IPv6 address/port 376 pair to the IPv4 address contained in the SDP answer. Media can now 377 flow in both directions through the IPAPM. In this paragraph we have 378 effectively added a requirement to [13] that the solution should 379 allow proxies to request the use of certain IP addresses and ports as 380 destination of the media flows. 382 3GPP UA 3GPP SIP SIP Edge Internet Internet 383 IPv6 Proxies Proxy SIP Proxy IPv4 UA 384 | | | | | 385 |-------------->|-------------->|------------->|------------->| 386 | INVITE Offer | INVITE Offer | INVITE Offer | INVITE Offer | 387 | (IPv6) | (IPv6) | (IPv6) | (IPv6) | 388 | | | | | 389 | | (A)|<-------------|<-------------| 390 |<--------------|<--------------| Error | Error | 391 | Error | Error | | | 392 | [IPv4 ext.] | [IPv4 ext.] | | | 393 | | | | | 394 |-------------->|-------------->|(B) | | 395 | INVITE Offer | INVITE Offer |------------->|------------->| 396 | (IPv4, IPv6) | (IPv4, IPv6) | INVITE Offer | INVITE Offer | 397 | | | (IPv4, IPv6) | (IPv4, IPv6) | 398 | | | | | 399 | | (C)|<-------------|<-------------| 400 |<--------------|<--------------| OK (IPv4) | OK (IPv4) | 401 | OK (IPv4) | OK (IPv4) | | | 402 | [IPv6 ext.] | [IPv6 ext.] | | | 403 | | | | | 404 |-------------->|-------------->|------------->|------------->| 405 | ACK | ACK | ACK | ACK | 406 | | | | | 408 Figure 2 - IMS-Generated INVITE Messaging Diagram 409 (Public IPv4 Address on Internet UA) 411 (A) - SIP Edge Proxy locally assigns a public IPv4 addr/port to the 412 3GPP UA and communicates this to the 3GPP UA by inserting 413 this information in the [IPv4 ext.] 414 (B) - SIP Edge Proxy installs mapping in IPAPM for 3GPP UA IPv6 415 addr/port to locally assigned IPv4 addr/port (IPv4), see (A). 416 (C) - SIP Edge Proxy installs mapping in IPAPM for Internet UA IPv4 417 addr/port to locally assigned IPv6 addr/port (in [IPv6 ext.]) 419 (IPvx) - Represents the IPvx SDP media information (addr/port) 420 [IPvx ext.] - Represents a special extension containing the IPvx 421 address/port pair appended to (but separate from) the 422 SDP message. 424 4.2.1. Session Policies Usage 426 In order to install the IPv4 to IPv6 mapping for a session in the 427 IPAPM, the SIP Edge Proxy needs to know the IP addresses of both user 428 agents, the 3GPP IMS terminal and the Internet user agent. If we 429 could assume that both user agents supported session policies, they 430 could use them to inform the SIP Edge Proxy about their respectives 431 addresses. However, at present, most of the SIP user agents on the 432 Internet do not support session policies. That is why the SIP Edge 433 proxy relies on parsing the SDP of the Internet user agent. This is 434 possible because the IMS does not allow other session description 435 formats than SDP and does not allow SDP encryption (although 436 integrity protection is allowed). 438 4.3 Internet Generated INVITE 440 In order to limit the impact on IPv4 user agents on Internet, the SIP 441 Edge Proxy will perform a different procedure in the case of SDP 442 offers (e.g. INVITE) sent by IPv4 user agents with at least a public 443 IPv4 address in their session descriptions. 445 Upon receiving this offer, the SIP Edge Proxy will parse the SDP and 446 establish that the IPv4 user agent does not currently have IPv6 447 addresses but has at least one public IPv4 address. The SIP Edge 448 Proxy should then locally assign an IPv6 address plus port to the 449 IPv4 user agent for this session. At this point the SIP Edge Proxy 450 has enough information to install a bidirectional mapping in the 451 IPAPM between the IPv4 user agent's public IPv4 media address/port 452 and the IPv6 address/port assigned to it for the session. It will 453 also allocate an IPv4 public address/port to the 3GPP IPv6 user 454 agent, even though it cannot establish the binding until it obtains 455 the 3GPP IPv6 user agent's media address in the SDP answer. The SIP 456 Edge Proxy should then append the IPv6 media address and port, 457 assigned to the IPv4 user agent, and the IPv4 media address and port, 458 assigned to the 3GPP IPv6 user agent, to the SDP offer (e.g. INVITE). 459 To achieve this it will not do SIP editing but will use the mechanism 460 already described in 4.2 in relation to [13]. 462 The 3GPP IPv6-only user agent will receive the SDP offer (e.g. 463 INVITE) and process the appended IPv6 and IPv4 address/port pairs. 464 The 3GPP user agent will use the appended IPv6 address/port to send 465 media to the IPv4 user agent. It will then send the SDP answer (e.g. 466 200 OK). The SDP answer will contain both its newly assigned IPv4 467 address/port (appended to the offer) and its IPv6 address/port and 468 uses ALT [7]. 470 The SDP answer will traverse the SIP Edge Proxy. At this point the 471 SIP Edge Proxy can install the bidirectional mapping state in the 472 IPAPM between the 3GPP user agent's IPv6 address and the public IPv4 473 address/port it was locally assigned earlier (which is also contained 474 in the SDP answer itself). The IPv4 user agent will use the public 475 IPv4 address and port in the SDP answer to send media to the 3GPP 476 IPv6 user agent. Media can now flow in both directions through the 477 IPAPM. 479 3GPP UA 3GPP SIP SIP Edge Internet Internet 480 IPv6 Proxies Proxy SIP Proxy IPv4 UA 481 | | | | | 482 | | (D)|<-------------|<-------------| 483 |<--------------|<--------------| INVITE Offer | INVITE Offer | 484 | INVITE Offer | INVITE Offer | (IPv4) | (IPv4) | 485 | (IPv4) | (IPv4) | | | 486 | [IPv6 ext.] | [IPv6 ext.] | | | 487 | [IPv4 ext.] | [IPv4 ext.] | | | 488 | | | | | 489 |-------------->|-------------->|(E) | | 490 |OK (IPv4, IPv6)|OK (IPv4, IPv6)|------------->|------------->| 491 | | |OK (IPv4,IPv6)|OK (IPv4,IPv6)| 492 | | | | | 493 |<--------------|<--------------|<-------------|<-------------| 494 | ACK | ACK | ACK | ACK | 496 Figure 3 - Internet-Generated INVITE Messaging Diagram 497 (Public IPv4 Address on Internet UA) 499 (D) - SIP Edge Proxy installs mapping in IPAPM for Internet UA IPv4 500 address/port to locally assigned IPv6 addr/port (in [IPv6 501 ext.]) SIP Edge Proxy also locally assigns IPv4 addr/port to 502 3GPP UA (in IPv4 ext.) but does not install IPAPM mapping. 503 (E) - SIP Edge Proxy installs mapping in IPAPM between 3GPP UA IPv6 504 addr/port and previously assigned IPv4 addr/port (in 505 [IPv4 ext.]) 507 4.4 IPAPM Operation and State Installation 509 The installation of state in the IPAPM is intimately coupled with the 510 generation of session descriptions (offers and answers) by the user 511 agent. 513 For incoming media packets (arriving at the IPAPM's IPv4 interface), 514 the IPAPM should modify source and destination address and port pairs 515 as follows. The IPAPM should make an address/port mapping for packets 516 having the public IPv4 source address plus port number that the IPv4 517 user agent placed in its session descriptions. The IPAPM should map 518 the source address/port of these IPv4 packets to the IPv6 source 519 address plus port number assigned by the SIP Edge Proxy to the IPv4 520 user agent for this session. The IPAPM must also look for packets 521 having the public IPv4 destination/port address corresponding to that 522 assigned to the IPv6 user agent by the SIP Edge Proxy. These must be 523 mapped to the IPv6 address/port pair contained in the session 524 description sent by the IPv6 user agent. 526 For outgoing media packets (arriving at the IPAPM's IPv6 interface), 527 the IPAPM should modify source and destination address and port pairs 528 as follows. Packets having the IPv6 source address plus port number 529 that the 3GPP user agent placed in its session descriptions, must be 530 mapped to the IPv4 source address and port assigned by the SIP Edge 531 Proxy to the 3GPP user agent for this session. The IPAPM must also 532 look for packets having the IPv6 destination/port address 533 corresponding to that assigned to the IPv4 user agent by the SIP Edge 534 Proxy. These must be mapped to the IPv4 address/port pair contained 535 in the session description sent by the IPv4 user agent 537 Note that the protocol used for communicating the address/port 538 mapping information from SIP Edge Proxy to the IPAPM is beyond the 539 scope of this document. Two alternatives are MEGACO [14] and the 540 MIDCOM protocol being developed [15]. 542 [Note for next revision: Specify how long to keep state] 544 4.5 Private Addressing in IPv4 User Agent 546 The procedures described above work fine when the IPv4 user agent has 547 a public IPv4 address and provides it in its session description. 548 However, many IPv4 user agents are behind NATs. Therefore it is 549 necessary for them to discover the public IPv4 address/port which 550 they get assigned by the NAT, to be able to use it in end-to-end SDP 551 messages. 553 To resolve this situation the 3GPP IMS user agent should choose to 554 use ICE when the first attempt fails (i.e. Error response to an 555 INVITE) or when the peer uses only private IPv4 addresses in its 556 offer. The 3GPP user agent would add "a=alt" lines to its media lines 557 grouped by ALT, as described in [7] and would run STUN servers on 558 those media transport addresses. The IPv4 user agent would be able to 559 discover public addresses for itself by communicating with these STUN 560 servers. Using ICE and STUN this way allows user agents to discover 561 new addresses which allow connectivity to the SIP peer, as described 562 in [12]. This mechanism does not require introduction of new servers 563 in IMS, but requires additional procedures in the SIP proxy, support 564 in the 3GPP user agent and in the IPv4 user agent as described in the 565 sections below. 567 It may be possible to recommend ICE implementation in 3GPP user 568 agents, but support of ICE/STUN in IPv4 user agents is necessary to 569 make this communication work. Since at the current time it is 570 uncertain whether IPv4 user agents on the Internet will support 571 ICE/STUN, it is not possible to guarantee that this procedure will 572 work. Should this procedure fail then the user agents will know that 573 communication is not possible. 575 We assume that the IPv4 user agent utilizes a SIP Proxy which has one 576 or more public IPv4 addresses. Therefore this proxy can communicate 577 with the SIP Edge Proxy at the edge of the IMS domain which also has 578 at least one public IPv4 address. 580 4.5.1 IMS Generated INVITE 582 As described previously, this solution is based on the ICE mechanism 583 [12]. In this case the 3GPP user agent sends an INVITE to the IPv4 584 user agent. The IPv4 user agent happens to have only IPv4 private 585 addresses. As described previously (see 4.2), this results in an 586 Error response from the IPv4 user agent. The SIP Edge Proxy then 587 locally assigns an IPv4 address/port to the 3GPP user agent, gets 588 ready to install state in the IPAPM and appends this address/port to 589 the Error Response. The 3GPP user agent then generates a new INVITE 590 and uses the procedure described in ICE [12]. In particular it should 591 start STUN servers on the IPv6 addresses it will use in its offer. 592 The 3GPP user agent then sends the offer containing "a=alt" lines to 593 its media lines grouped by ALT [7]. One of the media addresses must 594 be the public IPv4 address which the SIP Edge Proxy appended to the 595 previous Error Response. The SIP Edge Proxy now has all the 596 information to install bidirectional state in the IPAPM for the 3GPP 597 user agent. 599 The IPv4 user agent (assuming it supports ICE) runs the ICE procedure 600 upon receiving the offer (INVITE) from the 3GPP user agent. In this 601 way it discovers at least one public IPv4 address/port pair for 602 itself and uses this in its SDP answer. The procedure then follows as 603 described in 4.2. Note that it is not strictly necessary that the 604 3GPP user agent runs STUN after receiving the response since it does 605 not need to discover new addresses for the communication. 607 If ICE is not supported by the IPv4 user agent then the communication 608 will ultimately fail. The IPv4 user agent will return only private 609 IPv4 addresses in its SDP answer. The response will traverse the SIP 610 Edge Proxy which will not be able to allocate IPv6 address/port pairs 611 mapped to private IPv4 addresses. The 3GPP user agent will receive 612 the response, will return an ACK and will immediately send a BYE 613 message to terminate the call since it cannot accept the private IPv4 614 address in the SDP response. 616 Note that according to this mechanism the 3GPP UA should start STUN 617 servers on its IPv6 media addresses when it transmits an SDP Offer 618 containing IPv4 addresses (message marked with "a=alt lines" in 619 Figure 4). 621 3GPP UA 3GPP SIP SIP Edge Internet Internet 622 IPv6 Proxies Proxy SIP Proxy IPv4 UA 623 | | | | | 624 |-------------->|-------------->|------------->|------------->| 625 | INVITE Offer | INVITE Offer | INVITE Offer | INVITE Offer | 626 | (IPv6) | (IPv6) | (IPv6) | (IPv6) | 627 | | | | | 628 | | (F)|<-------------|<-------------| 629 |<--------------|<--------------| Error | Error | 630 | Error | Error | | | 631 | [IPv4 ext.] | [IPv4 ext.] | | | 632 | | | | | 633 |-------------->|-------------->|(G) | | 634 | INVITE Offer | INVITE Offer |------------->|------------->| 635 | (IPv4, IPv6) | (IPv4, IPv6) | INVITE Offer | INVITE Offer | 636 | a=alt lines | a=alt lines | (IPv4, IPv6) | (IPv4, IPv6) | 637 | | | a=alt lines | a=alt lines | 638 | | | | 639 | | IPAPM | | 640 | | | | | 641 | | (H)|<-------------|<-------------| 642 |<--------------|<--------------|STUN Bind.Req.|STUN Bind.Req.| 643 |STUN Bind. Req |STUN Bind. Req.| | | 644 | | | | | 645 |-------------->|-------------->|------------->|------------->| 646 |STUN Bind.Resp.|STUN Bind.Resp.|STUN Bind.Resp|STUN Bind.Resp| 647 | | | | 648 | | SIP Edge | | 649 | | Proxy | | 650 | | | | | 651 | | (J)|<-------------|<-------------| 652 |<--------------|<--------------| OK (IPv4) | OK (IPv4) | 653 | OK (IPv4) | OK (IPv4) | | | 654 | [IPv6 ext.] | [IPv6 ext.] | | | 655 | | | | | 656 |-------------->|-------------->|------------->|------------->| 657 | ACK | ACK | ACK | ACK | 658 | | | | | 660 Figure 4 - IMS-Generated INVITE Messaging Diagram 661 (Private IPv4 Address on Internet UA) 663 (F) - SIP Edge Proxy locally assigns a public IPv4 addr/port to the 664 3GPP UA and communicates this to the 3GPP UA by inserting 665 this information in the [IPv4 ext.] 666 (G) - SIP Edge Proxy installs mapping in IPAPM for 3GPP UA IPv6 667 addr/port to locally assigned IPv4 addr/port (IPv4), see (F). 668 (H) - SIP Edge Proxy reads the incoming STUN Binding Request and 669 forwards it by translating the IPv4 destination address to 670 the IPv6 address (IPAPM has the mapping, see (E)). As a 671 source address it uses the IPv4 address in the original 672 message and a IPAPM-owned prefix (PREFIX::a.b.c.d). 673 (J) - SIP Edge Proxy installs mapping in IPAPM for Internet UA IPv4 674 addr/port to locally assigned IPv6 addr/port (in [IPv6 ext.]) 676 4.5.2 Internet (private IPv4) Generated INVITE 678 As described previously, this solution is based on the ICE mechanism 679 [12]. The IPv4 user agent (which only has private IPv4 addresses) 680 sends an SDP offer (e.g. INVITE) to the 3GPP IPv6-only user agent 681 utilising private addresses. It would add "a=alt" lines to its media 682 lines and would run STUN servers on those transport addresses. The 683 SDP offer will then traverse the SIP Edge Proxy. The SIP Edge Proxy 684 is unable to make the local assignment of an IPv6 address/port pair 685 to the IPv4 user agent (see 4.3) because of the private IPv4 686 addressing in the SDP offer. However it is able to make a local 687 assignment of an IPv4 public address/port to the 3GPP IPv6 user agent 688 for this session, and will append this address/port to the SDP offer. 689 The mechanism to append this information to the SDP offer is 690 described in 4.2. 692 When the 3GPP user agent receives the SDP offer it will send back an 693 SDP answer (e.g. 200 OK) to allow the STUN procedure to proceed (i.e. 694 it can see that the offerer is using STUN). The SDP answer will 695 contain the newly assigned public IPv4 address/port (previously 696 appended to the SDP offer by the SIP Edge Proxy) and its IPv6 media 697 address/ports. The 3GPP user should add "a=alt" lines to its media 698 lines and run STUN servers on those media addresses (i.e. excluding 699 the IPv4 address since it is an IPv6-only host). 701 The SDP answer will traverse the SIP Edge Proxy. The SIP Edge Proxy 702 will now be able to install the bidirectional mapping in the IPAPM 703 between the 3GPP user agent's IPv6 media address in the SDP answer 704 and the public IPv4 address which it locally assigned previously 705 (this IPv4 address is also contained in the SDP answer). 707 When the IPv4 user agent receives the SDP answer, it will run STUN 708 towards the public IPv4 address supplied by the 3GPP user agent in 709 SDP as described in [12]. This will allow it to check connectivity to 710 the IPv4 address in the answer and learn about public IPv4 addresses 711 which it is reachable at. 713 At this point the IPAPM will have a binding which allows it to map 714 the IPv4 destination address of the STUN Binding Request to the 3GPP 715 UA's IPv6 address. However it does not have a binding to map the IPv4 716 source address to an IPv6 source address. That is performed by 717 combining the original IPv4 address and an IPAPM-owned IPv6 prefix, 718 similar to the procedure used in NAT-PT [16] (i.e. PREFIX::a.b.c.d, 719 where a.b.c.d is the IPv4 address). The IPAPM should be STUN-aware to 720 allow only STUN packets to undergo this procedure. The IPAPM must 721 also maintain one or more IPv6 address prefixes for this purpose 722 which must be configured on its IPv6 interface. The IPv6 addresses 723 used for this procedure must not be the same as those used for 724 mapping operations from the SIP Edge Proxy. The STUN Request will 725 therefore reach the 3GPP user agent having the IPAPM-owned IPv6 726 address as its source address. The 3GPP UA must extract the original 727 IPv4 address from the source address of the STUN Binding Request to 728 be used in the Binding Response message. The IPAPM will be able to 729 easily map the source/destination addresses of the incoming STUN 730 Binding Response from the 3GPP UA by using its bindings (for the 731 source address) and by extracting the IPv4 address from the IPv6 732 address (for the destination address). 734 Once it has found new public IPv4 addresses which allow connectivity 735 to the 3GPP user agent, the IPv4 user agent should issue a new offer 736 (e.g. re-INVITE or UPDATE) to pass the newly discovered public IPv4 737 address to the callee. Now that the IPv4 user agent has at least a 738 public address/port pair it can complete the procedure successfully 739 as described in 4.3. 741 If the IPv4 user agent does not support ICE, the communication would 742 fail. One alternative could be to deploy specific servers (e.g. TURN) 743 on the edge of the 3GPP network (i.e. IPAPM) if it is found that IPv4 744 user agents support other methods to discover public IPv4 745 address/ports. 747 Note that according to this mechanism the 3GPP UA should start STUN 748 servers on its IPv6 media addresses when it transmits an SDP Answer 749 containing IPv4 addresses (message marked with "a=alt lines" in 750 Figure 5). 752 3GPP UA 3GPP SIP SIP Edge Internet Internet 753 IPv6 Proxies Proxy SIP Proxy IPv4 UA 754 | | | | | 755 | | (K)|<-------------|<-------------| 756 |<--------------|<--------------| INVITE Offer | INVITE Offer | 757 | INVITE Offer | INVITE Offer | (IPv4) | (IPv4) | 758 | (IPv4) | (IPv4) | | | 759 | [IPv4 ext.] | [IPv4 ext.] | | | 760 | | | | | 761 |-------------->|-------------->|------------->|------------->| 762 |OK (IPv4, IPv6)|OK (IPv4, IPv6)|OK (IPv4,IPv6)|OK (IPv4,IPv6)| 763 | a=alt lines | a=alt lines | a=alt lines | a=alt lines | 764 | | | | 765 | | IPAPM | | 766 | | | | | 767 | | (L)|<-------------|<-------------| 768 |<--------------|<--------------|STUN Bind.Req.|STUN Bind.Req.| 769 |STUN Bind. Req |STUN Bind. Req.| | | 770 | | | | | 771 |-------------->|-------------->|------------->|------------->| 772 |STUN Bind.Resp.|STUN Bind.Resp.|STUN Bind.Resp|STUN Bind.Resp| 773 | | | | 774 | | SIP Edge | | 775 | | Proxy | | 776 | | | | | 777 | | (M)|<-------------|<-------------| 778 |<--------------|<--------------| INVITE Offer | INVITE Offer | 779 | INVITE Offer | INVITE Offer | (IPv4) | (IPv4) | 780 | (IPv4) | (IPv4) | | | 781 | [IPv6 ext.] | [IPv6 ext.] | | | 782 | | | | | 783 |-------------->|-------------->|------------->|------------->| 784 |OK (IPv4, IPv6)|OK (IPv4, IPv6)|OK (IPv4,IPv6)|OK (IPv4,IPv6)| 785 | | | | | 786 |<--------------|<--------------|<-------------|<-------------| 787 | ACK | ACK | ACK | ACK | 789 Figure 5 - Internet-Generated INVITE Messaging Diagram 790 (Private IPv4 Address on Internet UA) 792 (K) - SIP Edge Proxy locally assigns IPv4 public addr/port to the 793 3GPP UA (in [IPv4 ext.]) but does not install IPAPM state. 794 (L) - SIP Edge Proxy reads the incoming STUN Binding Request and 795 forwards it by translating the IPv4 destination address to 796 the IPv6 address (IPAPM has the mapping, see (H)). As a 797 source address it uses the IPv4 address in the original 798 message and a IPAPM-owned prefix (PREFIX::a.b.c.d). 799 (M) - SIP Edge Proxy installs mapping in IPAPM between Internet UA 800 IPv4 address/port and a locally assigned IPv6 address/port. 802 This is communicated to the 3GPP UA using the [IPv6 ext.] 804 4.6 Examples 806 TBD. 808 5. Security Considerations 810 TBD. 812 6. IANA Considerations 814 TBD 816 7. Contributors & Acknowledgements 818 Gabor Bajko (Nokia) has contributed to this work with useful 819 suggestions to clarify the text. Arne Pehrsson (Ericsson) has 820 contributed the STUN address mapping mechanism in 4.5.1 and 4.5.2 822 8. Authors' Addresses 824 Karim El Malki 825 Ericsson 826 LM Ericssons Vag. 8 827 126 25 Stockholm 828 Sweden 829 Phone: +46 8 7195803 830 E-mail: karim.el-malki@ericsson.com 832 Gonzalo Camarillo 833 Ericsson 834 Advanced Signalling Research Lab. 835 FIN-02420 Jorvas 836 Finland 837 E-mail: gonzalo.camarillo@ericsson.com 839 Mikael Lind 840 TeliaSonera 841 Vitsandsgatan 9B 842 SE-12386 Farsta 843 Sweden 844 E-mail: mikael.lind@teliasonera.com 845 Jasminko Mulahusic 846 TeliaSonera 847 Vitsandsgatan 9B 848 SE-12386 Farsta 849 Sweden 850 E-mail: jasminko.mulahusic@teliasonera.com 852 Hesham Soliman 853 Flarion 854 E-mail: H.Soliman@flarion.com 856 9. References 858 [1] Soininen, J. (Ed.), et al., "Transition Scenarios for 3GPP 859 Networks", RFC 3574, August 2003. 861 [2] Wiljakka, J. (Ed.), et al., "Analysis on IPv6 Transition in 862 3GPP Networks", draft-ietf-v6ops-analysis-07 (work in 863 progress), October 2003. 865 [3] Wasserman, M. (Ed.), et al., "Recommendations for IPv6 in Third 866 Generation Partnership Project (3GPP) Standards", RFC 3314, 867 September 2002. 869 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 870 Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: 871 Session Initiation Protocol", RFC 3261, June 2002. 873 [5] Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with the 874 Session Description Protocol (SDP) ", RFC 3264, June 2002. 876 [6] Handley, M. and V. Jacobson, "SDP: Session Description 877 Protocol", RFC 2327, April 1998. 879 [7] Camarillo, G. , Rosenberg, J., "The Alternative Semantics for 880 the Session Description Protocol Grouping Framework", 881 draft-camarillo-mmusic-alt-02 (work in progress), Oct 2003. 883 [8] Rosenberg, J., Weinberger, J., Mahy, R., Huitema, C., 884 "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom 885 turn-02 (work in progress), October 2003. 887 [9] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm 888 Specific IP: Framework", RFC 3102, October 2001. 890 [10] Rosenberg, J., Weinberger, J., Huitema, C., Mahy, R., "STUN - 891 Simple Traversal of User Datagram Protocol (UDP) Through 892 Network Address Translators (NATs)", RFC 3489, March 2003. 894 [11] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 895 draft-huitema-v6ops-teredo-00 (work in progress), June 2003. 897 [12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 898 Methodology for Network Address Translator (NAT) Traversal for 899 the Session Initiation Protocol (SIP)", 900 draft-ietf-mmusic-ice-00 (work in progress), Oct 2003. 902 [13] Rosenberg, J., "Requirements for Session Policy for the Session 903 Initiation Protocol (SIP)", draft-ietf-sipping-session-policy- 904 req-00 (work in progress), June 2003. 906 [14] Groves, C., Pantaleo, M., Anderson, T., Taylor, T., "Gateway 907 Control Protocol Version 1", RFC 3525, June 2003. 909 [15] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., Rayhan, 910 A., "Middlebox communication architecture and framework", RFC 911 3303, August 2002. 913 [16] Tsirtsis, G., Srisuresh, P., "Network Address Translation - 914 Protocol Translation", RFC 2766, February 2000. 916 Intellectual Property Statement 918 The IETF takes no position regarding the validity or scope of any 919 intellectual property or other rights that might be claimed to 920 pertain to the implementation or use of the technology described in 921 this document or the extent to which any license under such rights 922 might or might not be available; neither does it represent that it 923 has made any effort to identify any such rights. Information on the 924 IETF's procedures with respect to rights in standards-track and 925 standards-related documentation can be found in BCP-11. Copies of 926 claims of rights made available for publication and any assurances of 927 licenses to be made available, or the result of an attempt made to 928 obtain a general license or permission for the use of such 929 proprietary rights by implementors or users of this specification can 930 be obtained from the IETF Secretariat. 932 The IETF invites any interested party to bring to its attention any 933 copyrights, patents or patent applications, or other proprietary 934 rights which may cover technology that may be required to practice 935 this standard. Please address the information to the IETF Executive 936 Director. 938 Full Copyright Statement 940 Copyright (C) The Internet Society (2003). All Rights Reserved. 942 This document and translations of it may be copied and furnished to 943 others, and derivative works that comment on or otherwise explain it 944 or assist in its implementation may be prepared, copied, published 945 and distributed, in whole or in part, without restriction of any 946 kind, provided that the above copyright notice and this paragraph are 947 included on all such copies and derivative works. However, this 948 document itself may not be modified in any way, such as by removing 949 the copyright notice or references to the Internet Society or other 950 Internet organizations, except as needed for the purpose of 951 developing Internet standards in which case the procedures for 952 copyrights defined in the Internet Standards process must be 953 followed, or as required to translate it into languages other than 954 English. 956 The limited permissions granted above are perpetual and will not be 957 revoked by the Internet Society or its successors or assigns. 959 This document and the information contained herein is provided on an 960 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 961 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 962 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 963 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 964 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 966 Acknowledgement 968 Funding for the RFC Editor function is currently provided by the 969 Internet Society.