idnits 2.17.1 draft-ietf-dhc-dhcpv6-ldra-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3315, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- 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 (October 19, 2010) is 4936 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-dhc-l2ra-04 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group D. Miles, Ed. 3 Internet-Draft S. Ooghe 4 Updates: 3315 (if approved) Alcatel-Lucent 5 Intended status: Standards Track W. Dec 6 Expires: April 22, 2011 Cisco Systems 7 S. Krishnan 8 A. Kavanagh 9 Ericsson 10 October 19, 2010 12 Lightweight DHCPv6 Relay Agent 13 draft-ietf-dhc-dhcpv6-ldra-03 15 Abstract 17 This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that 18 is used to insert relay agent options in DHCPv6 message exchanges 19 identifying client-facing interfaces. The LDRA can be implemented in 20 existing access nodes (such as DSLAMs and Ethernet switches) that do 21 not support IPv6 control or routing functions. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 22, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Server Considerations . . . . . . . . . . . . . . . . . . . . 4 62 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Relay-Forward Message . . . . . . . . . . . . . . . . . . 5 64 5.2. Relay-Reply Message . . . . . . . . . . . . . . . . . . . 5 65 5.3. Mandatory DHCP Options . . . . . . . . . . . . . . . . . . 6 66 5.3.1. Relay-Message Option . . . . . . . . . . . . . . . . . 6 67 5.3.2. Interface-ID Option . . . . . . . . . . . . . . . . . 6 68 6. Agent Behaviour . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Relaying a Client Message . . . . . . . . . . . . . . . . 7 70 6.1.1. Client Message Validation . . . . . . . . . . . . . . 7 71 6.1.2. Trusted and Untrusted Interfaces . . . . . . . . . . . 8 72 6.2. Relaying a Relay-Reply message from the network . . . . . 8 73 7. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1. Client and Server on Same Link . . . . . . . . . . . . . . 9 75 7.2. Client and Server behind Relay Agent . . . . . . . . . . . 10 76 7.3. Relay Agent in Front of LDRA . . . . . . . . . . . . . . . 11 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 DHCPv6 Relay-Agents [RFC3315] are deployed to forward DHCPv6 messages 89 between clients and servers when they are not on the same IPv6 link 90 and are often implemented alongside a routing function in a common 91 node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent 92 Information to be inserted by an access node that performs a link- 93 layer bridging (i.e. non-routing) function. A LDRA resides on the 94 same IPv6 link as the client and a DHCPv6 Relay Agent or Server and 95 is functionally the equivalent of the Layer 2 DHCP Relay draft[L2RA] 96 proposed for DHCPv4 operation. 98 Unlike a DHCPv6 Relay-Agent specified in [RFC3315], a LDRA does not 99 implement any IPv6 control functions (e.g. ICMPv6) or have any 100 routing capability in the node. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Background 110 A variety of different link-layer network topologies exist for the 111 aggregation of IPv6 nodes into one or more routers. In Layer 2 112 aggregation networks (IEEE 802.1D bridging or similar) that have many 113 nodes on a single link, a DHCPv6 server or DHCP relay agent would 114 normally be unaware of how a DHCP client is attached to the network. 115 The LDRA allows Relay Agent Information, including the Interface-ID 116 option [RFC3315], to be inserted by the access node so that it may be 117 used by the DHCPv6 server for client identification. A typical 118 application in a broadband service provider may be as an equivalent 119 to the Broadband Forum TR-101 Layer 2 DHCP Relay Agent [TR-101] 120 described in [L2RA]. 122 3. Terminology 124 Access Node A device that combines many interfaces onto 125 one link. An access node is not IP-aware 126 in the data path. 128 Address An IP layer identifier for an interface or 129 set of interfaces. 131 Client-facing An interface on the access node that 132 carries traffic towards the DHCPv6 client. 134 Host A non-routing IPv6 node that is 135 participating in a DHCPv6 message exchange. 137 IP Internet Protocol Version 6 (IPv6). 139 LDRA Lightweight DHCPv6 Relay Agent. 141 Lightweight Relay Agent A function on the access node that 142 intercepts DHCP messages between clients 143 and servers. The function exists as a bump 144 in the wire on the IP link. 146 Link A communication facility or medium over 147 which nodes can communicate at the link 148 layer. 150 Link-local address An IP address having only local-scope, 151 indicated by having the address prefix 152 FE80::/10, that can be used to reach 153 neighbouring nodes attached to the same 154 link. Every interface has a link-local 155 address. 157 Network-facing An interface on the access node that 158 carries traffic towards the DHCPv6 159 server(s). 161 Node A device that implements IPv6. 163 Router A node that forwards packets not directly 164 addressed to itself. 166 Relay Agent A node that acts as an intermediary to 167 deliver DHCP messages between clients and 168 servers and being on the same link as the 169 client. 171 Unspecified address An IPv6 address that is comprised entirely 172 of zeros. 174 4. Server Considerations 176 This document updates the behavior specified in section 11 of DHCP 177 for IPv6 [RFC3315]. RFC3315 states, in part: 179 o If the server receives the message from a forwarding relay agent, 180 then the client is on the same link as the one to which the 181 interface, identified by the link-address field in the message 182 from the relay agent, is attached. 184 DHCP server implementations conforming to this specification must, 185 for the purposes of address selection, ignore any link-address field 186 whose value is zero. In the text from RFC3315 above, "link-address" 187 refers both to the link-address field of the Relay-forward message, 188 and also the link-address fields in any Relay-forward messages that 189 may be nested within the Relay-forward message. 191 5. Message Format 193 The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages 194 between clients and servers using the message formats established in 195 [RFC3315]. 197 To maintain interoperability with existing DHCP relays and servers 198 the message format is unchanged from [RFC3315]. The LDRA implements 199 the same message types as a normal DHCPv6 Relay Agent. They are: 201 o Relay-Forward Messages 203 o Relay-Reply Messages 205 5.1. Relay-Forward Message 207 The Relay-Forward message is created by any DHCPv6 Relay Agent, 208 including an LDRA, to forward messages between clients and servers or 209 other relay agents. These messages are built as specified in 210 [RFC3315]. 212 The Relay-Forward message contains relay agent parameters that 213 identify the client-facing interface on which any reply messages 214 should be forwarded. These parameters are link-address, peer-address 215 and Interface-ID. The link-address parameter MUST be set to the 216 unspecified address. The Interface-ID Relay Agent Option MUST be 217 included in the Relay-Forward message. The LDRA MAY insert 218 additional relay agent options. 220 5.2. Relay-Reply Message 222 The Relay-Reply message is constructed by a DHCPv6 server to send 223 parameters to a DHCP client when a relay agent is present between the 224 server and the client. The Relay-Reply message may be sent after an 225 initial Relay-Forward message as the parameters link-address, peer- 226 address, Interface-ID and the relay agent's IP address are learnt 227 from the Relay-Forward message. 229 The server MUST include the Interface-ID option in the Relay-Reply 230 Message to indicate to the LDRA the interface on which the de- 231 capsulated message should be forwarded. 233 5.3. Mandatory DHCP Options 235 Parameters are exchanged between DHCP client, relay-agent and server 236 through the use of DHCP options. There is a set of mandatory DHCP 237 options that MUST be included by the LDRA in all Relay-Forward 238 messages. These are the: 240 o Relay-Message Option 242 o Interface-ID Option 244 5.3.1. Relay-Message Option 246 A DHCPv6 Relay Agent relays messages between clients and servers or 247 other relay agents through Relay-Forward and Relay-Reply message 248 types. The original client DHCP message (i.e. the packet payload, 249 excluding UDP and IP headers) is encapsulated in a Relay Message 250 option [RFC3315]. 252 If a Relay-Message would exceed the MTU of the outgoing interface it 253 MUST be discarded and an error condition SHOULD be logged. 255 5.3.2. Interface-ID Option 257 The LDRA MUST include the Interface-ID option [RFC3315] in all Relay- 258 Forward messages. When a LDRA receives a Relay-reply message with an 259 Interface-ID option present and link-address unspecified, the LDRA 260 MUST relay the decapsulated message to the client on the interface 261 identified in the Interface-ID option. 263 Servers MAY use the Interface-ID for parameter assignment policies. 264 The format of the Interface-ID is outside the scope of this 265 contribution. The Interface-ID SHOULD be considered an opaque value, 266 i.e. the server SHOULD NOT try to parse the contents of the 267 Interface-ID option. The LDRA SHOULD use the same Interface-ID value 268 for a given interface, and this value SHOULD be retained across 269 restarts. This is because, if the Interface-ID changes, a server 270 will not be able to use it reliably in parameter assignment policies. 272 6. Agent Behaviour 274 The LDRA MUST have each of its interfaces configured as either 275 client-facing or network-facing. The LDRA uses the notion of client- 276 facing and network-facing interfaces to process DHCPv6 messages. 278 6.1. Relaying a Client Message 280 When a DHCPv6 message (defined in [RFC3315]) is received on any 281 client-facing interface, the LDRA MUST intercept and process the 282 message. The LDRA MUST also prevent the original message from being 283 forwarded on the network facing interface. 285 The lightweight relay agent adds any other options it is configured 286 or required to include in the Relay-Forward message. The LDRA MUST 287 set the link-address field of the Relay-forward message to the 288 Unspecified Address (::) and MUST include the Interface-ID option in 289 all DHCP Relay-Forward messages. 291 If the message received on the client-facing interface is a Relay- 292 Forward message, the LDRA MUST set the Hop-Count field in the newly 293 created Relay-Forward message to the value of the hop-count field in 294 the received message incremented by 1 as specified in [RFC3315]. 296 The LDRA MUST copy the IP destination and link-layer destination 297 addresses from the client-originated message into the IP destination 298 address and link-layer destination address of the Relay-forward 299 message. 301 The LDRA MUST copy the IP source address from the client-originated 302 message into the peer-address field of the Relay-forward message. 303 The LDRA MUST copy the link-layer source address from the client- 304 originated message into the link-layer source address of the Relay- 305 forward message. 307 6.1.1. Client Message Validation 309 On receipt of a DHCP message on a client-facing interface, the LDRA 310 MUST discard a message if it is of one of following message types: 312 o ADVERTISE (2) 314 o REPLY (7) 316 o RECONFIGURE (10) 318 o RELAY-REPLY (13) 319 Options contained in the DHCPv6 message MUST NOT be validated by the 320 LDRA, making it the responsibility of the DHCP server to check 321 message option validity and allow new options to be introduced 322 without changes on the LDRA. 324 6.1.2. Trusted and Untrusted Interfaces 326 In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces 327 set to trusted and untrusted. An LDRA MUST implement a configuration 328 setting for all client-facing interfaces, marking them either as 329 trusted or as untrusted. This setting SHOULD be configurable per 330 interface. When a client-facing interface is deemed untrusted the 331 LDRA MUST discard any message received from the client-facing 332 interface of type RELAY-FORWARD (12). 334 6.2. Relaying a Relay-Reply message from the network 336 The LDRA MUST intercept and process all IP traffic received on the 337 network-facing interface that has: 339 o a link-local scoped source address; 341 o a link-local scoped destination address; 343 o protocol type UDP; and 345 o destination port 547 347 An LDRA MUST inspect the DHCP message type and only forward Relay- 348 Reply messages. Other DHCP message types MUST be silently discarded. 350 The Relay-Reply message is considered valid by the LDRA if it passes 351 the validity checks to be performed by a relay agent per [RFC3315] 352 and: 354 - The Interface-ID Option is present and the value corresponds to a 355 valid interface in the access node, 357 - the Relay-Reply peer-address and the destination IP address is 358 identical and it is a link-local scoped address when no IP address is 359 configured on the LDRA, and 361 - the link-address is the Unspecified Address when no IP address is 362 configured on the LDRA 364 If the Relay-Reply message is valid, the LDRA copies the peer-address 365 into to the destination IP address field. The LDRA SHOULD forward 366 the packet to the correct client- facing interface using the 367 destination link-layer (MAC) address or the Interface-Id in the 368 Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any other 369 interface. The contents of the Relay Message Option is put into an 370 IP/UDP packet and then forwarded to the client. 372 The LDRA MUST copy the link-layer and IP source address from the 373 Relay-Reply message into the IP/UDP packet that is forwarded to the 374 client. 376 7. Network Topology 378 The LDRA intercepts any DHCPv6 message received on client-facing 379 interfaces with a destination IP address of 380 All_DHCP_Relay_Agents_and_Servers (FF02::1:2). The LDRA MUST NOT 381 forward the original client message to a network-facing interface, it 382 MUST process the message and add the appropriate Relay-Forward 383 options as described in previous sections. 385 7.1. Client and Server on Same Link 387 The access node acts as a bridge; it has no information about any IP 388 prefixes that are valid on the link, thus a server should consider 389 address and parameter assignment as if the client DHCP message was 390 not relayed. 391 +--------+ 392 Client -------| | 393 | Access | 394 Client -------| Node |-----+ 395 | (LDRA) | | 396 Client -------| | | 397 +--------+ | 398 | +--------+ 399 |------| Server | 400 | +--------+ 401 +--------+ | 402 Client -------| | | 403 | Access | | 404 Client -------| Node |-----+ 405 | (LDRA) | 406 Client -------| | 407 +--------+ 409 <--------- IPv6 Link --------> 411 For example, if a client sent a DHCP solicit message that was relayed 412 by the LDRA to the server, the server would receive the following 413 Relay-Forward message from the LDRA: 415 src-ip: client link-local address 416 dst-ip: All_DHCP_Relay_Agents_and_Servers 417 msg-type: RELAY-FORWARD 418 hop-count: 0 419 link-address: Unspecified_Address 420 peer-address: client link-local address 421 Interface-ID Option: 422 interface-id: LDRA-inserted interface-id 423 Relay-Message Option, which contains: 424 msg-type: SOLICIT 425 Solicit Message Options: 427 7.2. Client and Server behind Relay Agent 429 The client and server are on different IPv6 links, separated by one 430 or more relay agents that will typically act as a router. The LDRA 431 will send Relay-Forward messages upstream towards the second relay 432 agent which in turn will process the messages. 433 +--------+ 434 Client -------| | 435 | Access | 436 Client -------| Node |-----+ 437 | (LDRA) | | 438 Client -------| | | 439 +--------+ | 440 | +--------+ +--------+ 441 |------| RelayB |-------| Server | 442 | +--------+ +--------+ 443 +--------+ | 444 Client -------| | | 445 | Access | | 446 Client -------| Node |-----+ 447 | (LDRA) | 448 Client -------| | 449 +--------+ 451 <------- IPv6 Link A -------> <--IPv6 Link B--> 453 For example, if a client sent a DHCP solicit message that was relayed 454 by the LDRA to another relay agent and then to the server, the server 455 would receive the following Relay-Forward message from the LDRA: 457 src-ip: relayB 458 dst-ip: server 459 msg-type: RELAY-FORWARD 460 hop-count: 1 461 link-address: relayB address from link A 462 peer-address: client link-local address 463 Relay-Message Option, which contains: 464 msg-type: RELAY-FORWARD 465 hop-count: 0 466 link-address: Unspecified_Address 467 peer-address: client link-local address 468 Interface-ID Option: 469 interface-id: LDRA-inserted interface-id 470 Relay-Message Option, which contains: 471 msg-type: SOLICIT 472 Solicit Message Options: 474 7.3. Relay Agent in Front of LDRA 476 The client and server are on different IPv6 links, separated by one 477 or more relay agents that will typically act as a router and there is 478 an [RFC3315] Relay Agent on the client-facing Interface of the LDRA. 479 The LDRA will send Relay-Forward messages upstream towards the second 480 relay agent which in turn will process the messages. 481 +--------+ 482 RelayC -------| | 483 | Access | 484 RelayC -------| Node |-----+ 485 | (LDRA) | | 486 RelayC -------| | | 487 +--------+ | 488 | +--------+ +--------+ 489 |------| RelayB |-------| Server | 490 | +--------+ +--------+ 491 +--------+ | 492 RelayC -------| | | 493 | Access | | 494 RelayC -------| Node |-----+ 495 | (LDRA) | 496 RelayC -------| | 497 +--------+ 499 <------- IPv6 Link A -------> <--IPv6 Link B--> 501 For example, if a client sent a DHCP solicit message that was relayed 502 by RelayC and the LDRA to another relay agent, RelayB, and then to 503 the server, the server would receive the following Relay-Forward 504 message: 506 src-ip: relayB 507 dst-ip: server 508 msg-type: RELAY-FORWARD 509 hop-count: 2 510 link-address: relayB address from link A 511 peer-address: relayC 512 Relay-Message Option, which contains: 513 msg-type: RELAY-FORWARD 514 hop-count: 1 515 link-address: Unspecified_Address 516 peer-address: relayC 517 Interface-ID Option: 518 interface-id: LDRA-inserted interface-id 519 Relay-Message Option, which contains: 520 msg-type: RELAY-FORWARD 521 hop-count: 0 522 link-address: global or unspecified address 523 peer-address: end client address 524 Interface-ID Option: (if required) 525 interface-id: relayC inserted Interface-ID 526 Relay-Message Option, which contains: 527 msg-type: SOLICIT 528 Solicit Message Options: 530 8. Contributors 532 The authors would like to thank the following for their support, 533 Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig 534 Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij, 535 Alfred Hoenes and Ted Lemon. 537 Comments are solicited and should be addressed to the DHC WG mailing 538 list (dhcwg@ietf.org) and/or the author. 540 9. IANA Considerations 542 This document does not introduce any new namespaces for the IANA to 543 manage. 545 10. Security Considerations 547 Although the LDRA only listens to client-originated IPv6 traffic sent 548 to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547, 549 the LDRA SHOULD implement some form of rate-limiting on received 550 messages to prevent excessive process utilisation. As DHCP is 551 session-oriented, messages in excess of the rate-limit may be 552 silently discarded. 554 The hop count based determination of the trustworthiness of the LDRA 555 can be easily defeated by a rogue relay agent on the network-facing 556 interface of the LDRA. 558 11. Acknowledgements 560 The authors would like to thank Tatuya Jinmei, David Hankins, Ted 561 Lemon and Ralph Droms for reviewing this document and suggesting 562 changes. 564 12. References 566 12.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", RFC 2119, March 1997. 571 [RFC3315] Droms, R., "Dynamic Host Configuration Protocol for IPv6 572 (DHCPv6)", RFC 3315, July 2003. 574 12.2. Informative References 576 [L2RA] Joshi, B., "Layer 2 Relay Agent Information", IETF 577 Draft draft-ietf-dhc-l2ra-04, April 2009. 579 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 580 RFC 3046, January 2001. 582 [TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL 583 Aggregation", Technical Report TR-101, April 2006. 585 Authors' Addresses 587 David Miles (editor) 588 Alcatel-Lucent 589 L3 / 215 Spring St 590 Melbourne, Victoria 3000 591 Australia 593 Phone: +61 3 9664 3308 594 Email: david.miles@alcatel-lucent.com 595 Sven Ooghe 596 Alcatel-Lucent 597 Copernicuslaan 50 598 2018 Antwerp, 599 Belgium 601 Phone: 602 Email: sven.ooghe@alcatel-lucent.com 604 Wojciech Dec 605 Cisco Systems 606 Haarlerberdweg 13-19 607 1101 CH Amsterdam, 608 The Netherlands 610 Phone: 611 Email: wdec@cisco.com 613 Suresh Krishnan 614 Ericsson 615 8400 Blvd Decarie 616 Town of Mount Royal, Quebec 617 Canada 619 Email: suresh.krishnan@ericsson.com 621 Alan Kavanagh 622 Ericsson 623 8400 Blvd Decarie 624 Town of Mount Royal, Quebec 625 Canada 627 Email: alan.kavanagh@ericsson.com