idnits 2.17.1 draft-ietf-behave-turn-ipv6-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5153 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) == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-10 ** Obsolete normative reference: RFC 3697 (Obsoleted by RFC 6437) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE G. Camarillo 3 Internet-Draft O. Novo 4 Intended status: Standards Track Ericsson 5 Expires: September 9, 2010 S. Perreault, Ed. 6 Viagenie 7 March 8, 2010 9 Traversal Using Relays around NAT (TURN) Extension for IPv6 10 draft-ietf-behave-turn-ipv6-09 12 Abstract 14 This document adds IPv6 support to Traversal Using Relays around NAT 15 (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, 16 and IPv6-to-IPv4 relaying. This document defines the REQUESTED- 17 ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY 18 attribute allows a client to explicitly request the address type the 19 TURN server will allocate (e.g., an IPv4-only node may request the 20 TURN server to allocate an IPv6 address). 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 9, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 65 4. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Sending an Allocate Request . . . . . . . . . . . . . . . 4 67 4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute . . . . . . . . 4 68 4.2. Receiving an Allocate Request . . . . . . . . . . . . . . 5 69 4.2.1. Unsupported Address Family . . . . . . . . . . . . . . 6 70 4.3. Receiving an Allocate Error Response . . . . . . . . . . . 6 71 5. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 6 72 5.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 6 73 5.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6 74 6. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 6 75 6.1. Sending a CreatePermission Request . . . . . . . . . . . . 6 76 6.2. Receiving a CreatePermission request . . . . . . . . . . . 7 77 6.2.1. Peer Address Family Mismatch . . . . . . . . . . . . . 7 78 7. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 7 80 7.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 7 81 8. Packet Translations . . . . . . . . . . . . . . . . . . . . . 7 82 8.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . . 8 83 8.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . . 9 84 8.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . . 10 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 10.1. New STUN Attribute Registry . . . . . . . . . . . . . . . 12 88 10.2. New STUN Response Code Registry . . . . . . . . . . . . . 12 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 90 12. Normative References . . . . . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn] is a 96 protocol that allows for an element behind a NAT to receive incoming 97 data over UDP or TCP. It is most useful for elements behind 98 symmetric NATs that wish to be on the receiving end of a connection 99 to a single peer. 101 The base specification of TURN [I-D.ietf-behave-turn] only defines 102 IPv4-to-IPv4 relaying. This document adds IPv6 support to TURN, 103 which includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. 104 This document defines the REQUESTED-ADDRESS-FAMILY attribute, which 105 is an extension to TURN that allows a client to explicitly request 106 the address type the TURN server will allocate (e.g., an IPv4-only 107 node may request the TURN server to allocate an IPv6 address). This 108 document also defines and registers new error response codes. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Overview of Operation 118 When a user wishes a TURN server to allocate an address of a specific 119 type, it sends an Allocate Request to the TURN server with a 120 REQUESTED-ADDRESS-FAMILY attribute. TURN can run over UDP and TCP, 121 as it allows for a client to request address/port pairs for receiving 122 both UDP and TCP. 124 Assuming the request is authenticated, the TURN server allocates a 125 transport address of the type indicated in the REQUESTED-ADDRESS- 126 FAMILY attribute. This address is called the allocated transport 127 address. 129 The TURN server returns the allocated address in the response to the 130 Allocate Request. This response contains a XOR-RELAYED-ADDRESS 131 attribute indicating the IP address and port that the server 132 allocated for the client. 134 TURN servers allocate a single relayed-transport-address per 135 allocation request. Therefore, Allocate Requests cannot carry more 136 than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client 137 that wishes to allocate more than one address at a TURN server (e.g., 138 an IPv4 and an IPv6 address) needs to perform several allocation 139 requests (one allocation request per address). 141 A TURN server that supports a set of address families is assumed to 142 be able to relay packets between them. If a server does not support 143 the address family requested by a client, the server returns a 440 144 (Address Family not Supported) error response. 146 4. Creating an Allocation 148 The behavior specified here affects the processing defined in Section 149 6 of [I-D.ietf-behave-turn]. 151 4.1. Sending an Allocate Request 153 A client that wishes to obtain a transport address of a specific 154 address type includes a REQUESTED-ADDRESS-FAMILY attribute, which is 155 defined in Section 4.1.1, in the Allocate Request that it sends to 156 the TURN server. Clients MUST NOT include more than one REQUESTED- 157 ADDRESS-FAMILY attribute in an Allocate Request. The mechanisms to 158 formulate an Allocate Request are described in Section 6.1 of 159 [I-D.ietf-behave-turn]. 161 Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an 162 Allocate request that contains a RESERVATION-TOKEN attribute. 164 4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute 166 The REQUESTED-ADDRESS-FAMILY attribute is used by clients to request 167 the allocation of a specific address type from a server. The 168 following is the format of the REQUESTED-ADDRESS-FAMILY attribute. 169 Note that TURN attributes are TLV (Type-Length-Value) encoded, with a 170 16 bit type, a 16 bit length, and a variable-length value. 172 0 1 2 3 173 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Family | Reserved | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 1: Format of REQUESTED-ADDRESS-FAMILY Attribute 182 Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017. 184 As specified in [RFC5389], attributes with values between 0x0000 and 185 0x7FFF are comprehension-required, which means that the client or 186 server cannot successfully process the message unless it understands 187 the attribute. 189 Length: this 16-bit field contains the length of the attribute in 190 bytes. The length of this attribute is 4 bytes. 192 Family: there are two values defined for this field and specified in 193 [RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6 194 addresses. 196 Reserved: at this point, the 24 bits in the reserved field MUST be 197 set to zero by the client and MUST be ignored by the server. 199 The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate 200 Requests. 202 4.2. Receiving an Allocate Request 204 Assuming the request is authenticated and has not been tampered with, 205 the TURN server processes the Allocate request. If it contains both 206 a RESERVATION-TOKEN and a REQUESTED-ADDRESS-FAMILY, the server 207 replies with a 400 (Bad Request) Allocate Error Response. Following 208 the rules in [RFC5389], if the server does not understand the 209 REQUESTED-ADDRESS-FAMILY attribute, it generates an Allocate Error 210 Response, which includes an ERROR-CODE attribute with response code 211 420 (Unknown Attribute). This response will contain an UNKNOWN- 212 ATTRIBUTE attribute listing the unknown REQUESTED-ADDRESS-FAMILY 213 attribute. 215 If the server can successfully process the request, it allocates a 216 transport address to the TURN client, called the allocated transport 217 address, and returns it in the response to the Allocate Request. 219 As specified in [I-D.ietf-behave-turn], the Allocate Response 220 contains the same transaction ID contained in the Allocate Request 221 and the XOR-RELAYED-ADDRESS attribute that sets it to the allocated 222 transport address. 224 The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address 225 and port. It is encoded in the same way as the XOR-MAPPED-ADDRESS 226 [RFC5389]. 228 If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST 229 allocate an IPv4 transport address to the TURN client. If allocation 230 of IPv4 addresses is disabled by local policy, the server returns a a 231 440 (Address Family not Supported) Allocate Error Response. 233 If the server does not support the address family requested by the 234 client, it MUST generate an Allocate Error Response, and it MUST 235 include an ERROR-CODE attribute with the 440 (Address Family not 236 Supported) response code, which is defined in Section 4.2.1. 238 4.2.1. Unsupported Address Family 240 This document defines the following new error response code: 242 440 (Address Family not Supported): The server did not support the 243 address family requested by the client. 245 4.3. Receiving an Allocate Error Response 247 If the client receives an Allocate error response with the 440 248 (Unsupported Address Family) error code, the client SHOULD NOT retry 249 its request. 251 5. Refreshing an Allocation 253 The behavior specified here affects the processing defined in Section 254 7 of [I-D.ietf-behave-turn]. 256 5.1. Sending a Refresh Request 258 To perform a binding refresh, the client generates a Refresh Request 259 as described in Section 7.1 of [I-D.ietf-behave-turn]. The client 260 MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in its 261 Refresh Request. 263 5.2. Receiving a Refresh Request 265 If a server receives a Refresh Request with a REQUESTED-ADDRESS- 266 FAMILY attribute, and the attribute's value doesn't match the address 267 family of the allocation, the server MUST reply with a 443 (Peer 268 Address Family Mismatch) Refresh Error Response. 270 6. CreatePermission 272 The behavior specified here affects the processing defined in Section 273 9 of [I-D.ietf-behave-turn]. 275 6.1. Sending a CreatePermission Request 277 The client MUST only include XOR-PEER-ADDRESS attributes with 278 addresses of the same address family as the relayed transport address 279 for the allocation. 281 6.2. Receiving a CreatePermission request 283 If an XOR-PEER-ADDRESS attribute contains an address of an address 284 family different than the relayed transport address for the 285 allocation, the server MUST generate an error response with the 443 286 (Peer Address Family Mismatch) response code, which is defined in 287 Section 6.2.1. 289 6.2.1. Peer Address Family Mismatch 291 This document defines the following new error response code: 293 443 (Peer Address Family Mismatch): A peer address was of a 294 different address family than the relayed transport address of the 295 allocation. 297 7. Channels 299 The behavior specified here affects the processing defined in Section 300 11 of [I-D.ietf-behave-turn]. 302 7.1. Sending a ChannelBind Request 304 The client MUST only include a XOR-PEER-ADDRESS attribute with an 305 address of the same address family as the relayed transport address 306 for the allocation. 308 7.2. Receiving a ChannelBind Request 310 If the XOR-PEER-ADDRESS attribute contains an address of an address 311 family different than the relayed transport address for the 312 allocation, the server MUST generate an error response with the 443 313 (Peer Address Family Mismatch) response code, which is defined in 314 Section 6.2.1. 316 8. Packet Translations 318 The TURN specification [I-D.ietf-behave-turn] describes how TURN 319 relays should relay traffic consisting of IPv4 packets (i.e., IPv4- 320 to-IPv4 translations). The relay translates the IP addresses and 321 port numbers of the packets based on the allocation's state data. 322 How to translate other header fields is also specified in 323 [I-D.ietf-behave-turn]. This document addresses IPv4-to-IPv6, IPv6- 324 to-IPv4, and IPv6-to-IPv6 translations. 326 TURN relays performing any translation MUST translate the IP 327 addresses and port numbers of the packets based on the allocation's 328 state information as specified in [I-D.ietf-behave-turn]. The 329 following sections specify how to translate other header fields. 331 As discussed in Section 2.6 of [I-D.ietf-behave-turn], translations 332 in TURN are designed so that a TURN server can be implemented as an 333 application that runs in userland under commonly available operating 334 systems and that does not require special privileges. The 335 translations specified in the following sections follow this 336 principle. 338 The descriptions below have two parts: a preferred behavior and an 339 alternate behavior. The server SHOULD implement the preferred 340 behavior. However, if that is not possible for a particular field, 341 then the server SHOULD implement the alternative behavior. 343 Note that the use of the behaviors specified in the following 344 sections is at the "should" level. Having its use at the "should" 345 level instead of at the "must" level makes it possible to use 346 different translation algorithms that may be developed in the 347 future. 349 8.1. IPv4-to-IPv6 Translations 351 Flow Label 353 Preferred behavior: The relay sets the Flow label to 0. The relay 354 can choose to set the Flow label to a different value if it 355 supports [RFC3697]. 357 Alternative behavior: the relay sets the Flow label to the default 358 value for outgoing packets. 360 Hop Limit 362 Preferred behavior: as specified in Section 3 of 363 [I-D.ietf-behave-v6v4-xlate]. 365 Alternative behavior: the relay sets the Hop Limit to the default 366 value for outgoing packets. 368 Fragmentation 369 Preferred behavior: as specified in Section 3 of 370 [I-D.ietf-behave-v6v4-xlate]. 372 Alternative behavior: the relay assembles incoming fragments. The 373 relay follows its default behavior to send outgoing packets. 375 For both preferred and alternative behavior, the DONT-FRAGMENT 376 attribute ([I-D.ietf-behave-turn], Section 14.8) MUST be ignored 377 by the server. 379 Extension Headers 381 Preferred behavior: the relay sends outgoing packet without any 382 IPv6 extension headers, with the exception of the Fragmentation 383 header as described above. 385 Alternative behavior: same as preferred. 387 8.2. IPv6-to-IPv6 Translations 389 Flow Label 391 The relay should consider that it is handling two different IPv6 392 flows. Therefore, the Flow label [RFC3697] SHOULD NOT be copied as 393 part of the translation. 395 Preferred behavior: The relay sets the Flow label to 0. The relay 396 can choose to set the Flow label to a different value if it 397 supports [RFC3697]. 399 Alternative behavior: the relay sets the Flow label to the default 400 value for outgoing packets. 402 Hop Limit 404 Preferred behavior: the relay acts as a regular router with 405 respect to decrementing the Hop Limit and generating an ICMPv6 406 error if it reaches zero. 408 Alternative behavior: the relay sets the Hop Limit to the default 409 value for outgoing packets. 411 Fragmentation 412 Preferred behavior: If the incoming packet did not include a 413 Fragment header and the outgoing packet size does not exceed the 414 outgoing link's MTU, the relay sends the outgoing packet without a 415 Fragment header. 417 If the incoming packet did not include a Fragment header and the 418 outgoing packet size exceeds the outgoing link's MTU, the relay 419 drops the outgoing packet and send an ICMP message of type 2 code 420 0 ("Packet too big") to the sender of the incoming packet. If the 421 packet is being sent to the peer, the relay reduces the MTU 422 reported in the ICMP message by 48 bytes to allow room for the 423 overhead of a Data indication. 425 If the incoming packet included a Fragment header and the outgoing 426 packet size (with a Fragment header included) does not exceed the 427 outgoing link's MTU, the relay sends the outgoing packet with a 428 Fragment header. The relay sets the fields of the Fragment header 429 as appropriate for a packet originating from the server. 431 If the incoming packet included a Fragment header and the outgoing 432 packet size exceeds the outgoing link's MTU, the relay MUST 433 fragment the outgoing packet into fragments of no more than 1280 434 bytes. The relay sets the fields of the Fragment header as 435 appropriate for a packet originating from the server. 437 Alternative behavior: the relay assembles incoming fragments. The 438 relay follows its default behavior to send outgoing packets. 440 For both preferred and alternative behavior, the DONT-FRAGMENT 441 attribute MUST be ignored by the server. 443 Extension Headers 445 Preferred behavior: the relay sends outgoing packet without any 446 IPv6 extension headers, with the exception of the Fragmentation 447 header as described above. 449 Alternative behavior: same as preferred. 451 8.3. IPv6-to-IPv4 Translations 453 Type of Service and Precedence 454 Preferred behavior: as specified in Section 4 of 455 [I-D.ietf-behave-v6v4-xlate]. 457 Alternative behavior: the relay sets the Type of Service and 458 Precedence to the default value for outgoing packets. 460 Time to Live 462 Preferred behavior: as specified in Section 4 of 463 [I-D.ietf-behave-v6v4-xlate]. 465 Alternative behavior: the relay sets the Time to Live to the 466 default value for outgoing packets. 468 Fragmentation 470 Preferred behavior: as specified in Section 4 of 471 [I-D.ietf-behave-v6v4-xlate]. Additionally, when the outgoing 472 packet's size exceeds the outgoing link's MTU, the relay needs to 473 generate an ICMP error (ICMPv6 Packet Too Big) reporting the MTU 474 size. If the packet is being sent to the peer, the relay SHOULD 475 reduce the MTU reported in the ICMP message by 48 bytes to allow 476 room for the overhead of a Data indication. 478 Alternative behavior: the relay assembles incoming fragments. The 479 relay follows its default behavior to send outgoing packets. 481 For both preferred and alternative behavior, the DONT-FRAGMENT 482 attribute MUST be ignored by the server. 484 9. Security Considerations 486 Translation between IPv4 and IPv6 creates a new way for clients to 487 obtain IPv4 or IPv6 access which they did not have before. For 488 example, an IPv4-only client having access to a TURN server 489 implementing this specification is now able to access the IPv6 490 internet. This needs to be considered when establishing security and 491 monitoring policies. 493 The loop attack described in [I-D.ietf-behave-turn] Section 17.1.7 494 may be more easily done in cases where address spoofing is easier to 495 accomplish over IPv6. Mitigation of this attack over IPv6 is the 496 same as for IPv4. 498 All the security considerations applicable to STUN [RFC5389] and TURN 500 [I-D.ietf-behave-turn] are applicable to this document as well. 502 10. IANA Considerations 504 The IANA is requested to register the following values under the STUN 505 Attributes registry and under the STUN Response Code Registry. 507 10.1. New STUN Attribute Registry 509 0x0017: REQUESTED-ADDRESS-FAMILY 511 10.2. New STUN Response Code Registry 513 440 Address Family not Supported 514 443 Peer Address Family Mismatch 516 11. Acknowledgements 518 The authors would like to thank Alfred E. Heggestad, Dan Wing, Magnus 519 Westerlund, Marc Petit-Huguenin, Philip Matthews, and Remi Denis- 520 Courmont for their feedback on this document. 522 12. Normative References 524 [I-D.ietf-behave-turn] 525 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 526 Relays around NAT (TURN): Relay Extensions to Session 527 Traversal Utilities for NAT (STUN)", 528 draft-ietf-behave-turn-16 (work in progress), July 2009. 530 [I-D.ietf-behave-v6v4-xlate] 531 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 532 Algorithm", draft-ietf-behave-v6v4-xlate-10 (work in 533 progress), February 2010. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 539 "IPv6 Flow Label Specification", RFC 3697, March 2004. 541 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 542 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 543 October 2008. 545 Authors' Addresses 547 Gonzalo Camarillo 548 Ericsson 549 Hirsalantie 11 550 Jorvas 02420 551 Finland 553 Email: Gonzalo.Camarillo@ericsson.com 555 Oscar Novo 556 Ericsson 557 Hirsalantie 11 558 Jorvas 02420 559 Finland 561 Email: Oscar.Novo@ericsson.com 563 Simon Perreault (editor) 564 Viagenie 565 2600 boul. Laurier, suite 625 566 Quebec, QC G1V 4W1 567 Canada 569 Phone: +1 418 656 9254 570 Email: simon.perreault@viagenie.ca 571 URI: http://www.viagenie.ca