idnits 2.17.1 draft-ietf-ospf-transition-to-ospfv3-11.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5838, updated by this document, for RFC5378 checks: 2004-04-06) -- 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 (June 29, 2016) is 2856 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 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 5309 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft I. Chen 3 Ericsson 4 Intended Status: Standards Track A. Lindem 5 Updates: 5838 Cisco 6 R. Atkinson 7 Consultant 8 Expires in 6 months June 29, 2016 10 OSPFv3 over IPv4 for IPv6 Transition 11 13 Status of this Memo 15 Distribution of this memo is unlimited. 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire in 6 months. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as 41 the 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 Abstract 55 This document defines a mechanism to use IPv4 to transport OSPFv3 56 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address 57 Family extension can simplify transition from an OSPFv2 IPv4-only 58 routing domain to an OSPFv3 dual-stack routing domain. This document 59 updates RFC 5838 to support virtual links in the IPv4 unicast address 60 family when using OSPFv3 over IPv4. 62 Table of Contents 64 1. Introduction ....................................................3 65 1.1. IPv4-only Use Case .........................................4 66 2. Terminology .....................................................5 67 3. Encapsulation in IPv4 ...........................................5 68 3.1. Source Address .............................................7 69 3.2. Destination ................................................7 70 3.3. OSPFv3 Header Checksum .....................................7 71 3.4. Operation over Virtual Link ................................8 72 4. Management Considerations .......................................8 73 4.1. Coexistence with OSPFv2 ....................................8 74 5. Security Considerations .........................................9 75 6. IANA Considerations .............................................9 76 7. Acknowledgments .................................................9 77 8. References .....................................................10 78 8.1. Normative References.......................................10 79 8.2. informative References.....................................10 81 1. Introduction 83 Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3 84 Address Family extension can simplify transition from an IPv4-only 85 routing domain to an IPv6 [RFC2460], or dual-stack routing domain. 86 Dual-stack routing protocols, such as Border Gateway Protocol 87 [RFC4271], have an advantage during the transition, because both IPv4 88 and IPv6 address families can be advertised using either IPv4 or IPv6 89 transport. Some IPv4-specific and IPv6-specific routing protocols 90 share enough similarities in their protocol packet formats and 91 protocol signaling that it is trivial to deploy an initial IPv6 92 routing domain by transporting the routing protocol over IPv4, 93 thereby allowing IPv6 routing domains to be deployed and tested 94 before decommissioning IPv4 and moving to an IPv6-only network. 96 In the case of the Open Shortest Path First (OSPF) interior gateway 97 routing protocol (IGP), OSPFv2 [RFC2328] is the IGP deployed over 98 IPv4, while OSPFv3 [RFC5340] is the IGP deployed over IPv6. OSPFv3 99 further supports multiple address families [RFC5838], including both 100 the IPv6 unicast address family and the IPv4 unicast address family. 101 Consequently, it is possible to deploy OSPFv3 over IPv4 without any 102 changes to either OSPFv3 or to IPv4. During the transition to IPv6, 103 future OSPF extensions can focus on OSPFv3 and OSPFv2 can move to 104 maintenance mode. 106 This document specifies how to use IPv4 to transport OSPFv3 packets. 107 The mechanism takes advantage of the fact that OSPFv2 and OSPFv3 108 share the same IP protocol number, 89. Additionally, the OSPF packet 109 header for both OSPFv2 and OSPFv3 includes the OSPF header version 110 (i.e., the field that distinguishes an OSPFv2 packet from an OSPFv3 111 packet) in the same location (i.e., the same offset from the start of 112 the header). 114 If the IPv4 topology and IPv6 topology are not identical, the most 115 likely cause is that some parts of the network deployment have not 116 yet been upgraded to support both IPv4 and IPv6. In situations where 117 the IPv4 deployment is a superset of the IPv6 deployment, it is 118 expected that OSPFv3 packets would be transported over IPv4, until 119 the rest of the network deployment is upgraded to support IPv6 in 120 addition to IPv4. In situations where the IPv6 deployment is a 121 superset of the IPv4 deployment, it is expected that OSPFv3 would be 122 transported over IPv6. 124 Throughout this document, OSPF is used when the text applies to both 125 OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is used when the text is 126 specific to one version of the OSPF protocol. Similarly, IP is used 127 when the text describes either version of the Internet protocol. 128 IPv4 or IPv6 is used when the text is specific to a single version of 129 the Internet protocol. 131 1.1. IPv4-only Use Case 133 OSPFv3 only requires IPv6 link-local addresses to form adjacencies, 134 and does not require IPv6 global-scope addresses to establish an 135 IPv6 routing domain. However, IPv6 over Ethernet [RFC2464] uses a 136 different EtherType (0x86dd) from IPv4 (0x0800) and the Address 137 Resolution Protocol (ARP) (0x0806) [RFC826] used with IPv4. 139 Some existing deployed link-layer equipment only supports IPv4 and 140 ARP. Such equipment contains hardware filters keyed on the 141 EtherType field of the Ethernet frame to filter which frames will 142 be accepted by that link-layer equipment. Because IPv6 uses a 143 different EtherType, IPv6 framing for OSPFv3 will not work with 144 that equipment. In other cases, PPP might be used over a serial 145 interface, but again only IPv4 over PPP might be supported over 146 such interface. It is hoped that equipment with such limitations 147 will be eventually upgraded or replaced. 149 In some locations, especially locations with less communications 150 infrastructure, satellite communications (SATCOM) is used to reduce 151 deployment costs for data networking. SATCOM often has lower cost 152 to deploy than running new copper or optical cables over long 153 distances to connect remote areas. Also, in a wide range of 154 locations including places with good communications infrastructure, 155 Very Small Aperture Terminals (VSAT) often are used by banks and 156 retailers to connect their branches and stores to a central 157 location. 159 Some widely deployed VSAT equipment has either (A) Ethernet 160 interfaces that only support Ethernet Address Resolution Protocol 161 (ARP) and IPv4, or (B) serial interfaces that only support IPv4 and 162 Point-to-Point Protocol (PPP) packets. Such deployments and 163 equipment still can deploy and use OSPFv3 over IPv4 today, and then 164 later migrate to OSPFv3 over IPv6 after equipment is upgraded or 165 replaced. This can have lower operational costs than running 166 OSPFv2 and then trying to make a flag-day switch to OSPFv3. By 167 running OSPFv3 over IPv4 now, the eventual transition to dual- 168 stack, and then to IPv6-only can be optimized. 170 2. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 3. Encapsulation in IPv4 178 An OSPFv3 packet can be directly encapsulated within an IPv4 packet 179 as the payload, without the IPv6 packet header, as illustrated in 180 Figure 1. For OSPFv3 transported over IPv4, the IPv4 packet has an 181 IPv4 protocol type of 89, denoting that the payload is an OSPF 182 packet. The payload of the IPv4 packet consists of an OSPFv3 packet, 183 beginning with the OSPF packet header having its OSPF version field 184 set to 3. 186 An OSPFv3 packet followed by an OSPF link-local signaling (LLS) 187 extension data block [RFC5613] encapsulated in an IPv4 packet is 188 illustrated in Figure 2. 190 Since an IPv4 header without options is only 20 bytes long and is 191 shorter than an IPv6 header, an OSPFv3 packet encapsulated in a 192 20-byte IPv4 header is shorter than an OSPFv3 packet encapsulated in 193 an IPv6 header. Consequently, the link MTU for IPv6 is sufficient to 194 transport an OSPFv3 packet encapsulated in a 20-byte IPv4 header. If 195 the link MTU is not sufficient to transport an OSPFv3 packet in IPv4, 196 then OSPFv3 can rely on IP fragmentation and reassembly [RFC791]. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 201 | 4 | IHL |Type of Service| Total Length | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 203 | Identification |Flags| Fragment Offset | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Time to Live | Protocol 89 | Header Checksum | IPv4 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 207 | Source Address | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 209 | Destination Address | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 211 | Options | Padding | v 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 213 | 3 | Type | Packet length | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Router ID | OSPFv3 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 217 | Area ID | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 219 | Checksum | Instance ID | 0 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 221 | OSPFv3 Body ... | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 1: An IPv4 packet encapsulating an OSPFv3 packet. 226 +---------------+ 227 | IPv4 Header | 228 +---------------+ 229 | OSPFv3 Header | 230 |...............| 231 | | 232 | OSPFv3 Body | 233 | | 234 +---------------+ 235 | | 236 | LLS Data | 237 | | 238 +---------------+ 240 Figure 2: The IPv4 packet encapsulating an OSPFv3 packet with 241 a trailing OSPF link-local signaling data block. 243 3.1. Source Address 245 For OSPFv3 over IPv4, the source address is the primary IPv4 246 address for the interface over which the packet is transmitted. 247 All OSPFv3 routers on the link should share the same IPv4 subnet 248 for IPv4 transport to function correctly. 250 While OSPFv2 operates on a subnet, OSPFv3 operates on a link 251 [RFC5340]. Accordingly, an OSPFv3 router implementation MAY 252 support adjacencies with OSPFv3 neighbors on different IPv4 253 subnets. If this is supported, the IPv4 data plane MUST resolve 254 IPv4 addresses to layer-2 addresses using Address Resolution 255 Protocol (ARP) on multi-access networks and point-to-point over LAN 256 [RFC5309] for direct next-hops on different IPv4 subnets. When 257 OSPFv3 adjacencies on different IPv4 subnets are supported, 258 Bidirectional Forwarding Detection (BFD) [RFC5881] cannot be used 259 for adjacency loss detection since BFD is restricted to a single 260 subnet. 262 3.2. Destination Address 264 As defined in OSPFv2, the IPv4 destination address of an OSPF 265 protocol packet is either an IPv4 multicast address or the IPv4 266 unicast address of an OSPFv2 neighbor. Two well-known link-local 267 multicast addresses are assigned to OSPFv2, the AllSPFRouters 268 address (224.0.0.5) and the AllDRouters address (224.0.0.6). The 269 multicast address used depends on the OSPF packet type, the OSPF 270 interface type, and the OSPF router's role on multi-access 271 networks. 273 Thus, for an OSPFv3 over IPv4 packet to be sent to AllSPFRouters, 274 the destination address field in the IPv4 packet MUST be 224.0.0.5. 275 For an OSPFv3 over IPv4 packet to be sent to AllDRouters, the 276 destination address field in the IPv4 packet MUST be 224.0.0.6. 278 When an OSPF router sends a unicast OSPF packet over a connected 279 interface, the destination of such an IP packet is the address 280 assigned to the receiving interface. Thus, a unicast OSPFv3 packet 281 transported in an IPv4 packet would specify the OSPFv3 neighbor's 282 IPv4 address as the destination address. 284 3.3. OSPFv3 Header Checksum 286 For IPv4 transport, the pseudo-header used in the checksum 287 calculation will contain the IPv4 source and destination addresses, 288 the OSPFv3 protocol ID, and the OSPFv3 length from the OSPFv3 289 header (Appendix A.3.1 [RFC5340]). The format is similar to the 290 UDP pseudo-header as described in [RFC768] and is illustrated in 291 Figure 3. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Source Address | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Destination Address | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | 0 | Protocol (89) | OSPFv3 Packet Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 3: Pseduo-header for OSPFv3 over IPv4. 304 3.4. Operation over Virtual Links 306 When an OSPF router sends an OSPF packet over a virtual link, the 307 receiving router is a router that might not be directly connected 308 to the sending router. Thus, the destination IP address of the IP 309 packet must be a reachable unicast IP address for the virtual link 310 endpoint. Because IPv6 is the presumed Internet protocol and an 311 IPv4 destination is not routable, the OSPFv3 address family 312 extension [RFC5838] specifies that only IPv6 address family virtual 313 links are supported. 315 As illustrated in Figure 1, this document specifies OSPFv3 316 transport over IPv4. As a result, OSPFv3 virtual links can be 317 supported with IPv4 address families by simply setting the IPv4 318 destination address to a reachable IPv4 unicast address for the 319 virtual link endpoint. Hence, the restriction in Section 2.8 of 320 RFC 5838 [RFC5838] is relaxed since virtual links can now be 321 supported for IPv4 address families as long as the transport is 322 also IPv4. If IPv4 transport, as specified herein, is used for 323 IPv6 address families, virtual links cannot be supported. Hence, in 324 OSPF routing domains that require virtual links, the IP transport 325 MUST match the address family (IPv4 or IPv6). 327 4. Management Considerations 329 4.1. Coexistence with OSPFv2 331 Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use 332 exactly the same protocol and IPv4 addresses, OSPFv2 packets may be 333 delivered to the OSPFv3 process and vice versa. When this occurs, 334 the mismatched protocol packets will be dropped due to validation 335 of the version in the first octet of the OSPFv2/OSPFv3 protocol 336 header. Note that this will not prevent the packets from being 337 delivered to the correct protocol process as standard socket 338 implementations will deliver a copy to each socket matching the 339 selectors. 341 Implementations of OSPFv3 over IPv4 transport SHOULD implement 342 separate counters for a protocol mismatch and SHOULD provide means 343 to suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket SNMP 344 notifications as described in [RFC4750] and the ospfv3IfRxBadPacket 345 and ospv3VirtIfRxBadPacket SNMP notifications as described in 346 [RFC5643] when an OSPFv2 packet is received by the OSPFv3 process 347 or vice versa. 349 5. Security Considerations 351 As described in [RFC4552], OSPFv3 uses IPsec [RFC4301] for 352 authentication and confidentiality. Consequently, an OSPFv3 packet 353 transported within an IPv4 packet requires IPsec to provide 354 authentication and confidentiality. Further work such as [ipsecospf] 355 would be required to support IPsec protection for OSPFv3 over IPv4 356 transport. 358 An optional OSPFv3 Authentication Trailer [RFC7166] also has been 359 defined as an alternative to using IPsec. The calculation of the 360 authentication data in the Authentication Trailer includes the source 361 IPv6 address to protect an OSPFv3 router from Man-in-the-Middle 362 attacks. For IPv4 encapsulation as described herein, the IPv4 source 363 address should be placed in the first 4 octets of Apad followed by 364 the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L is 365 the length of hash measured in octets. 367 The processing of the optional Authentication Trailer is contained 368 entirely within the OSPFv3 protocol. In other words, each OSPFv3 369 router instance is responsible for the authentication, without 370 involvement from IPsec or any other IP layer function. Consequently, 371 except for calculation of the Apad value, transporting OSPFv3 packets 372 using IPv4 does not change the generation or validation of the 373 optional OSPFv3 Authentication Trailer. 375 6. IANA Considerations 377 No actions are required from IANA as result of the publication of 378 this document. 380 7. Acknowledgments 382 The authors would like to thank Alexander Okonnikov for his thorough 383 review and valuable feedback. The authors would also like to thank 384 Wenhu Lu for acting as document shepherd. 386 8. References 388 8.1. Normative References 390 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 391 1981. 393 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 394 (IPv6) Specification", RFC 2460, December 1998. 396 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 397 for IPv6", RFC 5340, July 2008. 399 [RFC2328] Moy, J., "OSPF Version 2", STD54, RFC 2328, April 1998. 401 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 402 R. Aggarwal, "Support of Address Families in OSPFv3", RFC 403 5838, April 2010. 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point 409 Operation over LAN in Link State Routing Protocols", RFC 410 5309, October 2008. 412 8.2. Informative References 414 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 415 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 416 2006. 418 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 419 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 421 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or 422 Converting Network Protocol Addresses to 48.bit Ethernet 423 Address for Transmission on Ethernet Hardware", STD 37, 424 RFC 826, November 1982. 426 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 427 Networks", RFC 2464, December 1998. 429 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 430 10.17487/RFC0768, August 1980. 432 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 433 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 434 10.17487/RFC5881, June 2010. 436 [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., 437 Coltun, R., and F. Baker, "OSPF Version 2 Management 438 Information Base", RFC 4750, DOI 10.17487/RFC4750, 439 December 2006. 441 [RFC5643] Joyal, D., Ed., and V. Manral, Ed., "Management 442 Information Base for OSPFv3", RFC 5643, DOI 443 10.17487/RFC5643, August 2009. 445 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 446 for OSPFv3", RFC 4552, June 2006. 448 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 449 Internet Protocol", RFC 4301, December 2005. 451 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 452 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 454 [ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta- 455 ospf-ospfv2-sec-01.txt", August 2009. 457 Authors' Addresses 459 I. Chen 460 Ericsson 461 Email: ichen@kuatrotech.com 463 A. Lindem 464 Cisco 465 Email: acee@cisco.com 467 R. Atkinson 468 Consultant 469 Email: rja.lists@gmail.com