idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-ipv6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2012) is 4354 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 4925 == Outdated reference: A later version (-07) exists of draft-ietf-dhc-client-id-02 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-public-4over6-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft P. Wu 4 Intended status: Standards Track J. Wu 5 Expires: November 19, 2012 Tsinghua University 6 T. Lemon 7 Nominum, Inc. 8 May 18, 2012 10 DHCPv4 over IPv6 Transport 11 draft-ietf-dhc-dhcpv4-over-ipv6-03 13 Abstract 15 In IPv6 networks, there remains a need to provide IPv4 service for 16 some residual devices. This document describes a mechanism for 17 allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 18 transport. It is done by putting a special relay agent function 19 (Client Relay Agent) on the client side, as well as extending the 20 behavior of the server; in the case where DHCP server only supports 21 IPv4 transport, a relay agent is extended to support IPv6 transport 22 (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, 23 with a new Relay Agent Information sub-option added to carry the IPv6 24 address of the Client Relay Agent. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 19, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6 65 6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 7 66 7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 8 67 8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8 68 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 9 69 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 70 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 12. Appendix: Discussion on One Host Retrieving Multiple 72 Addresses through One CRA . . . . . . . . . . . . . . . . . . 10 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 13.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot 81 operate on an IPv6 network. However, as dual-stack networks become a 82 reality, the need arises to allocate IPv4 addresses in an IPv6 83 environment. To meet this demand, this document extends the DHCPv4 84 protocol to allow the use of an IPv6 network for transport. 86 A typical scenario that probably requires this feature is IPv4-over- 87 IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over- 88 IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts 89 or end networks) across an IPv6 network. If the IPv4 addresses of 90 the end users are provisioned by the concentrator side, then the 91 provisioning process should be able to cross the IPv6 network. One 92 such tunnel mechanism is demonstrated in 93 [I-D.ietf-softwire-public-4over6]. DHCPv4 over IPv6 would be a 94 generic solution for this scenario. 96 Three main flavors of solutions may be considered: 98 o Use DHCPv6 instead of DHCPv4, to provision IPv4-related 99 connectivity. In DHCPv6, the provisioned IPv4 address can be 100 embedded into IPv6 address, or carried within a new option. Along 101 with that, dedicated options are needed to convey IPv4-related 102 information, such as the IPv4 address of DNS server, NTP server, 103 etc. Therefore it will put a certain amount of IPv6-unrelated 104 information into DHCPv6 protocol. 106 o Use DHCPv4 and tunnel DHCPv4-in-IPv4 messages over IPv6. Unlike 107 the previous approach where DHCPv6 is used for both IPv4 and IPv6 108 connectivity, this approach consists in preserving the separation 109 between IPv4 and IPv6 connectivity information. It allows to 110 maintain the IPv4 service without major modification of IPv6- 111 related provisioning resources, and sustains DHCPv4 to be the 112 IPv4-related information carrier. However, this approach enforces 113 an IPv4-in-IPv6 tunnel on DHCP, and subsequently requires extra 114 efforts to maintain tunnel endpoint information for encapsulation 115 use. 117 o Use DHCPv4 and extend it to work on IPv6 transport. Instead of 118 relying on IPv4-in-IPv6 tunnel, this flavor uses IPv6 directly for 119 DHCP message transport, and it keeps the advantage of separation 120 with IPv6 connectivity information. This document focuses on this 121 flavor. The document defines the behavior of extended DHCPv4 122 components, as well as a new sub-option of the Relay Agent 123 Information Option, to support DHCPv4 over IPv6. 125 2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. Terminology 133 This document makes use of the following terms: 135 o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. 137 o Client Relay Agent(CRA): a special DHCPv4 Relay Agent which works 138 as a "proxy" between DHCPv4 client and the IPv6 network by 139 converting between IPv4 transport and IPv6 transport. A CRA 140 either sits on the same, IPv6-accessable host with the DHCPv4 141 client, or sits on the same link with the host. 143 o Host Client Relay Agent(HCRA): a CRA which sits on the same, IPv6- 144 accessible host with the DHCPv4 client. 146 o On-Link Client Relay Agent(LCRA): a CRA which sits on the same 147 link with the host that runs DHCPv4 client. 149 o IPv6-Transport Server(TSV): a DHCPv4 Server that supports IPv6 150 transport. TSV listens on IPv6 for incoming DHCPv4 messages, and 151 sends DHCPv4 messages in IPv6 packets. 153 o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that 154 supports IPv6 transport. TRA sits on a machine which has both 155 IPv6 and IPv4 connectivity, and relays DHCP messages between CRA 156 and regular DHCPv4 server. Unlike CRA, TRA sits on the remote end 157 of IPv6 network, and communicates with DHCPv4 server through IPv4. 159 o Client Relay Agent IPv6 Address Sub-option(CRA6ADDR sub-option): a 160 new sub-option of DHCP Relay Agent Information Option [RFC3046] 161 defined in this document. CRA6ADDR sub-option is used by TRA to 162 carry the IPv6 address of a CRA. 164 4. Protocol Summary 166 The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. 167 DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 168 network in the middle. DHCP messages between a client and the 169 server/relay cannot naturally be forwarded to each other because they 170 are by default IPv4 UDP packets, either unicast or broadcast. To 171 bridge this gap, both the client side and the server/relay side 172 should enable DHCPv4 over IPv6 transport. More precisely, they 173 should support delivering and receiving DHCP messages in IPv6 UDP 174 packets and thereby traverse the IPv6 network. 176 On the client side, a special relay agent called Client Relay Agent 177 is placed on the same host with the client, or on the link of the 178 host. CRA is used to relay DHCP messages from the client to the 179 server, and from the server to the client. CRA sends DHCPv4 messages 180 to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP 181 packets with the DHCPv4 messages from the server. By using CRA, no 182 extension is required on the DHCP client. 184 +-------------------------+ 185 +------+ | 186 |DHCPv4| | 187 |Client| +-------+ 188 +------+ |DHCPv4 | 189 | IPv6 Network |Server/| 190 +------+ |Relay | 191 |DHCPv4| +-------+ 192 |Client| | 193 +------+ | 194 +-------------------------+ 196 Figure 1 Scenario of DHCPv4 over IPv6 Transport 198 The IPv6-Transport DHCPv4 server can receive DHCP messages delivered 199 in IPv6 UDP from CRA, and send out DHCP messages to CRA using IPv6 200 UDP (figure 2(a)). TSV should send DHCP messages to the IPv6 address 201 from which it receives relevant DHCP messages earlier. 203 When CRAs communicate with an IPv6-Transport Relay Agent rather than 204 with a server directly, the situation will become a little more 205 complicated. Besides the IPv6 communication with CRA, TRA also 206 communicates with a regular DHCPv4 server through IPv4. Therefore, 207 when TRA relays DHCP messages between a CRA and the DHCPv4 server, it 208 receives DHCP message from the CRA in IPv6 and sends it to the server 209 in IPv4, as well as receives DHCP message from the server in IPv4 and 210 sends it to the CRA in IPv6. TRA has to use the DHCP Relay Agent 211 Information Option (Option code 82) to record the IPv6 address of the 212 CRA, which will be used as forwarding destination when relaying a 213 DHCP message from the server. Since Option 82 doesn't have an 214 existing sub-option that fits in the case, this document defines a 215 new Client Relay Agent IPv6 Address Sub-option. The DHCPv4 server 216 MUST support the new sub-option in this case. 218 +------+ +------+ 219 |client| IPv6 network |TSV | 220 |+HCRA |----------------| | 221 +------+ +------+ 223 +------+ +------+ +------+ 224 |client| |LCRA | IPv6 network |TSV | 225 | |--| |----------------| | 226 +------+ +------+ +------+ 227 (a)client--server case 229 +------+ +------+ +------+ 230 |client| IPv6 network |TRA | IPv4 network |server| 231 |+HCRA |----------------| |--------------| | 232 +------+ +------+ +------+ 234 +------+ +------+ +------+ +------+ 235 |client| |LCRA | IPv6 network |TRA | IPv4 network |server| 236 | |--| |----------------| |--------------| | 237 +------+ +------+ +------+ +------+ 239 (b)client--relay--server case 241 Figure 2 Protocol Summary 243 5. Client Relay Agent IPv6 Address Sub-option 245 This sub-option MUST be added by a DHCPv4 TRA. It encodes the IPv6 246 address of the machine from which a DHCPv4-in-IPv6 CRA-to-TRA message 247 was received. It is intended for the TRA to relay DHCPv4 replies 248 back to the proper CRA. To be more specific, the TRA uses the IPv6 249 address encoded in this sub-option as the destination IPv6 address 250 when relaying a DHCPv4 reply to IPv6 network. 252 The CRA IPv6 address MUST be unique in the IPv6 domain. 254 The CRA6ADDR sub-option has a fixed length of 18 octets. The SubOpt 255 code is tbd by IANA, the length field is 16, and the following 16 256 octets contain the CRA IPv6 address. 258 DHCP servers handle it following the standard option 82 procedure 259 defined in [RFC3046]. DHCP servers MAY use this sub-option to select 260 parameters specific to particular hosts. Servers MAY parse this sub- 261 option and extract the IPv6 address. 263 SubOpt Len Agent Remote ID 264 +------+------+------+------+------+- -+------+ 265 | tbd | 16 | a1 | a2 | a3 | ... | a16 | 266 +------+------+------+------+------+- -+------+ 268 Figure 3 Client Relay Agent IPv6 Address Sub-option format 270 6. Client Relay Agent Behavior 272 A Client Relay Agent sits on the same host with the DHCPv4 client 273 (HCRA), or on the link of the host (LCRA). CRA is a special type of 274 relay agent, which relays DHCPv4 messages between regular client and 275 TSV/TRA. The communication between CRA and the client happens inside 276 the last-hop local network using IPv4, and the communication between 277 CRA and TSV/TRA happens on the IPv6 network using IPv6. 279 A CRA is configured with one or more IPv6 addresses of TSV/TRA. This 280 configuration is provided before DHCPv4 process, for example through 281 DHCPv6 option, or by some other mechanisms depending on the 282 application scenarios. 284 A CRA listens for DHCP messages on IPv4 UDP port 67. When it 285 receives from IPv4 any DHCP message with bootp op field = 1, it 286 forwards the message using the standard DHCP relay agent format, but 287 over UDPv6, with source port 67 and destination port 67. The CRA 288 forwards the message to each of the TSV or TRA with which it is 289 configured. The CRA SHOULD use a global IPv6 address if it has one. 291 A CRA also listens for DHCP messages on IPv6 UDP port 68. When it 292 receives from IPv6 any DHCP message with bootp op field = 2, the CRA 293 checks to see if the message contains option 82, and if so, it 294 discards the message. Otherwise, it delivers the message to the DHCP 295 client using IPv4. 297 The basic functionality of HCRA and LCRA are the same. The 298 difference is that, when relaying DHCP messages, the HCRA MUST NOT 299 include an option 82 or modify the giaddr field of the DHCP message, 300 while in the LCRA case, it SHOULD NOT include an option 82 or modify 301 the giaddr of DHCP message. If it has to, 302 [I-D.ietf-dhc-dhcpv4-relay-encapsulation] can be used as the solution 303 to the coexistence of LCRA and TRA. 305 A HCRA MUST only serve the client inside the same host, while the 306 LCRA SHOULD serve any client on the link. When the IPv6 address of 307 TSV/TRA is provisioned to the DHCP client, it uses HCRA; else the 308 client depends on LCRA. A HCRA serves only one link; the multiple 309 link case MUST be handled by multiple HCRA instances. A LCRA does 310 not necessarily need an IPv4 address, though it may be configured 311 with one. 313 7. IPv6-Transport Server Behavior 315 To support IPv6 transport, the behavior of DHCPv4 server is extended. 316 The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4 317 messages, and send DHCPv4 messages through IPv6. 319 A TSV listens for DHCP messages on IPv6 UDP port 67. When it 320 receives from IPv6 a DHCP message, it MUST record the IPv6 source 321 address of that message and retain it as the return address of the 322 message. That is to say, when sometime later the TSV responds to 323 this message, it MUST send the reply message to the IPv6 return 324 address retained earlier, with destination port 68. When filling in 325 the server id option of DHCP replies, the TSV MUST choose an IPv4 326 address which is reachable from the client once the residual IPv4 327 service is set up. This follows the server id option requirement in 328 [RFC2131]. The rest of TSV DHCP process is the same with normal 329 DHCPv4 server. A TSV MAY also listen on IPv4 UDP port 67 like a 330 normal DHCPv4 server, and process normally when receives IPv4 DHCPv4 331 message. 333 This document places no new requirements on DHCPv4 servers that do 334 not listen on UDPv6 (other than to support the CRA6ADDR 335 sub-option)--in order to use an IPv4-only DHCPv4 server through an 336 IPv6 connection, a TRA is required. 338 8. IPv6-Transport Relay Agent Behavior 340 An IPv6-Transport Relay Agent sits between IPv6 network and IPv4 341 network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4 342 server. The communication between CRAs and the TRA uses IPv6, while 343 the communication between the TRA and the server uses IPv4. A TRA 344 listens on IPv6 UDP port 67 for DHCP messages with bootp op field = 345 1, as well as IPv4 UDP port 68 for DHCP messages with bootp op field 346 = 2. 348 When relaying a DHCP message from CRA to server, TRA MUST add an 349 option 82 with a CRA6ADDR sub-option. This sub-option contains the 350 IPv6 source address of the message (the CRA's IPv6 address) which is 351 retained when the message is received in IPv6. The TRA MUST also 352 store the IPv4 address of itself in the giaddr field of the DHCP 353 message. The TRA MAY include a Link Selection sub-option [RFC3527] 354 to indicate to the DHCP server which link to use when choosing an IP 355 address. 357 When receiving a DHCP message from the DHCP server, if the option 82 358 in the message contains no CRA6ADDR sub-option, the TRA MUST discard 359 the message. Otherwise, it processes it as required by [RFC3046], 360 and forwards it to the IPv6 address recorded in the CRA6ADDR sub- 361 option, with source port 67 and destination port number 68. TRA 362 SHOULD drop DHCPv4-over-IPv6 traffic that is not originated from 363 configured server address. 365 9. Security Consideration 367 This mechanism may rise a new form of DHCP protocol attack. A 368 malicious attacker in IPv6 can interference with the DHCPv4 process 369 by inject fake DHCPv4-in-IPv6 messages which will be handled by TSV 370 or TRA. However, the damage is the same with the known DHCPv4 attack 371 happened in IPv4. The only difference is the attacker and the victim 372 could locate in different address families. 374 Another impact is DHCP filtering. There are firewalls today capable 375 of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6 376 packages). The DHCP messages with the new, DHCPv4-in-IPv6 style may 377 bypass these firewalls. Nevertheless it is not difficult for them to 378 make some slight modification and adapt to the new DHCPv4 message 379 pattern. 381 10. IANA consideration 383 IANA is requested to assign one new sub-option code from the registry 384 of DHCP Agent Sub-Option Codes maintained in 385 http://www.iana.org/assignments/bootp-dhcp-parameters. This sub- 386 option code will be assigned to the Client Relay Agent IPv6 Address 387 Sub-option. 389 11. Contributors 391 The following gentlemen also contributed to the effort: 393 Francis Dupont 394 Internet Systems Consortium, Inc. 396 Email: fdupont@isc.org 397 Tomasz Mrugalski 398 Internet Systems Consortium, Inc. 400 Email: tomasz.mrugalski@gmail.com 402 Dmitry Anipko 403 Microsoft Corporation 405 Email: danipko@microsoft.com 407 12. Appendix: Discussion on One Host Retrieving Multiple Addresses 408 through One CRA 410 This document is written with the intention of supporting a use case 411 where a single DHCP client is configuring a single tunnel endpoint 412 per physical link. The technique described in this document could be 413 used by a host needing to configure more than one tunnel endpoint on 414 the same physical link, i.e., to retrieve multiple addresses through 415 the same CRA. However, the following additional behavior is REQUIRED 416 to support this case. 418 DHCP server implementing this specification MUST implement Client 419 Identifier Option in DHCP server replies [I-D.ietf-dhc-client-id]. 421 In general this specification is intended not to require modification 422 of DHCP clients. However, DHCP clients being used to configure 423 multiple tunnel endpoints have to be modified; otherwise there is no 424 way for such DHCP clients to differentiate between DHCP responses. 425 Therefore, in such case, the DHCP client using this specification 426 MUST use a different client identifier for each tunnel endpoint being 427 configured. Such DHCP clients MUST examine the response from the 428 DHCP server and use the client identifier to differentiate between 429 the DHCP client state machines for each tunnel endpoint. 431 In order to satisfy the requirement that client identifiers be 432 unique, DHCP clients configuring multiple tunnel endpoints MUST 433 implement Node-specific Client Identifiers for DHCPv4 [RFC4361]. 434 Such clients MUST use a different IAID for each tunnel endpoint. 436 It is assumed here that every client state machine on a multiple- 437 tunnel-endpoint link can hear all the DHCP messages (and subsequently 438 accept the messages intended for it). How this is accomplished is 439 left to the implementor. However, implementations MUST follow this 440 requirement; otherwise, it will be impossible for multiple tunnel 441 endpoints to be successfully configured. The easiest way to 442 accomplish this is to have a single DHCP client process with multiple 443 DHCP state machines, and to dispatch each DHCP message to the correct 444 DHCP client state machine using the client identifier. However, this 445 is not REQUIRED; any mechanism that results in client state machines 446 receiving the messages that are intended for them will suffice. 448 13. References 450 13.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 456 RFC 2131, March 1997. 458 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 459 RFC 3046, January 2001. 461 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 462 "Link Selection sub-option for the Relay Agent Information 463 Option for DHCPv4", RFC 3527, April 2003. 465 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 466 Identifiers for Dynamic Host Configuration Protocol 467 Version Four (DHCPv4)", RFC 4361, February 2006. 469 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 470 Problem Statement", RFC 4925, July 2007. 472 13.2. Informative References 474 [I-D.ietf-dhc-client-id] 475 Swamy, N., Halwasia, G., and S. Unit, "Client Identifier 476 Option in DHCP Server Replies", 477 draft-ietf-dhc-client-id-02 (work in progress), 478 March 2012. 480 [I-D.ietf-dhc-dhcpv4-relay-encapsulation] 481 Lemon, T., Deng, H., and L. Huang, "Relay Agent 482 Encapsulation for DHCPv4", 483 draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (work in 484 progress), July 2011. 486 [I-D.ietf-softwire-public-4over6] 487 Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y. 488 Lee, "Public IPv4 over IPv6 Access Network", 489 draft-ietf-softwire-public-4over6-01 (work in progress), 490 March 2012. 492 Authors' Addresses 494 Yong Cui 495 Tsinghua University 496 Department of Computer Science, Tsinghua University 497 Beijing 100084 498 P.R.China 500 Phone: +86-10-6260-3059 501 Email: yong@csnet1.cs.tsinghua.edu.cn 503 Peng Wu 504 Tsinghua University 505 Department of Computer Science, Tsinghua University 506 Beijing 100084 507 P.R.China 509 Phone: +86-10-6278-5822 510 Email: pengwu.thu@gmail.com 512 Jianping Wu 513 Tsinghua University 514 Department of Computer Science, Tsinghua University 515 Beijing 100084 516 P.R.China 518 Phone: +86-10-6278-5983 519 Email: jianping@cernet.edu.cn 521 Ted Lemon 522 Nominum, Inc. 523 2000 Seaport Blvd 524 Redwood City 94063 525 USA 527 Phone: +1-650-381-6000 528 Email: mellon@nominum.com