idnits 2.17.1 draft-sun-openv6-problem-statement-01.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 (February 13, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6241' is mentioned on line 411, but not defined == Unused Reference: 'RFC2119' is defined on line 449, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-07 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-06 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-05 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Sun 3 Internet-Draft China Telecom 4 Intended status: Informational W. Liu 5 Expires: August 17, 2014 C. Zhou 6 Huawei Technologies 7 G. Leclanche 8 Viagenie 9 February 13, 2014 11 Problem Statement for Openv6 Scheme 12 draft-sun-openv6-problem-statement-01 14 Abstract 16 This document assesses the variety and complexity of IPv6 17 deployments, and proposes a new space of study to simplify the 18 enablement of new IPv6 applications on an existing network. The 19 document evaluates the identified technical gaps as well. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 17, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Problem Extent and Existing Work . . . . . . . . . . . . . . 3 58 3.1. Variety of IPv6 deployment technologies . . . . . . . . . 3 59 3.2. Complexity of IPv6 operation . . . . . . . . . . . . . . 5 60 3.2.1. End-to-End Network Management . . . . . . . . . . . . 5 61 3.2.2. Open Network Business Capabilities . . . . . . . . . 6 62 3.3. Existing evaluations of the IPv6 Transition Landscape . . 7 63 4. Alternative Approach to IPv6 applications enablement . . . . 8 64 5. Existing protocols and methods for the alternate approach . . 9 65 6. Missing protocols and methods for the alternate approach . . 9 66 6.1. Dynamic devices forwarding table configuration . . . . . 9 67 6.2. Address Management . . . . . . . . . . . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7.1. Source Address Validation and Traceback with Openv6 . . . 10 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 11.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 The exhaustion of the IPv4 address space has been a practical problem 81 that providers are facing today. Network address migration to IPv6 82 is ongoing or upcoming throughout the world. However, IPv6 83 activation requires costly end-to-end network upgrades and different 84 network scenarios will co-exist during IPv6 transition. In addition, 85 the technologies deployed for the transition are suppose to be 86 obsoleted once the transition is completed. 88 This document proposes a new approach to deploy and operate IPv6 89 applications on a network, whether related to transition technologies 90 or purely native ones. Such a technology would allow to continue 91 using the same equipments and operational practices for various 92 deployment scenarios. 94 2. Terminology 96 3. Problem Extent and Existing Work 98 3.1. Variety of IPv6 deployment technologies 100 The IPv6 transition period contains three stages for IP Networks: 101 IPv4-only, dual-stack and IPv6-only. The networks should support 102 both IPv4 services and IPv6 services during each 103 stage.[One-vision-for-IPv6] 105 There are multiple IPv6 transition technologies for different network 106 scenarios (e.g. IPv4 network for IPv4/IPv6 user access, IPv6 network 107 for IPv4/IPv6 user access, IPv4 servers for IPv6 visitors, etc.). 108 Different network scenarios will co-exist during the IPv6 transition 109 period, which means the devices implementing the IPv6 transition 110 technology should support the array of technologies, or there has to 111 be as many devices as technologies used in a given network. The 112 following scenarios below will happen during the IPv6 transition 113 period : 115 Scenario 1: An IPv6 host visits IPv6 servers via an IPv4 access 116 network 118 Scenario 2: An IPv4 host visits IPv4 servers via an IPv4 NAT Dual- 119 stack network 121 Scenario 3: An IPv6 host visits IPv6 servers via an IPv6 network 123 Scenario 4: An IPv4 host visits IPv4 servers via an IPv6 access 124 network 126 Scenario 5: IPv4 host and IPv6 host interaction 128 Different transition mechanisms may have different impacts on user 129 experience. For example, DS-Lite would have some impact due to 130 address sharing compared to 6rd mechanisms, and NAT64 would have 131 extra impact due to ALG issue. An operator having a diverse customer 132 base might have to deploy different transition technologies for a 133 given scenario depending on the required user experience. This 134 implies that it is useful to support multiple transition mechanisms 135 in the same area, and preferably on the same transition devices. 137 Another use case is that multiple scenarios may exist in the same 138 stage. For example, if there are both IPv6-only devices and 139 IPv4-only host in the same area with limited public IPv4 address, 140 both NAT64 and NAT44 (or DS-Lite) are required to achieve IPv4 141 service connectivity. 143 The current implementations normally use a separate instance for each 144 mechanism, and additional policies need to be applied when running 145 multiple mechanisms in one device. Some have a limitation on the 146 number of policies that can be configured in one device, while some 147 have restrictions regarding the resource occupation (e.g. one 148 transition instance will use a static amount of memory). The major 149 challenges of IPv6 deployment mainly lie in two aspects: 151 The need to implement different IPv6 transition technologies in 152 the same hardware and the need to support this by upgrading 153 network devices as little as possible. 155 The need to hop over legacy infrastructures which are not IPv6 156 enabled, costly or impossible to upgrade. 158 The issues are: 160 1. How to support multiple transition mechanisms in a cost- 161 efficient and flexible way ? 163 2. How to easily identify the transition type of different 164 subscribers ? 166 A random operator will most likely not go through each scenario one 167 by one. For example, some operators may start from scenario 1, and 168 some may start directly from scenario 2 or scenario 4. However, 169 since the target scenario is the IPv6-only access network, a single 170 operator will be confronted to multiple scenarios on the long term. 172 In such a case, the operator should either upgrade existing devices 173 to support new features, or replace them with new ones. In 174 particular, when the operator's network consists of devices from 175 different vendors, it is difficult to guarantee that all the legacy 176 devices can be upgraded at the same time. This is costly and 177 operationally complicated. 179 We call Transition Data Plane (TDP) the data forwarding plane of the 180 operator network during the whole transition period. Issues that can 181 be identified to improve the situation are: 183 1. How to manipulate Transition Data Plane with different modes? 185 2. How to identify the capabilities of different transition 186 devices ? 188 3. How does the Transition Data Plane identify different modes in 189 the unified platform ? 191 3.2. Complexity of IPv6 operation 193 3.2.1. End-to-End Network Management 195 3.2.1.1. Scattered Address Pool Management 197 When operators are facing the IPv4 address shortage problem, the 198 remaining IPv4 address pools are usually quite scattered. It is 199 quite complicated for an operator to manage scattered address pools 200 in many transition devices. The situation will become even worse 201 when multiple transition mechanisms in the same device need to be 202 configured with different address pools. Besides, the occupation of 203 the address pools may vary during different transition periods: when 204 there is not many IPv6-enabled services and IPv6-enabled devices, 205 IPv4 traffic will still represent a great portion of the total 206 traffic, while in the later stage of IPv6 transition, IPv4 traffic 207 will decrease and the amount of allocated IPv4 addresses may decrease 208 as well, depending on customer requirements. 210 A solution could be to manage the address pools centrally. Different 211 transition mechanisms can require the address pools on-demand. For 212 example, when one transition mechanism is running out of the current 213 address pools, it may request a additional address pool. It can also 214 release the address pools that it is not using any longer. In this 215 way, operators do not need to configure the address pools one by one 216 manually and it also helps using the address pools more efficiently. 218 Fixing this problem implies solving those issues: 220 1. How to configure the address pools for different mechanisms ? 222 2. How to collect the current status of address pool usage ? 224 3.2.1.2. Source Address Validation and Traceback with Openv6 226 It has been long known the IPv4/IPv6 transition makes the tracking 227 and validating of source IP address challenging. Whenever an IPvX 228 packet is translated into an IPvY packet, a major change happens to 229 the IP packet, which brings new issues: 231 1. How to track the origin of the IPvY packet which is actually 232 in the IPvX world? 234 2. How to validate the IPvX packet at the edge of the IPvY world 235 to prevent possible spoofing? 237 3. How to protect the IPvY address from being spoofed in the IPvY 238 world? 240 SAVI[RFC7039] defines the source address validation solutions for 241 both IPv4 and IPv6, but doesn't cover the scenario where an IPv4/IPv6 242 transition technology is used in the network. Currently designing a 243 solution for the transition scenario is not an easy task. There are 244 two main challenges: 246 1. the diversity of IPv4/IPv6 transition mechanisms. There have been 247 a number of transition mechanism. Moreover, new transition 248 mechanisms may be standardized in the future. It would be complex 249 for a SAVI solution to understand each transition mechanism. An 250 unified abstraction of the transition mechanisms (for example, an 251 abstract Openv6 Transition Data Plan (TDP)) and a set of unified open 252 interfaces should be provided by Openv6 to the SAVI solution for the 253 transition scenario. Then the SAVI solution could know the 254 correspondences between the two IP protocols without having to 255 inspect each packet or keep heavy state locally. The SAVI solution 256 can then generate filtering rules and process tracking. 258 2. the inflexibility of SAVI. Currently SAVI solutions are tightly 259 associated with address assignment mechanisms. It should be noted 260 that each IPv4/IPv6 transition mechanism actually introduce a new 261 mechanism to assign valid IPv4/IPv6 addresses. Based on the current 262 model of SAVI, the SAVI solution for the transition scenario should 263 be able to track the address translation in all the transition 264 mechanism. Such a SAVI solution is heavy and costly for switches. 265 The SAVI solution should introduce flexibility in rule generation 266 similarly as Openv6, which offloading the complexity from network 267 devices to a controller. 269 3.2.2. Open Network Business Capabilities 271 3.2.2.1. Dynamic QoS guarantee in IPv6 transition period 273 Traditionally, almost all bandwidth on the Internet is shared, or 274 with a pre-configured QoS class. However, since the QoS requirements 275 by different applications are not always the same, the subscribers 276 should either waste money by paying for a higher bandwidth service, 277 or can not get qualified service when needed. Therefore, currently, 278 operators are tending to provide more dynamic QoS guarantee for 279 subscribers so that they may apply for a higher bandwidth on-demand 280 when they needed, or specific QoS guarantee can be applied for a 281 certain amount of applications. In this case, the QoS adjustment 282 platform is needed to pass the QoS adjustment request from 283 subscribers or application servers dynamically. 285 In IPv6 transition period, the situation will become more 286 complicated. When CGNs are introduced in the network, ip address and 287 port will change during the translation or tunnelling process. For 288 some solutions, e.g. NAT444, DS-Lite, etc., the mappings might be 289 different for different sessions. 291 In this case, the QoS adjustment platform should have the ability to 292 pass and acquire QoS requirements for certain mappings in the CGNs. 293 Therefore, more flexibility should be introduced in the network to 294 load the dynamic QoS requests to the forwarding devices, no matter 295 whether it is a tunnelling or translating mapping. 297 3.2.2.2. Coordinated NAT translation 299 Traditionally, most peer-to-peer applications would deploy relays by 300 their own to achieve NAT traversal. They may use different kinds of 301 ways e.g. TURN, STUN, or use some private protocols for their own 302 purpose. It would not only cost a lot for applications deploy 303 multiple relays, but also introduces a lot of complexity for newly 304 emerging applications. In addition, in IPv6 transition period, there 305 would be more CGNs than before which might make it more difficult for 306 applications to achieve NAT traversal. 308 However, when operators have deployed some kinds of CGNs in their 309 network, it is reasonable for operators to provide NAT traversal 310 service for third-party applications so that the applications do not 311 need to deploy the relays by their own. For example, the third-party 312 application may require the CGN with the transport address, reflect 313 address, etc., and then choose the one to use for the specific NAT 314 situation. It can also be applied when IPv6 client communicates with 315 iPv4 client with similar procedure. In this case, a centralized 316 controller is needed to acquire the requests from third-party 317 applications and form the specific mappings for them. 319 3.3. Existing evaluations of the IPv6 Transition Landscape 321 This paragraph references work done at the IETF or to describe the 322 complex landscape of transition technologies. 324 The different network environments (architecture, scale, services 325 deployed, varying IP traffic) cause a variety of IPv6 transition 326 technologies for different operators. This section analyses the 327 current and future coexistence of IPv6 transition technologies 328 situation as well as the issues behind it. 330 Since IPv6 was proposed, there have been a couple of RFCs and on- 331 going documents in IETF, as listed in the table below. 333 +--------+---------+------------------------------------------------+ 334 | status | number | documents | 335 +--------+---------+------------------------------------------------+ 336 | RFC | 8 or | [RFC5571], [RFC6333], [RFC6674], [RFC5969], | 337 | | more | [RFC6219], [RFC6535], [RFC6654], [RFC6145], | 338 | | | ... | 339 | WG | 6 or | [I-D.ietf-softwire-4rd], | 340 | draft | more | [I-D.ietf-softwire-map], | 341 | | | [I-D.ietf-softwire-map-t], | 342 | | | [I-D.ietf-softwire-public-4over6], | 343 | | | [I-D.ietf-softwire-lw4over6], | 344 | | | [I-D.ietf-v6ops-464xlat], ... | 345 | Active | several | ... | 346 | draft | | | 347 +--------+---------+------------------------------------------------+ 349 Table 1: A Table of IPv6 Transition Technologies @ IETF 351 The situation described above depicts the difficulty of selecting 352 appropriate IPv6 transition technologies for the carriers. Moreover, 353 according to [SD-NAT], there are multiple stages during the whole 354 IPv6 transition period, and a variety of technologies and equipments 355 are used during different IPv6 transition stages. To protect the 356 user experience and the early investment, an operator will not 357 upgrade its network directly to the final stage of IPv6 transition. 358 During different IPv6 transition stages, an operator needs different 359 technologies in different stages. Thus, a method that is able to 360 implement different IPv6 transition technologies in the same hardware 361 is crucial, to avoid repeated investments. 363 4. Alternative Approach to IPv6 applications enablement 365 Finally an IP Network is simply an interconnection of various IPv4- 366 and IPv6-aware devices over some transport. From a payload point of 367 view, there is no need to wonder how the packet got to the 368 destination (security aspects are reserved). Removing the complexity 369 of the transport from the IP-aware devices, by simply considering it 370 as a hop-by-hop "encapsulation" would simplify some situations and 371 bring more flexibility for new applications. 373 The alternative approach proposed here is to put the IPv6 forwarding 374 rules into the devices by a dynamic configuration protocol like 375 Netconf, depending on the application requirements. Those forwarding 376 rules could for example require a change of encapsulation (e.g. from 377 IPv6oEthernet to IPv6oIPv4oEthernet), or an IP protocol change (e.g. 378 apply a NAT64 translation). A central management server would be 379 able to coordinate this configuration and push it adequately on the 380 forwarding devices. 382 Today, the configuration of these encapsulation or translations is 383 done manually and is not controlled in a coordinated and standard 384 way. The goal of the application-based approach is to allow the 385 operator to have both the flexibility and full control on what 386 technologies have to be used and when to help with its IPv6 387 transition process. 389 5. Existing protocols and methods for the alternate approach 391 The proposed approach would have impact on layer 3, and maybe 4. 392 Hence there is no need to change anything to Layer 1-2 protocols and 393 techniques. 395 Higher layer applications are not impacted either as the network 396 forwarding is transparent to them. 398 The proposed approach requires a dynamic configuration protocol for 399 network devices, to update the forwarding table accordingly. 400 Protocols like Netconf (add ref) or Openflow (add ref) are already 401 existing to achieve this goal. Thanks to their openness, they can 402 easily be extended to support it. 404 6. Missing protocols and methods for the alternate approach 406 The authors have identified some missing pieces to be able to use the 407 technology in a fully standard way. 409 6.1. Dynamic devices forwarding table configuration 411 The IETF standard for devices configuration is [RFC6241], the NETCONF 412 Protocol. So it may be suitable for the forwarding table 413 configuration of the openv6 devices and the address management in 414 [section 6.2], with some modifications of the code. However, Netconf 415 is not able to support the packet report from the device to the 416 controller/applications, which may need extensions of the protocol. 418 6.2. Address Management 420 Having a centralized way to manage addresses requires an efficient 421 protocol to request and allocate them. Among the possible solutions, 422 Netconf or Radius could be extended. 424 7. Security Considerations 425 7.1. Source Address Validation and Traceback with Openv6 427 A easy-to-use solution for Source Address Validation would increase 428 the safety of networks. If operators have an efficient and low cost 429 unified solution for this problem for both IPv4 and IPv6 and the 430 transition itself, they would be more incline to implement it and 431 therefore the security of networks as a whole would improve. 433 8. IANA Considerations 435 This document has no actions for IANA. 437 9. Authors 439 Credits and Thanks 441 10. Acknowledgements 443 Reference previous work. 445 11. References 447 11.1. Normative References 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, March 1997. 452 11.2. Informative References 454 [I-D.ietf-softwire-4rd] 455 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 456 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 457 Solution (4rd)", draft-ietf-softwire-4rd-07 (work in 458 progress), October 2013. 460 [I-D.ietf-softwire-lw4over6] 461 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 462 I. Farrer, "Lightweight 4over6: An Extension to the DS- 463 Lite Architecture", draft-ietf-softwire-lw4over6-06 (work 464 in progress), February 2014. 466 [I-D.ietf-softwire-map-t] 467 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 468 T. Murakami, "Mapping of Address and Port using 469 Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work 470 in progress), February 2014. 472 [I-D.ietf-softwire-map] 473 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 474 Murakami, T., and T. Taylor, "Mapping of Address and Port 475 with Encapsulation (MAP)", draft-ietf-softwire-map-10 476 (work in progress), January 2014. 478 [I-D.ietf-softwire-public-4over6] 479 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 480 IPv4 over IPv6 Access Network", draft-ietf-softwire- 481 public-4over6-10 (work in progress), July 2013. 483 [I-D.ietf-v6ops-464xlat] 484 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 485 Combination of Stateful and Stateless Translation", draft- 486 ietf-v6ops-464xlat-10 (work in progress), February 2013. 488 [One-vision-for-IPv6] 489 Mark Townsley, "One vision for IPv6", . 491 [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., 492 Toutain, L., and J. Tremblay, "Softwire Hub and Spoke 493 Deployment Framework with Layer Two Tunneling Protocol 494 Version 2 (L2TPv2)", RFC 5571, June 2009. 496 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 497 Infrastructures (6rd) -- Protocol Specification", RFC 498 5969, August 2010. 500 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 501 Algorithm", RFC 6145, April 2011. 503 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 504 China Education and Research Network (CERNET) IVI 505 Translation Design and Deployment for the IPv4/IPv6 506 Coexistence and Transition", RFC 6219, May 2011. 508 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 509 Stack Lite Broadband Deployments Following IPv4 510 Exhaustion", RFC 6333, August 2011. 512 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 513 Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. 515 [RFC6654] Tsou, T., Zhou, C., Taylor, T., and Q. Chen, "Gateway- 516 Initiated IPv6 Rapid Deployment on IPv4 Infrastructures 517 (GI 6rd)", RFC 6654, July 2012. 519 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, 520 "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, 521 July 2012. 523 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, 524 "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, 525 July 2012. 527 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 528 "Source Address Validation Improvement (SAVI) Framework", 529 RFC 7039, October 2013. 531 [SD-NAT] Alain Durand, "SD-NAT", 532 . 534 Authors' Addresses 536 Qiong Sun 537 China Telecom 538 No.118 Xizhimennei street, Xicheng District 539 Beijing 100035 540 P.R. China 542 Email: sunqiong@ctbri.com.cn 544 Will(Shucheng) Liu 545 Huawei Technologies 546 Bantian, Longgang District 547 Shenzhen 518129 548 P.R. China 550 Email: liushucheng@huawei.com 552 Cathy Zhou 553 Huawei Technologies 554 Bantian, Longgang District 555 Shenzhen 518129 556 P.R. China 558 Email: cathy.zhou@huawei.com 559 Guillaume Leclanche 560 Viagenie 561 246 Aberdeen 562 Quebec, QC G1R 2E1 563 Canada 565 Phone: +1 418 656 9254 566 Email: guillaume.leclanche@viagenie.ca