idnits 2.17.1 draft-ietf-ngtrans-dstm-06.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? == Mismatching filename: the document gives the document name as 'draft-ietf-ngtrans-dstm-05', but the file name used is 'draft-ietf-ngtrans-dstm-06' == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 46 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Missing Reference: '10' is mentioned on line 422, but not defined == Unused Reference: '5' is defined on line 502, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 511, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2406 (ref. '3') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2893 (ref. '6') (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 2462 (ref. '8') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2373 (ref. '9') (Obsoleted by RFC 3513) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-16 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jim Bound 2 NGTRANS Working Group Compaq 3 Obsoletes draft-ietf-ngtrans-dstm-05.txt Laurent Toutain 4 Expires May 2002 Octavio Medina 5 Francis Dupont 6 ENST Bretagne 7 Hossam Afifi 8 INT 9 Alain Durand 10 Sun Microsystems 12 Dual Stack Transition Mechanism (DSTM) 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 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 To view the entire list of current Internet-Drafts, please check the 38 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 39 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 40 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 41 ftp.isi.edu (US West Coast). 43 Distribution of this memo is unlimited. 45 Abstract 47 During the initial deployment of IPv6, hosts in native IPv6 networks 48 will need to maintain connectivity with hosts and/or applications who 49 can only be reached through IPv4. The Dual Stack Transition Mechanism 50 (DSTM) provides a method to assure this connectivity based on the use 51 of IPv4-over-IPv6 tunnels and the temporal allocation of a global 52 IPv4 address to hosts requiring such communication. This document 53 defines the processes and architecture required for this transition 54 mechanism. 56 Table of Contents: 58 1. Introduction ............................................. 3 59 2. Terminology .............................................. 4 60 2.1 IPv6 DSTM Terminology ................................... 4 61 2.2 Specification Language ................................... 5 62 3. DSTM Overview and Assumptions ............................ 5 63 4. DSTM Host Requirements ................................... 7 64 4.1 Configuration of the IPv4 stack ......................... 7 65 4.2 IPv4 packet forwarding .................................. 8 66 4.3 DSTM processing of IPv4 packets .......................... 8 67 4.4 IPv6 packet construction ................................. 8 68 5. DSTM Server Requirements .................................. 9 69 6. Applicability Statement ................................... 9 70 7. Security Considerations ................................... 10 71 Acknowledgments ............................................. 12 72 Normative References ........................................ 12 73 Informative References ...................................... 12 74 Authors' Address ............................................ 13 76 1. Introduction 78 The initial deployment of IPv6 will require a tightly coupled use of 79 IPv4 addresses to support the interoperation of IPv6 and IPv4 within 80 an IPv6-only Network. Nodes will still need to communicate with IPv4 81 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. 82 The Dual Stack Transition Mechanism (DSTM) is based on the use of 83 IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6-only 84 network and provides a method to allocate a temporary IPv4 Address to 85 IPv6/IPv4 nodes. 87 DSTM is targeted to help the interoperation of IPv6 newly deployed 88 networks with existing IPv4 networks. Since the IPv4 globally 89 routable address space available is becoming a scarce resource, it is 90 assumed that users may deploy IPv6 to reduce the need and reliability 91 on IPv4 within a portion of their networks. In this specific 92 scenario, DHCPv4[7] can not be directly used to assign IPv4 addresses 93 to IPv6 nodes, since no IPv4 connectivity is maintained in the 94 network. 96 When DSTM is deployed in a network, an IPv4 address is allocated to a 97 dual stack node if the connexion can not be established using IPv6. 98 This allows either IPv6 nodes to communicate with IPv4-only nodes, or 99 IPv4-only applications to run on an IPv6 node without modification. 100 This allocation mechanism is coupled with the ability to perform 101 IPv4-over-IPv6 (4over6) tunnelling, hiding IPv4 packets inside the 102 native IPv6 domain. This simplifies network management: only the IPv6 103 routing plan is managed inside the network. 105 The DSTM architecture is composed of an address server (DSTM server), 106 a gateway and a number of hosts (DSTM hosts). The address server is 107 in charge of IPv4 address allocation to client nodes. This 108 allocation is very simple since there is no localisation purpose in 109 this address. The DSTM server has just to guaranty the uniqueness of 110 the IPv4 address for a period of time. The gateway, or Tunnel End 111 Point (TEP), can be seen as a border router between the IPv6-only 112 domain and an IPv4 internet or intranet. This node performs 113 encapsulation/decapsulation of packets to assure bi-directional 114 forwarding between both networks. Finally, in order to assure IPv4 115 connectivity, hosts in the IPv6-only domain should be able to 116 dynamically configure their IPv4 stack (by asking the server for a 117 temporary address) and must be capable to establish 4over6 tunnels 118 towards a Tunnel End Point. 120 This specification begins by the definition of the terminology 121 (section 2). Section 3 provides a technical overview of the DSTM 122 methodology as a transition mechanism. In section 4, the 123 requirements for DSTM hosts is presented. Section 5 describes the 124 DSTM server requirements. Finally, section 6 provides the DSTM 125 Applicability Statement. 127 2. Terminology 129 2.1 IPv6 DSTM Terminology 131 DSTM Domain The network areas on an Intranet where IPv6 nodes 132 use DSTM to assure IPv4 communication. An IPv4 133 address allocation server may be deployed inside the 134 domain to manage an IPv4 address pool. IPv4 routing 135 access may not be maintained within a DSTM domain. 137 DSTM Server A process in charge of managing the IPv4 address 138 space that will be allocated to DSTM Nodes. 140 Tunnel End Point (TEP) Destination of IPv6 flows containing IPv4 packets. 141 It assures the forwarding function between the DSTM 142 domain and a given IPv4 network. 144 4over6 Tunnelling Encapsulation of IPv4 packets over IPv6. Used for 145 carrying IPv4 flows from one node to another in a 146 DSTM Domain. 148 DSTM Node A Node that supports both IPv4 and IPv6 stacks and 149 4over6 tunnelling. The DSTM node generates only IPv6 150 packets on the network. 152 DSTM Client A process on a DSTM Host who manages 153 the temporary IPv4 address allocated by the 154 DSTM Server. 156 DSTM Host A terminal equipment implementing 4over6 157 tunnelling and dynamic IPv4 address configuration. A 158 DSTM Host is a DSTM Node running a DSTM client 159 process. 161 IPv6 Protocol Terms: See [1] 163 IPv6 Transition Terms: See [6] 165 DHCPv6 Terms: See [2] 167 2.2 Specification Language 169 In this document, several words are used to signify the requirements 170 of the specification, in accordance with RFC 2119 [4]. These words 171 are often capitalized. 173 MUST This word, or the adjective "required", means that 174 the definition is an absolute requirement of the 175 specification. 177 MUST NOT This phrase means that the definition is an absolute 178 prohibition of the specification. 180 SHOULD This word, or the adjective "recommended", means 181 that there may exist valid reasons in particular 182 circumstances to ignore this item, but the full 183 implications must be understood and carefully 184 weighed before choosing a different course. 185 Unexpected results may result otherwise. 187 MAY This word, or the adjective "optional", means that 188 this item is one of an allowed set of alternatives. 189 An implementation which does not include this option 190 MUST be prepared to interoperate with another 191 implementation which does include the option. 193 silently discard 194 The implementation discards the packet without 195 further processing, and without indicating an error 196 to the sender. The implementation SHOULD provide 197 the capability of logging the error, including the 198 contents of the discarded packet, and SHOULD record 199 the event in a statistics counter. 201 3. DSTM Overview and Assumptions 203 DSTM, as discussed in the introduction, is a method that uses 204 existing protocols. This document does not specify a new protocol. 205 However, DSTM defines host, server and TEP behaviours as well as the 206 properties of the temporary addresses allocation mechanism. 208 The motivation for DSTM is to provide IPv6 hosts a means to acquire 209 an IPv4 address, for communications with IPv4-only hosts or through 210 IPv4 applications. 212 The core assumption within this mechanism is that it is totally 213 transparent to applications, which can continue to work with IPv4 214 addresses. It is also transparent to the network, where only IPv6 215 packets are carried. It is the authors' viewpoint that the user, in 216 this case, has deployed IPv6 to support end to end computing without 217 translation. This aspect is fundamental during a transition process 218 to guarantee that every existing application will continue to work 219 (e.g. IPsec, H.323), despite of the presence of IPv4 addresses in the 220 payload of a packet. 222 The following assumptions describe the model used by DSTM: 224 - A DSTM domain is within an Intranet not on the Internet. 226 - IPv6 nodes do not maintain an IPv4 address except on a temporary basis, 227 to communicate with IPv4-only nodes and/or IPv4 applications. 229 - The temporary IPv4 address allocation is performed by the DSTM server. 230 Different protocols (DHCPv6 being the logical choice) can be used 231 for the allocation process. Native IPv6 communication between server and 232 client is one restriction in this matter. 234 - As an extension to the address allocation process, the DSTM server may also 235 provide a range of port numbers to be used by the client. This would allow 236 the use of the same IPv4 address by several DSTM hosts at the same time, 237 reducing the size of the required IPv4 address pool. 239 - Inside a DSTM domain, IPv4 routing tables are kept to a minimum on 240 behalf of IPv6 routing, hence, reducing the network management required 241 for IPv4 during transition. 243 - Once an IPv6 node has obtained an IPv4 address (and maybe a port range), 244 4over6 tunnelling is used to forward packets from the host to a DSTM TEP, 245 where the packet is decapsulated and forwarded using IPv4. As part of the 246 address allocation process, the DSTM server SHOULD provide the client with 247 the IPv6 address of the TEP to be used. 249 - Existing IPv4 applications do not need to be modified to run on DSTM nodes. 251 - A DSTM Node can communicate with any IPv4-only host, as long as the 252 destination address is reachable from the TEP used by the node. 254 A schematic overview of DSTM is as follows: 256 ----------------------------------------------- 257 DSTM Domain (Intranet) | IPv4 Internet or Intranet 258 | IPv4 Applications 259 +---------------------+ | Domain 260 | DSTM Server | | 261 +---------------------+ | 262 ^ ^ | 263 | | | 264 +----DSTM Host----+ | | 265 | | | | +--------+ 266 | IPv6/IPv4 Node | | - - - - - >| DSTM | 267 | | | | TEP | 268 |-----------------| | | | 269 | DSTM client |<-------+ | IPv6 |--------------> 270 |-----------------| | & | IPv4 271 | 4over6 iface |<=====================>| IPv4 | 272 +-----------------+ IPv4 over IPv6 +--------+ 273 tunnel | 274 IPv6-only Network | 275 ---------------------------------------------- 277 For an IPv6 node to participate in DSTM it MUST have a dual IP layer, 278 supporting both an IPv4 and an IPv6 stack. DSTM is not a solution 279 for IPv6 ONLY nodes. 281 4. DSTM Host Requirements. 283 4.1 Configuration of the IPv4 stack 285 As long as communications can take place in native IPv6, no IPv4 286 address is given to the DSTM host. The host can detect the need of an 287 IPv4 address by different methods: when a query to the DNS resolver 288 results in an IPv4 destination address, when an application opens an 289 IPv4 socket, or when an IPv4 packet is sent to the kernel and no 290 interface is ready to forward that packet. 292 When the first IPv4 packet needs to be sent, the DSTM client MUST 293 contact the DSTM server to obtain a temporary IPv4 address as well as 294 the IPv6 address of a TEP. If allowed by the implementation, the 295 server MAY also provide the port range to be used. This information 296 is used to configure the 4over6 interface. It is at this point that 297 the IPv4 stack is configured. 299 4.2 IPv4 packet forwarding 301 In the absence of an IPv4 routing infrastructure, a DSTM node can not 302 directly send IPv4 packets on the network. It has to encapsulate them 303 into IPv6 packets and send them to a Tunnel End Point (which can be 304 seen as a particular DSTM node) that will decapsulate the packet and 305 forward them into the IPv4 network. 307 On a DSTM node, this encapsulation is done by a 4over6 interface. 308 All IPv4 traffic can be directed to that interface by an IPv4 routing 309 table entry. The exact details of the 4over6 interface and the 310 associated routing table entries are implementation dependant. 312 4.3 DSTM processing of IPv4 packets 314 When a DSTM Node needs to send an IPv4 packet, it is sent to the 315 4over6 interface. If the 4over6 interface is not configured (it does 316 not have an IPv4 address), the process SHOULD be blocked and the DSTM 317 Server SHOULD be contacted to get a temporary address. Once an 318 address is allocated, it is used as the IPv4 source address for all 319 the packets leaving the interface. The other fields of the IPv4 320 packet are normally filled. 322 4.4 IPv6 packet construction 324 When the 4over6 interface encapsulates an IPv4 packet into an IPv6 325 packet, it has to determine the IPv6 destination address. Usually, 326 this will be the address of a TEP. At the node, the address of the 327 TEP can be either statically configured or dynamically acquired when 328 the DSTM host obtains an IPv4 address from the DSTM Server. 330 The IPv6 address of the TEP SHOULD be provided by the DSTM server 331 when the DSTM node receives a temporary IPv4 address (section 5). 332 However, a DSTM node MAY manually configure the TEP during early 333 deployment of DSTM. This will not scale and is not recommended as a 334 long term transition solution. 336 The next header type for encapsulation of IPv4 is 4 (as for IPv4 337 tunnelling over IPv4). When a tunnelled packet arrives to the IPv6 338 destination, the IPv6 header is removed and the packet is processed 339 by the IPv4 layer. The IPv4 packet will then be forwarded by the TEP 340 using the IPv4 infrastructure. The TEP SHOULD cache the association 341 between the IPv4 and IPv6 source addresses. 343 The IPv6 source address of an encapsulated packet SHOULD be the IPv6 344 address of the physical interface on which the IPv6 packet will be 345 sent. 347 5. DSTM Server Requirements 349 The DSTM server is in charge of the temporary IPv4 address 350 allocation. This allocation is very simple since there is no 351 localisation purpose in this address. The DSTM server has just to 352 guaranty the uniqueness of the IPv4 address for a period of time. To 353 reduce the need of IPv4 addresses, some implementations MAY include a 354 port range as part of the allocation process. This would allow the 355 use of the same IPv4 address by several hosts simultaneously. 357 The DTSM server MUST memorize the mapping between the IPv6 address of 358 the node requesting an address and the allocated IPv4 address. The 359 IPv4 address is allocated by the server for a fixed amount of time. 360 This duration MUST be included in the response. If the client needs 361 the IPv4 address for a longer period of time, the client MUST renew 362 the lease. 364 Routing in the IPv4 realm MUST ensure that the pool of IPv4 global 365 addresses managed by a DSTM server is routed to one or more TEPs in 366 the DSTM domain. When allocating an address to a DSTM Node, the 367 server message SHOULD include the IPv6 address of the TEP in charge 368 of the allocated address. Additionally, the DSTM Server MAY be in 369 charge of configuring the IPv4/IPv6 mapping table at the TEP, if it 370 can not be constructed dynamically or dynamic construction is 371 disabled for security reasons. 373 The communication between the DSTM client and the server MUST be in 374 IPv6. 376 The DSTM server MAY allocate a temporary IPv4 address without a 377 request from he client. 379 The DSTM server SHOULD be able to authenticate the DSTM client. 381 6. Applicability Statement 383 DSTM is applicable for use from within a DSTM Domain in which hosts 384 need to communicate with IPv4-only hosts or through IPv4-only 385 applications on a user Intranet or over the Internet. 387 The motivation of DSTM is to allow dual IP layer nodes to communicate 388 using global IPv4 addresses across an Intranet or Internet, where 389 global addresses are required. However, the mechanisms used in DSTM 390 can also be deployed using private IPv4 addresses to permit the 391 Intranet use of DSTM where users require temporary access to IPv4 392 services within their Intranet. 394 In DSTM, a mechanism is needed to perform the address allocation 395 process. This can be decoupled in two functions: the management of 396 the IPv4 address pool and the communication protocol between server 397 and clients. A number of mechanisms, like DHCPv6, can perform these 398 functions. The choice of the method to be used is a decision of the 399 DSTM Domain administrator. 401 The exact capacities of the 4over6 tunnelling interface required by 402 DSTM is implementation defined. Optionally, it is allowed that DSTM 403 nodes configure manually (in a static manner) the tunnel to the TEP; 404 but the recommendation is not to do this. The dynamic configuration 405 of 4over6 interfaces as a result of the address allocation process is 406 the right way to execute DSTM on an IPv6 Network. 408 DSTM also assumes that all packets returning from an IPv4 node to a 409 DSTM node are routed through the originating DSTM TEP who maintains 410 the association of the node's IPv4/IPv6 addresses. At this time it 411 is beyond the scope of this proposal to permit IPv4 packets destined 412 to a DSTM node to be forwarded through a non-originating DSTM TEP. 414 A line for future work on DSTM may include the support of multiple 415 TEPs for returning IPv4 packets and the discovery of DSTM nodes using 416 IPv4 DNS queries. 418 7. Security Considerations 420 The DSTM mechanism can use all of the defined security specifications 421 for each functional part of its operation. For DNS, the DNS Security 422 Extensions/Update can be used [9, 10]. Concerning address allocation 423 protocols, if DHCPv6 is deployed, the DHCPv6 Authentication Message 424 can be used [2]. Finally, for IPv4 communications on DSTM nodes, once 425 the node has an IPv4 address, IPsec [3] can be used since DSTM does 426 not break secure end-to-end communications at any point. 428 Changes from draft 03 to draft 04 430 1. Changed DHCPv6 options and processing to comply with 431 draft-ietf-dhc-dhcpv6-16.txt 433 Changes from draft 02 to draft 03 434 1. Working Group Edits 436 Changes from draft 01 to draft 02 438 1. Added futher clarifications to DSTM components. 440 2. Added client/server details for DHCPv6 ngtrans extension. 442 3. Removed optional scenarios to simplify this mechanism. 444 4. Removed AIIH concepts and changed to be DSTM components. 446 5. Add Applicability Statement 448 6. Added acknowledgment section and new coauthors Francis Dupont 449 and Alain Durand. 451 Changes from draft 00 to draft 01 453 1. Added text explaining why the draft does not use DHCPv4 to assign 454 IPv4 compatible addresses to the "Introduction". 456 2. Defined what is mandatory and what is optional and added relative 457 text in various places to clarify this change. And added RFC 458 2119 adjectives to the spec where appropriate. 460 3. Scenario 1 where IPv6 node wants to communicate with IPv4 461 node is mandatory. 463 4. Scenarios 2 and 3 are now optional where an IPv6 node is 464 assigned an IPv4 compatible address because an external 465 IPv4 node is attempting communications with the IPv6 node. 467 5. For scenario 1 DHCPv6 is only needed for DSTM and not the 468 tightly coupled paradigm of a co-existent DHCPv6 and 469 DNS server. Also added mandatory and optional to the 470 DSTM AIIH/NODE/ROUTER Diagram. 472 6. Made Static Tunnel Endpoints mandatory and Dynamic Tunnel 473 End Points optional. 475 7. Fixed DHCPv6 Reconfigure statements to take into account 476 changes to the Reconfigure message in the DHCPv6 working 477 group, to support AIIH processing. 479 Acknowledgments 481 The authors would like to acknowledge the implementation 482 contributions by Stephane Atheo at ENST Bretagne who has implemented 483 a DSTM prototype on FreeBSD and input to this specification. We 484 would also like to thank the NGTRANS Working Group for their input. 486 Normative References 488 [1] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 489 Architecture", RFC 2460, December 1998. 491 [3] IPSEC - 492 S. Kent, R. Atkinson. Security Architecture for the Internet 493 Protocol. RFC 2401, November 1998. 494 S. Kent, R. Atkinson. IP Authentication Header. 495 RFC 2402, November 1998. 496 S. Kent, R. Atkinson. IP Encapsulating Security Payload 497 RFC 2406, November 1998. 499 [4] S. Bradner. Key words for use in RFCs to indicate Requirement 500 Levels. RFC 2119, March 1997. 502 [5] A. Conta and S. Deering. Generic Packet Tunneling in IPv6. 503 RFC 2473, December 1998. 505 [6] R. Gilligan and E. Nordmark. Transition Mechanisms for IPv6 506 Hosts and Routers. RFC 2893, August 2000. 508 [7] R. Droms. Dynamic Host Configuration Protocol. 509 RFC 2131, March 1997. 511 [8] Thomson, Narten. IPv6 Stateless Address Configuration. 512 RFC 2462, December 1998. 514 [9] Hinden, Deering. IP Version 6 Addressing Architecture. 515 RFC 2373, July 1998. 517 Informative References 519 [2] J. Bound, M. Carney, C. Perkins, and R. Droms. Dynamic Host 520 Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6-16.txt 521 October 2001 (work in progress). 523 Authors' Address 525 Jim Bound 526 Compaq Computer Corporation 527 110 Spitbrook Road 528 Nashua, NH 003062 529 USA 531 Laurent Toutain 532 ENST Bretagne 533 BP 78 534 35512 Cesson Sevigne Cedex 535 Phone : +33 2 99 12 70 26 536 Email : Laurent.Toutain@enst-bretagne.fr 538 Octavio Medina 539 ENST Bretagne 540 BP 78 541 35512 Cesson Sevigne Cedex 542 Phone : +33 2 99 12 70 23 543 Email / Octavio.Medina@enst-bretagne.fr 545 Hossam Afifi 546 INT 547 91011 Evry 548 Phone : +33 1 60 76 40 40 549 Email : Hossam.Afifi@int-evry.fr 551 Francis Dupont 552 ENST Bretagne 553 BP 78 554 35 512 Cesson Sevigne Cedex 555 Phone : +33 2 99 12 70 33 556 Email : Francis.Dupont@enst-bretagne.fr 558 Alain Durand 559 Sun Microsystems 560 901 San Antonio Road 561 UMPK 17-202 562 Palo Alto, CA 94303-4900 563 Tel: +1 650 786 7503 564 Fax: +1 650 786 5896 565 Email: Alain.Durand@sun.com