idnits 2.17.00 (12 Aug 2021) /tmp/idnits41892/draft-liumin-v6ops-silkroad-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1062. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1069. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1075. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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.) ** There are 31 instances of lines with control characters in the document. == There are 20 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 149 == Unused Reference: '11' is defined on line 973, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '1') ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3315 (ref. '3') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. '4') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '5') (Obsoleted by RFC 5389) == Outdated reference: draft-huitema-v6ops-teredo has been published as RFC 4380 -- Obsolete informational reference (is this intentional?): RFC 2571 (ref. '7') (Obsoleted by RFC 3411) -- Obsolete informational reference (is this intentional?): RFC 2574 (ref. '8') (Obsoleted by RFC 3414) -- Obsolete informational reference (is this intentional?): RFC 2575 (ref. '9') (Obsoleted by RFC 3415) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '10') (Obsoleted by RFC 4301) == Outdated reference: draft-blanchet-v6ops-tunnelbroker-tsp has been published as RFC 5572 Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF v6ops Working Group Min Liu 2 Internet-Draft Xianguo Wu 3 Expires: January 17, 2006 ICT 4 Mingye Jin 5 China Unicom 6 Defeng Li 7 HUAWEI 9 July, 2005 11 Tunneling IPv6 with private IPv4 addresses through NAT devices 12 draft-liumin-v6ops-silkroad-03.txt 14 Status of this memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 17, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 The growth of IPv6 networks started mainly using the transport 46 facilities offered by the current Internet. This led to the 47 development of several techniques to manage IPv6 over IPv4 tunnels. 48 However, classic tunneling methods do not work when the IPv6 49 candidate node is isolated behind a Network Address Translator (NAT) 50 device. We propose here a service, called Silkroad, to enable nodes 51 located behind one or several IPv4 NATs to obtain IPv6 connectivity. 52 It can provide IPv6 connectivity through all existing NAT types and 53 does not require any update of them. In addition, Silkroad could 54 provide managed IPv6 prefixes with path optimized routing directly 55 between clients. 57 Table of Contents: 59 1 Introduction.....................................................3 60 2 Silkroad Terminology.............................................4 61 2.1 Silkroad Client (SC)...........................................4 62 2.2 Silkroad Access Router (SAR)...................................4 63 2.3 Silkroad Navigator (SN)........................................4 64 2.4 Silkroad UDP port..............................................4 65 3 Background.......................................................5 66 3.1 What is NAT?...................................................5 67 3.2 Types of NAT...................................................5 68 3.3 Traversal of User Datagram Protocol (UDP) Through NATs.........5 69 4 Silkroad Description.............................................6 70 4.1 Silkroad Model.................................................6 71 4.1.1 Silkroad Client (SC).........................................7 72 4.1.2 Silkroad Access Router (SAR).................................7 73 4.1.3 Silkroad Navigator (SN)......................................8 74 4.2 Silkroad Operation.............................................9 75 4.2.1 Determining the SAR..........................................9 76 4.2.2 Obtaining IPv6 Address/prefix................................9 77 4.2.3 Determining the Type of NAT.................................10 78 4.2.4 Packet Transmission from a SC to a Regular IPv6 Node........11 79 4.2.5 Packet Transmission from a Regular IPv6 Node to a SC........12 80 4.2.6 Exchanges Between Two Silkroad Clients......................13 81 5 Route Optimization..............................................15 82 5.1 Exchanges Between two Silkroad Clients........................15 83 5.2 Exchanges Between two Silkroad Clients on the Same Link.......16 84 6 Message Formats.................................................18 85 7 Other Issues of the Solution....................................19 86 7.1 Lifetime of NAT Mappings......................................19 87 7.2 Lifetime of Silkroad Tunnel...................................19 88 7.3 Mobility Support in Silkroad..................................20 89 8 Security Consideration..........................................21 90 9 IANA Considerations ............................................21 91 10 Acknowledgments................................................22 92 References........................................................22 93 Authors' Addresses................................................24 94 Appendix A........................................................24 95 Intellectual Property and Copyright Statements....................25 97 1. Introduction 99 The growth of IPv6 networks started mainly using the transport 100 facilities offered by the current Internet. Complete upgrades of 101 current Internet from IPv4 to IPv6 will take a long time. Thus the 102 key to a successful IPv6 transition is compatibility with the large 103 installed base of IPv4 hosts and routers. This led to the 104 development of several techniques to manage IPv6 over IPv4 tunnels. 105 Classic tunneling methods designed for IPv6 transition operate by 106 sending IPv6 packets as payload of IPv4 packets. However, these 107 methods do not work when the IPv6 candidate node is isolated behind a 108 Network Address Translator (NAT) device. The reason is that usually 109 NATs will perform ingress filtering and refuse to allow the 110 transmission of many payload types. 112 In this memo, we propose a service, called Silkroad, to enable nodes 113 located behind one or several IPv4 NATs to obtain IPv6 connectivity. 114 It provides connectivity for clients located behind all existing NAT 115 types, including symmetric NAT. Silkroad does not need special IPv6 116 addressing prefix and can provide the users with stable/dynamic IPv6 117 address. In addition, Silkroad could provide route optimization 118 between clients. Unlike Teredo, which is primarily a way to make 6to4 119 style automation work through NATs, Silkroad is one way to make a 120 managed tunnel work through NATs. It is a efficient method for ISPs 121 that are willing to provide IPv6 connectivity to their customers 122 behind NATs, but may not be able to do it natively due to a number of 123 reasons. Silkroad approach is expect to be useful to stimulate the 124 growth of IPv6 and to allow early IPv6 network providers to provide 125 easy access to their IPv6 network. 127 This document is intended to present a framework describing the 128 guidelines for the provision of a Silkroad service within the 129 Internet. It details the general architecture of the proposed 130 approach and also outlines a set of viable implementation. The memo 131 is organized as follows. Section 2 contains the definition of the 132 terms used in the memo. Section 3 introduces the background 133 information. Section 4 provides an overall description of the 134 Silkroad model. Section 5 presents the route optimization of Silkroad 135 in certain scenarios. Section 6 contains the format of the messages. 136 Section 7 is a discussion of some other issues of this solution. 137 Section 8 and Section 9 contain a security discussion and IANA 138 consideration. 140 In appendix A, we compare the mechanism to some other proposed 141 mechanisms: Teredo[6] and an instance of Tunnel Broker concept-- 142 TSP[12]. 144 2. Silkroad Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 This section defined other terminology used with Silkroad: 152 2.1 Silkroad Client (SC) 154 A dual stack node that has some access to the IPv4 Internet and that 155 wants to gain access to the IPv6 Internet. 157 2.2 Silkroad Access Router (SAR) 159 A dual stack router that has access to the IPv4 Internet through a 160 globally registered address. It will be used to help Silkroad clients 161 to gain IPv6 connectivity. 163 2.3 Silkroad Navigator (SN) 165 A node that is used to help SARs to route between each other. The 166 only requirement for SN is reachable for its SARs. It may be IPv4 or 167 IPv6 addressable, which is up to the specific ISP. It is recommended 168 for ISP whose SARs are relatively few. However, it is mandatory for 169 ISP who has many SARs and SCs. 171 2.4 Silkroad UDP port 173 The UDP port number at which Silkroad Access Routers are waiting for 174 packets. The value of this port is TBD. In this memo, we use port 175 5188 temporarily. 177 3. Background 179 3.1 What is NAT? 181 The need for IP address translation arises when a network's internal 182 IP addresses can not be used outside the network either because they 183 are invalid for use outside, or because the internal addressing must 184 be kept private from the external network. 186 Network Address Translation(NAT)is a method by which IP addresses are 187 mapped from one realm to another. It is often used to connect an 188 isolated address realm with private unregistered addresses to an 189 external realm with globally unique registered addresses. [1] 190 describes the operation of NAT devices and the associated 191 considerations in general. 193 Typically, NATs are not programmed to allow the transmission of 194 arbitrary payload types. As a result, many existing tunnel techniques 195 for IPv6 transition operation, which send IPv6 packets as payload of 196 IPv4 packets, can not work if the user is using private IPv4 address 197 behind a NAT box. 199 3.2 Types of NAT 201 It is assumed that the reader is familiar with NATs. It has been 202 observed that NAT devices can adopt widely different strategies among 203 implementations. Four treatments observed in implementations are 204 described in [5], which are Full Cone NAT, Restricted Cone NAT, Port 205 Restricted Cone NAT and Symmetric NAT. 207 Silkroad can provide IPv6 connectivity for clients located behind all 208 these four NAT types. However, determining the type of NAT will be 209 important when we want to optimize the transmission performance of 210 Silkroad. 212 3.3 Traversal of User Datagram Protocol (UDP) Through NATs 214 Experience shows that TCP and UDP are the only protocols guaranteed 215 to cross the majority of NAT devices. Although transporting IPv6 216 packets as the payload of TCP packets would be possible, it often 217 result in a very poor QoS (Quality-of-Service). What's more, it is 218 hard for applications to enforcing their own control on the 219 transmission rate in TCP. As a result, current traversal techniques 220 through NATs are generally based on UDP. Silkroad also transports 221 IPv6 packets as the payload of UDP packets. 223 4 Silkroad Description 225 Silkroad communication procedures are based on assumptions on NAT 226 treatment of UDP; such assumptions may prove invalid when new NAT 227 devices are deployed. 229 Silkroad is designed to robustly enable IPv6 traffic through NATs, 230 and the price is a reasonable amount of overhead, due to UDP 231 encapsulation. Thus Silkroad SHOULD NOT be used except when the 232 direct IPv6 connectivity is not locally available and the node can 233 not use a global IPv4 address. 235 4.1 Silkroad Model 237 The typical model of Silkroad is shown in Figure 1. 239 +------+ +-------+ 240 | IPv6 |/-----+ -| SAR | 241 | Node |\----+| / +-------+ 242 +------+ || / 243 || +------+ / +-------+ 244 || -| SN | ----| SAR | 245 || / +------+ \ +-------+ 246 NAT \/ / \ NAT 247 +------+ | +-------+ / \ +-------+ | +------+ 248 | SC |<--+-->| SAR |- -| SAR |<--+-->| SC | 249 +------+ | +-------+ +-------+ | +------+ 250 /\ /\ /\ /\ /\ /\ 251 || || || || || || 252 |+-----------+| |+--------------------+| |+-----------+| 253 +-------------+ +----------------------+ +-------------+ 254 UDP Tunnel UDP Tunnel 256 Figure 1: The Silkroad model 258 As can be seen from Figure 1, the Silkroad service requires the 259 cooperation of three kinds of entities: Silkroad clients(SCs), who 260 want to use IPv6 despite being located behind a NAT; Silkroad access 261 routers(SARs), who provide for the interconnection between the 262 Silkroad clients and the existing IPv6 Internet; Silkroad 263 navigators(SNs), who will help the SAR to forward packets. 265 The Silkroad service is realized by having clients interact with 266 SARs to send and receive IPv6 packets through the Silkroad service 267 protocol. There will be no direct interaction between SCs and SNs. 268 For ISP whose SCs and SARs are relatively few, its SARs could 269 configure static tunnels between each other. Under this case, SN is 270 recommended but not mandatory. For large ISP that havs many SARs and 271 SCs, and it is diffult or imposssible to implement N^2 trust model, 272 it will be necessary to deploy SN to help SARs to route between each 273 other during the packet transmission process. In this process, the 274 role of SN is like a DNS(Domain Name System). There may be 275 hierarchical SNs for one ISP. Each of them takes charge of a 276 different SAR domain. The authentication and coherence for SARs and 277 SNs in one ISP will follow the specific ISP's security and route 278 consideration and existing machenisms. There will be no automatic 279 synchronization and interaction between SARs and SNs belonging to 280 different ISPs, unless there are prior agreement. Generally, the 281 packet forwarding between SARs belonging to different ISPs will 282 follow IPv6 rules and no route optimization could be made. 284 The deployment model of Silkroad makes two assumptions: 286 - That all Silkroad clients and Silkroad access routers will be 287 cognizant of the Silkroad port; 289 - That all Silkroad access routers will know the address of its 290 Silkroad navigator. 292 4.1.1 Silkroad Client (SC) 294 A SC is a node that has some access to the IPv4 Internet and that 295 wants to gain access to the IPv6 Internet despite being located 296 behind a NAT. It mainly has the following functions: 298 - Manage UDP tunnel with SAR 300 Create, modify or delete tunnel; 301 Determining the type of NAT; 302 Optimize routes; 303 Send keep-alive packets; 305 - Security control with SAR 307 - Ingress filtering 309 - Provide transparent Silkroad support for applications 311 4.1.2 Silkroad Access Router (SAR) 313 A SAR is a dual-stack (IPv4 & IPv6) router that has access to the 314 IPv4 Internet through a globally routable address. It mainly has the 315 following functions: 317 - Manage UDP tunnel: 319 Create, modify or delete tunnel; 321 Determining the type of NAT; 322 Maintain usage statistics for every active tunnel; 324 - IPv6 address assignment and management 326 - Maintain the list of recent communication peers 328 - Update routing cache with the help of SN 330 - Connect to SN to search whether one IPv6 destination is a SC 331 serviced by another SAR; if yes, get the IPv4 address of the 332 SAR 334 - Secure qualification for SC 336 - Forward packets in IPv6/IPv4 networks 338 - Access control and security control 340 The ISP must ensure that the SAR is capable to handle the amount of 341 users and the traffic that goes through it. 343 4.1.3 Silkroad Navigator (SN) 345 The only requirement for SN is reachable for its SARs. It may be IPv4 346 or IPv6 addressable, which is up to the specific ISP. A SN mainly has 347 the following functions: 349 - Manage and control SARs in its domain 351 - Help SARs to update their routing cache 353 - Help SARs to search one specific SC's SAR, and provide its 354 address 356 - If having lower level SNs, manage them and help them to do 357 address resolution 359 As we have mentioned above, for large ISP that has many SARs and SCs, 360 it will be necessary to deploy SN to help SARs to route between each 361 other during the packet transmission process. In this process, the 362 role of SN is like a DNS. There may be hierarchical SNs for one ISP. 363 Each of them take charge of a different SAR domain. But at this 364 time, it is recommended to offer native IPv6 instead of deploying 365 too many SNs. 367 4.2 Silkroad Operation 369 4.2.1 Determining the SAR 371 The first phase of Silkroad operation is determining an appropriate 372 SAR to provide Silkroad service to the SC. In other words, the SC has 373 to learn the IPv4 address of its SAR. There are many possible ways to 374 do this. For example, the SC could get the SAR's information from its 375 administrator, or using DNS to look up a service name. What's more, a 376 pre-configured or pre-determined IPv4 anycast address could also be 377 used to find the SAR. Of course, ISP could use other unspecific 378 methods to advertise its SARs' address or domain name. Anyway, once 379 determined, the corresponding SAR's information will be automatically 380 saved in the SC's configuration file. This SAR will become the SC's 381 default SAR, unless the SC explicitly changes its configuration. 383 4.2.2 Obtaining IPv6 Address/prefix 385 In order to obtain an IPv6 address/prefix, SC sends the SAR a normal 386 Neighbor Discovery [2] (ND) Route Solicitation (RS) or a DHCPv6 [3] 387 SOLICIT or prefix delegation request [4] message over UDP. 389 The SAR replies with a normal ND Route Advertisement (RA) or a 390 further DHCPv6 message over UDP tunnel to the SC. The default prefix 391 length will be a /64. Whether of not providing an arbitrary length 392 prefix is up to the specific ISP's policy and business process. The 393 ISP may require prior agreement for special requirements. 395 The message replied by SAR also contains a "Control Option" domain 396 that specifies the IPv4 address and port number from which the SAR 397 received the prefix request. At the same time, the SAR creates a 398 mapping between the SC's IPv6 address, and its IPv4 address and port 399 number. In fact, when a prefix request arrives at the SAR, it may 400 have passed through one or more NATs between the SC and the SAR. As a 401 result, the source address of the request received by the SAR will be 402 the mapped address created by the NAT closest to the SAR. The SAR 403 copies that source IP address and port into the "Control Option" 404 domain and sends it back to the source IP address and port of the 405 request. 407 When the SAR replies RA, the packet will have the following format: 409 +------+-----+----------------+-----------------+ 410 | IPv4 | UDP | Control Option | RA | 411 +------+-----+----------------+-----------------+ 413 The IPv6 address/prefix assigned to SCs is belonging to the IPv6 414 addressing space managed by the SAR. SC could preserve a stable IPv6 415 address even though its IPv4 address is dynamic. 417 Similarly, SCs can also request for temporary addresses. These 418 addresses will be assigned a lifetime and removed after its 419 expiration unless an explicit lifetime extension request is submitted 420 by the SC. 422 As mentioned above, once a SAR has assigned an IPv6 address/prefix to 423 a SC, this SAR will make an address binding in its mapping table, in 424 which the assigned IPv6 address/prefix is associated with the mapped 425 IPv4 address and mapped port of the SC. Address binding MAY be 426 dynamic with dynamic IPv4 address of SCs. In addition, the SAR will 427 maintain the management information about this UDP tunnel. 429 4.2.3 Determining the Type of NAT 431 The previous section presented a simple address assignment procedure. 432 When the SC receives the prefix response, it compares the IP address 433 and port in Control Option with the local IP address and port it 434 bound to when the request was sent. If these do not match,the SC is 435 behind one or more NATs; otherwise, the SC need not use the Silkroad 436 service. 438 For better transmission efficiency, the SC could choose to determine 439 the type of NAT behind which it is located with the help of SAR. To 440 determine that, the SC sends Test Requests and SAR replies with Test 441 Response. The procedure May generally work as in [5] (Of course, the 442 exact implementation will be flexible). 444 The SC would send a Test Request packet to a different SAR IPv4 445 address from the same source IP address and port. If the address and 446 port in the Control Option in the response are different from those 447 in the first response, the client knows it is behind a symmetric NAT. 449 To determine if it's behind a full-cone NAT, the SC can send a Test 450 Request with flags that tell the SAR to send a response from a 451 different IP address and port than the request was received on. If 452 the SC receives this response, it knows it is behind a full cone NAT. 454 Of course, the SC can also send a Test Request with flags that tell 455 the SAR to send the Test Response from the same IP address the 456 request was received on, but with a different port. This can be used 457 to detect whether the SC is behind a port restricted cone NAT or just 458 a restricted cone NAT. 460 Once determined, the NAT type will be saved by the SC. 462 4.2.4 Packet Transmission from a SC to a Regular IPv6 Node 464 The exchange of packets between a SC and a regular IPv6 node is 465 presented in the following figure, in which "A" is a SC located 466 behind the NAT , "SAR1" is the SAR chosen by "A", and "B" is a 467 regular IPv6 node. 469 +------+ 470 -| SN | 471 / +------+ 472 NAT / 473 +------+ | +-------+ / IPv6 +------+ 474 | A |<--+-->| SAR1 |<---------------->| B | 475 +------+ | +-------+ +------+ 476 /\ /\ 477 || || 478 |+-----------+| 479 +-------------+ 480 UDP Tunnel 482 Figure 2: Packet transmission from a SC to a regular IPv6 node 484 We assume that A has already gotten its IPv6 address from SAR1. We 485 also assume that the address of each entity is the following: 487 - A's private IPv4 address and port are: 1.0.0.1:1234 488 - A's mapped IPv4 address and port are: 2.0.0.2:5678 489 - A's IPv6 address is: 3ffe:8330:1::1234 490 - SAR1's IPv4 address and port are: 3.0.0.3:5188 491 - B's IPv6 address is: 2001:250:f006:1::5678 493 A wants to transmit an IPv6 packet to B. A's first action is to 494 encapsulate this IPv6 packet in a UDP Datagram within IPv4, and send 495 it from source address and port 1.0.0.1:1234, to the address of SAR1: 496 3.0.0.3:5188. We call it Silkroad packet. (The prefix response packet 497 from SAR described in 4.2.2 and the Test Request and Test Response 498 packets described in 4.2.3 are also Silkroad packets.) This packet 499 will have the following format: 501 +------+-----+----------------+-------------+ 502 | IPv4 | UDP | Control Option | IPv6 packet | 503 +------+-----+----------------+-------------+ 504 The packet is received by the NAT. NAT uses the existing mapping 505 for 1.0.0.1:1234, and replaces the UDP source address and port by the 506 mapped values 2.0.0.2:5678, before forwarding the packet. 508 The packet is received over IPv4 UDP tunnel by SAR1. SAR1 examines 509 the IPv6 destination and checks if there is an entry for this IPv6 510 address in the list of recent communication peers, and if the entry 511 is still valid. If there is no entry for this IPv6 destination or the 512 entry is invalid, SAR1 will connect to its SN to search whether B is 513 one SC serviced by another SAR. The search process is like the 514 disposal process of DNS. The SN will search SARs' information in its 515 own management domain. If there is no entry, it will ask its upper SN 516 for help. The address resolution process will be restricted in one 517 ISP's network, that means SNs belonging to different ISPs will not 518 cooperate with each other unless there are prior agreements. In the 519 case shown in Figure 2, the search process will be ended with the 520 conclusion that B is not one SC in the ISP's network. Thus the SAR1 521 will discard the IPv4 and UDP header and Control Option domain, and 522 forward other content of the packet over IPv6 to the address of B: 523 2001:250:f006:1::5678. In this way, no route optimization could be 524 made. 526 If SAR1 gets the route information for B from the address resolution 527 process with the help of SN, it will update the list of recent 528 communication peers: if there is no entry for B in the list, add one 529 entry for B and indicate B is a regular IPv6 node; Otherwise, set the 530 status to valid. 532 4.2.5 Packet Transmission from a Regular IPv6 Node to a SC 534 Consider the same scenario in Figure 2. When B wants to transmit an 535 IPv6 packet to A, B simply follows IPv6 rules. Because the IPv6 536 address of A is belonging to the address space of SAR1, and SAR1 is 537 IPv6 reachable, the packet will be forwarded to SAR1 over IPv6. In 538 this process, no route optimization could be made. SAR1 will check 539 the address binding in its mapping table, in which it will find that 540 the destination IPv6 address is associated with A's mapped IPv4 541 address and port. Thus SAR1 will forward the packet to A in UDP 542 tunnel. At the same time, SAR1 will check the list of recent 543 communication peers. If there is one entry for B, SAR1 will update 544 the period of validity; otherwise, SAR1 will add one entry for B. The 545 default period of validity will be 30 seconds. After 30 seconds, tne 546 entry will be set invalid. Every time SAR receives packet from the 547 peer, the period of validity for the peer will be reset to 30 548 seconds. 550 4.2.6 Exchanges Between Two Silkroad Clients 552 The following figure shows two SCs,"A" and "B", connected through the 553 NATs "NAT1" and "NAT2". "SAR1" is the SAR chosen by "A" and "SAR2" is 554 the SAR chosen by "B". 556 +------+ 557 -| SN |- 558 / +------+ \ 559 NAT1 / \ NAT2 560 +------+ | +-------+ / UDP Tunnel2 \ +-------+ | +------+ 561 | A |<--+-->| SAR1 |<---------------->| SAR2 |<--+-->| B | 562 +------+ | +-------+ +-------+ | +------+ 563 /\ /\ /\ /\ 564 || || || || 565 |+-----------+| |+-----------+| 566 +-------------+ +-------------+ 567 UDP Tunnel1 UDP Tunnel3 569 Figure 3: Packet transmission between two SCs 571 We assume that A and B have already gotten their IPv6 addresses from 572 SAR1 and SAR2 respectively. In this example, we do not consider any 573 route optimization based on different NAT types. Route optimization 574 will be introduced in section 5. We also assume that the address of 575 each entity is the following: 577 - A's private IPv4 address and port are: 1.0.0.1:1234 578 - A's mapped IPv4 address and port are: 2.0.0.2:5678 579 - A's IPv6 address is: 3ffe:8330:1::1234 580 - SAR1's IPv4 address and port are: 3.0.0.3:5188 581 - SAR2's IPv4 address and port are: 4.0.0.4:5188 582 - B's private IPv4 address and port are: 5.0.0.5:1234 583 - B's mapped IPv4 address and port are: 6.0.0.6:5678 584 - B's IPv6 address is: 2001:250:f006:1::5678 586 A has learnt B's address, for example from the DNS, and starts 587 communication with B. The data packets will be sent from A's IPv6 588 address (3ffe:8330:1::1234) to B's IPv6 address 589 (2001:250:f006:1::5678). The transmission process from A to SAR1 is 590 the same as explained in section 4.2.4. 592 SAR1 examines the IPv6 destination and will find that B is one SC 593 serviced by SAR2. SAR1 may get the route information from the list of 594 recent communication peers or from the address resolution process 595 with the help of SN. 597 If SAR1 gets the route information for B from the address resolution 598 process with the help of SN, it will update the list of recent 599 communication peers: if there is no entry for B in the list, add one 600 entry for B; Otherwise, update the entry content and set the status 601 to valid. 603 After determining the address of SAR2, SAR1 will tunnel the IPv6 604 packet together with the Control Option to the address of SAR2: 605 4.0.0.4:5188. The transmission between SAR1 and SAR2 may follow 606 different ways. It can manage IPv6 packet over another UDP tunnel, 607 like UDP tunnel2 in Figure 3. The advantage of this method is that 608 the disposal of SAR1 before forwarding will be simple, just replacing 609 the UDP source address and port by the values 3.0.0.3:5188 and 610 replacing the UDP destination address and port by the values 611 4.0.0.4:5188. However, the price is a reasonable amount of overhead, 612 due to UDP encapsulation. Silkroad can also send IPv6 packets between 613 SARs as payload of IPv4 packets just like traditional tunnels. But 614 this method does not support Control Option and SAR1 must 615 unencapsulate the packet and reencapsulate it before forwarding. 616 Anyway, the ISP can specify the transmission method between its SARs. 617 The default disposal is that when there is Control Option in the 618 packet, SAR will take UDP tunnel to forward it; otherwise, 619 traditional tunnel will be used. In fact, Control Option generally 620 only appears in the foremost several packets in one session. As a 621 result, SARs may need to "listen" to both, UDP and IP encapsulation. 622 But no matter what transmission method is token between SARs, SCs 623 only need to support UDP encapsulation. 625 For simplification, in the following description, we assume SARs 626 always take UDP tunnel to forward packets between each other. 628 When SAR2 receives the packet over IPv4 UDP tunnel2, it will find 629 that B is a SC serviced by itself, and the address binding in its 630 mapping table shows that the IPv6 destination address 631 2001:250:f006:1::5678 is associated with B's mapped IPv4 address and 632 port: 6.0.0.6:5678. Thus SAR2 will replace the UDP source address and 633 port by the values 4.0.0.4:5188 and replace the UDP destination 634 address and port by the values 6.0.0.6:5678, then forward the packet 635 in UDP tunnel3. At the same time, SAR2 will check the list of recent 636 communication peers. If there is one entry for A, SAR2 will update 637 the entry content; otherwise, SAR2 will add one entry for A. 639 NAT2 will receive this message. It will use the existing mapping to 640 rewrite 6.0.0.6:5678 to 5.0.0.5:1234, and forward the packet to B. 641 Then the packet will be received over IPv4 UDP tunnel3 by B. 643 Note that SAR1 and SAR2 may be the same SAR. In this way, UDP tunnel2 644 will be elided. 646 5 Route Optimization 648 For better transmission efficiency, we can do some route optimization 649 in certain scenarios. Route optimization is optional. ISPs could 650 decide whether to support route optimization for their Silkroad 651 clients. Generally, route optimization will only be done between SCs 652 belonging to the same ISP, unless there are prior agreements between 653 different ISPs. 655 5.1 Exchanges Between Two Silkroad Clients 657 As described in 4.2.6, Figure 4 shows two SCs,"A" and "B", connected 658 through the NATs "NAT1" and "NAT2". "SAR1" is the SAR chosen by "A" 659 and "SAR2" is the SAR chosen by "B". As we have mentioned above, SAR1 660 and SAR2 may be the same SAR . In this way, UDP tunnel2 will be 661 elided. 663 direct communication 664 +----------------------------------------------------------+ 665 |+--------------------------------------------------------+| 666 || || 667 || +------+ || 668 || -| SN |- || 669 || / +------+ \ || 670 \/ NAT1 / \ NAT2 \/ 671 +------+ | +-------+ / UDP Tunnel2 \ +-------+ | +------+ 672 | A |<--+-->| SAR1 |<---------------->| SAR2 |<--+-->| B | 673 +------+ | +-------+ +-------+ | +------+ 674 /\ /\ /\ /\ 675 || || || || 676 |+-----------+| |+-----------+| 677 +-------------+ +-------------+ 678 UDP Tunnel1 UDP Tunnel3 680 Figure 4: Exchanges between two SCs 682 In fact, A and B can communicate with each other directly, unless 683 NAT1 and NAT2 are both Symmetric NAT. Of course, they need the help 684 of SAR1 and SAR2 to exchange some parameters at first. 686 Assume that A wants to communicate with B. If A wants to do route 687 optimization, A could determine the type of NAT behind which it is 688 located with the help of SAR1 as described in 4.2.3. Then A will 689 include its mapped address and mapped port together with its type of 690 NAT in the Control Option in the encapsulated packet to B. If both 691 NAT1 and NAT2 are Full Cone NAT, B will reply IPv6 packets 692 encapsulated in UDP directly to A, with Control Option indicating its 693 mapped address and mapped port. Then A and B will communicate with 694 each other directly through UDP tunnel. If both NAT1 and NAT2 are 695 Symmetric NAT, A and B can not transmit packets to each other without 696 the help of SAR. In other case, A and B must generate some Test 697 packets to establish corresponding mapping at the Restricted Cone 698 NAT/Port Restricted Cone NAT/Symmetric NAT before they can transmit 699 packets directly to each other. In this case, it is recommended that 700 A and B choose to do route optimization only if they want to transmit 701 large bulk traffic. If they only want to transmit a few of messages, 702 there is no need to send test packets to make route optimization. 704 5.2 Exchanges Between Two Silkroad Clients on the Same Link 706 The following figure shows two Silkroad Clients, A and B, connected 707 to the same link, which is connected to the Internet through the 708 NAT1. The exchanges between A and B will use the SAR1. We are not 709 making any assumption about the type of NAT1. This scenario explains 710 how the exchanges between clients on the same link can be optimized 711 to avoid routing all packets through SAR1 and NAT1. 713 +------+ 714 | | 715 +----------->| SAR1 |<-----------+ 716 | | | | 717 | +------+ | 718 | | | 719 UDP tunnel1 | | | UDP tunnel2 720 | +------+ | 721 | | NAT1 | | 722 | +------+ | 723 | / \ | 724 | / \ | 725 | / \ | 726 | +------+ +------+ | 727 | | | | | | 728 +-->| A |<-------->| B |<--+ 729 | | | | 730 +------+ +------+ 731 direct communication 733 Figure 5: Packet transmission between two SCs on the same link 735 We assume that A and B have already gotten their IPv6 addresses from 736 SAR1 respectively. 738 Of course, A and B are possibly located behind the same NAT, if they 739 are both using the same mapped IPv4 address. However, even if the 740 mapped IPv4 addresses are different, they are also possibly located 741 behind the same NAT. On the other hand, even if they are behind the 742 same NAT, it is possible that they can not communicate with each 743 other directly. Thus they have to take some actions to confirm that 744 they are directly reachable. 746 There are several ways to gain this end. Here we only give a viable 747 alternative to implement it. 749 If A wants to discover whether it and B are on the same link, it can 750 include its private address in the Control Option in the packet sent 751 to B through NAT1 and SAR1. When B receives this packet, it will 752 reply encapsulated packets including its private address to SAR1's 753 address and A's private address simultaneously. If A receives both 754 packets, it will confirm that it and B are on the same link and they 755 are directly reachable. Then the packets will be sent directly on the 756 local link, avoiding the loop through SAR1 and NAT1. 758 6 Message Formats 760 In this section, we will introduce Silkroad packet in details. 762 Silkroad packets are transmitted as the payload of UDP packets 763 within IPv4. In order to control and optimize the transmission, 764 Control Option will be inserted in the first bytes of the UDP 765 payload: 767 +------+-----+----------------+-------------+ 768 | IPv4 | UDP | Control Option | IPv6 packet | 769 +------+-----+----------------+-------------+ 771 The first bit of the Control Option is set to 1; this is used to 772 discriminate between the Control Option and the simple IPv6 in UDP 773 encapsulation, in which the first 4 bits of the packet contain the 774 indication of the IPv6 protocol "0110". 776 The Control Option has two different formats: one for control use and 777 one for test use. 779 Format 1 (control use): 781 0 1 2 3 4 5 6 7 782 +-----+-----+-----+-----+-----+-----+-----+-----+ 783 | | | | | | 784 | 1 | 0 | Type | Option Length |Flag | 785 | | | | | | 786 +-----+-----+-----+-----+-----+-----+-----+-----+ 787 | | 788 | Option Content | 789 | | 790 +-----+-----+-----+-----+-----+-----+-----+-----+ 792 Type in this format is 2 bits, which indicates the content type of 793 this option. We have already defined 3 types as follows: 795 11 - Mapped address and port 796 10 - Private address and port 797 01 - Type of NAT 798 00 - unused 800 Option Length is 3 bits, which indicates the length of this option 801 content in unit of byte. 803 The 1 bit Flag is used to indicate whether there are other options 804 following this option in this packet. It means the Control Option 805 domain in one packet could carry more than one type of option. 807 Format 2 (test use): 809 0 1 2 3 4 5 6 7 810 +-----+-----+-----+-----+-----+-----+-----+-----+ 811 | | | | | | 812 | 1 | 1 | Type | Unused |Flag | 813 | | | | | | 814 +-----+-----+-----+-----+-----+-----+-----+-----+ 816 Type in this format is 3 bits, which indicates the content type of 817 this option. We have already defined 5 types as follows: 819 111 - Test request, need not reply 820 110 - Test request, need reply 821 101 - Test request, need reply from a different IP address and 822 port than the request was received on 823 100 - Test request, need reply from the same IP address the 824 request was received on, but with a different port 825 011 - Test response 826 010 - unused 827 001 - unused 828 000 - unused 830 (111 type packet can be used as keep-alive packet) 832 The 1 bit Flag is used to indicate whether there are other options 833 following this option in this packet. 835 7 Other Issues of the Solution 837 7.1 Lifetime of NAT Mappings 839 Regardless of their types, NAT mappings are not kept forever. 840 Generally, if no traffic is observed on the specified port for a 841 "lifetime" period, the corresponding mapping will be removed. The 842 Silkroad client that wants to maintain a mapping open in the NAT will 843 have to send some "keep-alive" traffic before the lifetime expires. 845 7.2 Lifetime of Silkroad Tunnel 846 As mentioned in 4.2.2, IPv6 addresses can be assigned to the SC 847 permanently. In this way, SC could preserve a stable IPv6 address 848 even though its IPv4 address is dynamic. Similarly, SC can also 849 request for temporary addresses. The lifetime of these temporary IPv6 850 addresses should be relatively longer than the lifetime of the IPv4 851 connection of the SC. 853 In addition, there should be keep-alive mechanism on SARs. In this 854 case, if no "refresh" traffic is observed on the assigned address for 855 a duration that exceeds a refresh interval, the Silkroad tunnel will 856 be canceled and the address binding will be removed or be set as 857 unactive. 859 7.3 Mobility Support in Silkroad 861 Silkroad could support mobility in one ISP' network. Assume A is a 862 SC, SAR1 is the home SAR chosen by A, and A has gotten its home 863 address from SAR1. When A move to SAR2's access domain, A will 864 register on SAR2 and get a care-of address from SAR2. If A wants to 865 keep its IPv6 address the same. It could register its new care-of 866 address with SAR1 and ask SAR1 to serve as home agent to deliver all 867 the packets destined for A to A's current point of attachment. Of 868 course, A and SAR1 must share a security association and be able to 869 use Message Digest 5 (RFC 1321) with 128-bit keys to create 870 unforgeable digital signatures for registration requests. The 871 signature is computed by performing MD5's one-way hash algorithm over 872 all the data within the registration message header and the 873 extensions that precede the signature. To secure the registration 874 request, each request must contain unique data so that two different 875 registrations will in practical terms never have the same MD5 hash. 877 Silkroad will not consider support mobility between different ISPs, 878 unless there are prior agreements. 880 8 Security Consideration 882 Generally, Silkroad service is limited in one ISP's scrope. The ISP 883 should perform IPv4 ingress filtering at its borders. In particular, 884 the ISP should block the SAR's address from being used as a source 885 address from the outside. The ISP should perform IPv4 ingress 886 filtering towards its customes, especially SCs, so that they will not 887 be able to forge the IPv4 source address of the packets. 889 For the interaction between SN and SAR, secure SNMP could be adopted 890 [7,8,9]. In addition, if a simpler approach based on RSH commands is 891 used, standard IPsec mechanisms can be applied [10]. 893 For the interaction between SC and SAR, a loss of confidentiality may 894 occur whenever a SC disconnects from the Internet without tearing 895 down the tunnel previously established through the SAR. As a result, 896 the SAR will keep tunneling the IPv6 traffic addressed to that user 897 to its old IPv4 address. However, the fact may be that this IPv4 898 address has already been dynamically assigned to another user. This 899 problem could be solved by implementing on every tunnel the 900 keep-alive mechanism as mentioned in section 7.2. In this way, the 901 SAR will immediately stop IPv6 traffic forwarding towards 902 disconnected users. 904 On the other hand, the SC must ensure that the Silkroad tunnels that 905 it uses remain valid. It does so by checking that packets are 906 regularly received from the SAR. 908 NATs make SC lose end-to-end connectivity but have more security, 909 because a NAT can also be regarded as one type of firewall. With the 910 help of Silkroad a SC become reachable in the IPv6 internet and be a 911 potential goal of attackers. To ensure the security of 912 communications, a SC can use IP security services such as AH or ESP 913 with a global IPv6 connectivity. 915 As the same with Teredo, it is hard for Silkroad to find out a 916 man-in-the-middle attacker, because the deed of a NAT is similar with 917 that of man-in-the-middle attacker. An implementation of 918 identification process between SC and SAR will effectly prevent 919 man-in-the-middle attack. A way to defeat the protection is off-line 920 dictionary attack. If the identification process is encrypted with a 921 symmetry or asymmetry encryption system, it is quite difficult to put 922 man-in-the-middle attack in practice. 924 9 IANA Considerations 926 This memo requests an allocation of a "privileged" UDP port (TBD). 928 10 Acknowledgments 930 The authors would like to thank Li Zhongcheng, Cai Yibing, Shi 931 Jinglin, Tony Hain and Ma Jian for their comments, and Zhang Tianle 932 for initial implementations. 934 Normative References 936 [1] P. Srisuresh and M. Holdrege, "IP Network Address Translator 937 (NAT) Terminology and Considerations", RFC2663, Aug 1999. 939 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 940 IP Version 6 (IPv6)", RFC 2461, December 1998. 942 [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 943 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 944 RFC 3315, July 2003. 946 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 947 Configuration Protocol (DHCP) version 6", RFC 3633, December 948 2003. 950 Informative References 952 [5] J. Rosenberg, J. Weinberger, C. Huitema and R. Mahy, "STUN - 953 Simple Traversal of User Datagram Protocol (UDP) Through Network 954 Address Translators (NATs)", RFC 3489, March 2003. 956 [6] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs", 957 draft-huitema-v6ops-teredo-01.txt (Work in Progress), February 2004. 959 [7] B. Wijnen, D. Harrington and R. Presuhn, "An Architecture for 960 Describing SNMP Management Frameworks", RFC 2571, April 1999. 962 [8] U. Blumenthal and B. Wijnen, "User-based Security Model (USM) 963 for version 3 of the Simple Network Management Protocol (SNMPv3)", 964 RFC 2574, April 1999. 966 [9] B. Wijnen, R. Presuhn and K. McCloghrie, "View-based Access 967 Control Model (VACM) for the Simple Network Management Protocol 968 (SNMP)", RFC 2575, April 1999. 970 [10] S. Kent and R. Atkinson, "Security Architecture for the 971 Internet Protocol", RFC 2401, November 1998. 973 [11] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6 Tunnel 974 Broker", RFC 3053, January 2001. 976 [12] M. Blanchet, F. Parent, "IPv6 Tunnel Broker with the Tunnel 977 Setup Protocol (TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-01(Work 978 in Progress), June 2004. 980 Authors' Addresses 982 Min Liu 983 Institute of Computing Technology 984 Chinese Academy of Sciences 985 Box 2704, Beijing, 100080 PRC 986 Email: liumin@ict.ac.cn 988 Xianguo Wu 989 Institute of Computing Technology 990 Chinese Academy of Sciences 991 Box 2704, Beijing, 100080 PRC 992 Email: xgwu@ict.ac.cn 994 Mingye Jin 995 China Unicom 996 No.133A, Xidan North Street, Xicheng 997 Beijing,100032 PRC 998 Emailú¦jinmy@chinaunicom.com.cn 1000 Defeng Li 1001 HUAWEI Technologies Co., LTD. 1002 Hua Wei Bld., No.3 Xinxi Rd., 1003 Shang-Di Information Industry Base, 1004 Hai-Dian District, Beijing, 100085 PRC 1005 Email: 77cronux.leed0621@huawei.com 1007 Appendix A. Comparison to Other Mechanisms 1009 A.1 Teredo 1011 Teredo is primarily a way to make 6to4 style automation work through 1012 NATs. However, Silkroad is one way to make a managed tunnel work 1013 through NATs. They are two complementary technologies. 1015 Teredo provides an automated IPv6 prefix as a derivative of the IPv4 1016 address. This creates an implicit limit on the stability of the 1017 Teredo addresses, which can only remain valid as long as the 1018 underlying IPv4 address and UDP port remains valid. In addition, 1019 Teredo does not provide connectivity for clients located behind a 1020 symmetric NAT, which is common in large enterprises. 1022 Silkroad is also a tunnel service to enable nodes located behind IPv4 1023 NAT devices to obtain IPv6 connectivity over IPv4 UDP. However,it can 1024 provide connectivity for clients located behind all existing NAT 1025 types, including symmetric NAT. Moreover, Silkroad does not need 1026 special IPv6 addressing prefix and can provide the users with 1027 stable IPv6 address. Of course, the route optimization May be more 1028 complicated in Silkroad than in Teredo, because there is no 1029 information about the IPv4 address and UDP port through which a 1030 Silkroad client can be reached in its IPv6 address. 1032 A.2 Tunnel Broker Solutions 1034 There are several proposed tunnel broker mechanisms. We'll take 1035 TSP[12] as an instance of this model. TSP is one "Tunnel Setup 1036 Protocol", which is not presented to specify any protocol for 1037 trafficing data/IPv6 payload but to provide one easy way to configure 1038 and maintain many different tunnels. From this point, TSP has 1039 relation to all existing tunnel technologies. But it is a "pure 1040 procedure" management technology for tunnels. It is different from 1041 specific tunnel technologies. The goal of Silkroad is to define a 1042 specific tunneling techique to provide IPv6 connetivity for users 1043 behind NATs. It could provide stable and managed IPv6 prefixs and 1044 route optimizations. TSP works also for tunnel configuration across 1045 ISPs. However, Silkroad service will be in one ISP's scope and 1046 communications across ISPs will follow IPv6 rules, unless there are 1047 prior agreements between ISPs. In addition, in the new version of 1048 Silkroad, SN will only help SARs to update routing cache and find the 1049 destination SAR. SN will not receive the tunnel request from SCs and 1050 will not assign SARs to provide Silkroad service. So the basic model 1051 of Silkroad is quite different from traditional tunnel broker. 1053 Intellectual Property Statement 1055 The IETF takes no position regarding the validity or scope of any 1056 Intellectual Property Rights or other rights that might be claimed to 1057 pertain to the implementation or use of the technology described in 1058 this document or the extent to which any license under such rights 1059 might or might not be available; nor does it represent that it has 1060 made any independent effort to identify any such rights. Information 1061 on the procedures with respect to rights in RFC documents can be 1062 found in BCP 78 and BCP 79. 1064 Copies of IPR disclosures made to the IETF Secretariat and any 1065 assurances of licenses to be made available, or the result of an 1066 attempt made to obtain a general license or permission for the use of 1067 such proprietary rights by implementers or users of this 1068 specification can be obtained from the IETF on-line IPR repository at 1069 http://www.ietf.org/ipr. 1071 The IETF invites any interested party to bring to its attention any 1072 copyrights, patents or patent applications, or other proprietary 1073 rights that may cover technology that may be required to implement 1074 this standard. Please address the information to the IETF at 1075 ietf-ipr@ietf.org. 1077 Disclaimer of Validity 1079 This document and the information contained herein are provided on an 1080 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1081 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1082 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1083 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1084 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1085 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1087 Copyright Statement 1089 Copyright (C) The Internet Society (2005). This document is subject 1090 to the rights, licenses and restrictions contained in BCP 78, and 1091 except as set forth therein, the authors retain all their rights.