idnits 2.17.1 draft-palet-v6ops-p2p-links-04.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 (November 4, 2019) is 1633 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3627 (Obsoleted by RFC 6547) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops J. Palet Martinez 3 Internet-Draft The IPv6 Company 4 Intended status: Informational November 4, 2019 5 Expires: May 7, 2020 7 IPv6 Point-to-Point Links 8 draft-palet-v6ops-p2p-links-04 10 Abstract 12 This document describes different alternatives for configuring IPv6 13 point-to-point links, considering the prefix size, numbering choices 14 and prefix pool to be used. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 7, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 52 3. The Ping-Pong Problem in Point-to-Point Links . . . . . . . . 3 53 4. Prefix Size Choices . . . . . . . . . . . . . . . . . . . . . 3 54 4.1. Rationale for using /64 . . . . . . . . . . . . . . . . . 3 55 4.2. Rationale for using /127 . . . . . . . . . . . . . . . . 4 56 4.3. Rationale for using /126 and Other Options . . . . . . . 5 57 4.4. A Possible Middle-Term Choice . . . . . . . . . . . . . . 5 58 5. Numbering Choices . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. GUA (Global Unicast Addresses) . . . . . . . . . . . . . 5 60 5.2. ULA (Unique Local Addresses) . . . . . . . . . . . . . . 5 61 5.3. Link-Local Addresses Only . . . . . . . . . . . . . . . . 6 62 6. Prefix Pool Choices . . . . . . . . . . . . . . . . . . . . . 7 63 7. /64 from Customer Prefix for point-to-point links . . . . . . 7 64 7.1. Numbering Interfaces . . . . . . . . . . . . . . . . . . 7 65 7.2. Routing Aggregation of the Point-to-Point Links . . . . . 8 66 7.3. DHCPv6 Considerations . . . . . . . . . . . . . . . . . . 9 67 7.4. Router Considerations . . . . . . . . . . . . . . . . . . 9 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 11.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 There are different alternatives for numbering IPv6 point-to-point 79 links, and from an operational perspective, there may have different 80 advantages or disadvantages that need to be taken in consideration 81 under the scope of each specific network architecture design. 83 [RFC6164] describes using /127 prefixes for inter-router point-to- 84 point links, using two different address pools, one for numbering the 85 point-to-point links and another one for delegating the prefixes at 86 the end of the point-to-point link. However, this doesn't exclude 87 other choices. 89 This document describes alternative approaches, for the prefix size, 90 the numbering of the link and the prefix pool. 92 The proposed approaches are suitable for those point-to-point links 93 connecting ISP to customers, but not limited to those cases, and in 94 fact, all them are being used by a relevant number of networks 95 worldwide, in several different scenarios (service providers, 96 enterprise networks, etc.). 98 2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 3. The Ping-Pong Problem in Point-to-Point Links 108 Some point-to-point links may present the ping-pong problem, (a 109 forwarding loop). The fundamental root cause of this problem is an 110 IPv6 implementations not performing full Neighbor Discovery (NS/NA) 111 on addresses that the prefix says could exist on the link. 113 IPv6 implementations are assuming that all addresses within the 114 prefix must exist at the other end of the point-to-point link, and 115 send the traffic straight onto the link. If the address doesn't 116 exist, and there is a covering route back in the other direction, the 117 ping-pong problem occurs. 119 Full Neighbor Discovery is doing more than just resolving the link- 120 layer address of an IPv6 address. Neighbor Discovery is also 121 determining if the address exists. Even if a point-to-point link 122 doesn't have link-layer addresses to resolve, ND determining if an 123 address exists on the link is very beneficial because it will prevent 124 the ping-pong problem occurring entirely regardless of the IPv6 125 prefix length being used on the link. 127 4. Prefix Size Choices 129 [RFC7608] already discusses about the IPv6 prefix length 130 recommendations for forwarding, and the need for routing and 131 forwarding implementations to ensure that longest-prefix-match works 132 on any prefix length. So, in this document, we concentrate in the 133 most commonly used choices, not excluding other options. 135 4.1. Rationale for using /64 137 The IPv6 Addressing Architecture ([RFC4291]) specifies that all the 138 Interface Identifiers for all the unicast addresses (except for 139 000/3) are required to be 64 bits long and to be constructed in 140 Modified EUI-64 format. 142 The same document also mandates the usage of the predefined subnet- 143 router anycast address, which has cleared to zero all the bits that 144 do not form the subnet prefix. 146 Using /64 is the most common scenario and currently the best practice 147 by the number of service providers using this approach compared to 148 others. 150 Using a /64 has the advantage of being future proof and avoids 151 renumbering, in the event that new standards take advantage of the 64 152 bits for other purposes, or the link becomes a point-to-multipoint, 153 or there is a need to use more addresses in the link (e.g., 154 monitoring equipment, managed bridges). 156 It has been raised also the issue of some hardware having limitations 157 in using prefixes longer then /64, for example using extra hardware 158 resources. 160 Section 5. of [RFC6164] describes possible issues when using /64 for 161 the point-to-point links, such as the ping-pong and the neighbor 162 cache exhaustion. However, it also states that they can be mitigated 163 by other means, including the latest ICMPv6 [RFC4443] ND [RFC4861]. 164 Indeed, considering the publication date of that document, those 165 issues should not be any longer a concern. The fact is that many 166 operators worldwide, today use /64 without any concerns, as vendors 167 have taken the necessary code updates. 169 Consequently, we shall conclude that it is a valid approach to use 170 /64 prefixes for the point-to-point links. 172 4.2. Rationale for using /127 174 [RFC6164] already do a complete review of reasons why /127 is a good 175 approach vs other options. However, it needs to be considered that 176 it was published a number of years ago, and most of the hardware 177 today already incorporate mitigations. 179 It should be noted that, when using a /127 prefix, configuration of 180 each of the addresses within the /127 prefix, at each respective end 181 of the link, must be actively validated by the network operator. A 182 missing /127 address from one end of the link, with a local route 183 pointing out that end of the link that covers the missing /127 184 address, such as a default route, causes a "ping-pong" scenario to 185 exist for the missing /127 address. The link could still be 186 successfully carrying transit traffic, and IPv6 will not report any 187 errors, because IPv6 doesn't require or nor check to ensure all 188 interfaces attached to a link has addresses from all prefixes 189 assigned to the link, excepting the Link-Local prefix per [RFC4291]. 191 It is a valid approach to use /127 for the point-to-point links, 192 however is not future proof considering the comments from the 193 previous section, and older equipment may not support it. 195 4.3. Rationale for using /126 and Other Options 197 /126 was considered by [RFC3627], and despite this document has been 198 obsoleted, because was considering /127 as harmful, the 199 considerations in Section 4.3 are still valid. 201 The same document describes options such as /112 and /120, and all 202 those are commonly used in worldwide IPv6 deployments [IPv6-Survey], 203 though in a lesser degree than /64 or /127. 205 Consequently, we shall conclude that /126, /120 and /112 are valid 206 approaches for the point-to-point links. 208 4.4. A Possible Middle-Term Choice 210 A possible "middle-term" approach, will be to allocate a /64 for each 211 point-to-point link, but use just one /127 out of it, making it 212 future proof and at the same time avoiding possible issues indicated 213 in the previous sections. 215 5. Numbering Choices 217 IPv6 provides different unicast addressing scopes which can be 218 considered when numbering a point-to-point link. 220 It has been reported that certain hardware may consume resources when 221 using numbered links. This is a very specific situation that may 222 need to be consider on a case by case basis. 224 5.1. GUA (Global Unicast Addresses) 226 Using GUA is the most common approach. It provides full 227 functionality for both end-points of the point-to-point link and 228 consequently, facilitates troubleshooting. 230 5.2. ULA (Unique Local Addresses) 232 Some networks use ULAs for numbering the point-to-point links. This 233 approach may cause numerous problems when carrying Internet traffic 234 and therefore, is strongly discouraged. For example, if the CE needs 235 to send an ICMPv6 message to a host outside that network (to the 236 Internet), the packet with ULA source address will not get thru and 237 PMTUD will break, which in turn will completely break that IPv6 238 connection when the MTU is not the same for all the path. 240 ULAs are IPv6 private addresses, not intended to be used as source or 241 destination addresses across the Internet. This issue also exists in 242 IPv4 when using [RFC1918] addresses on links carrying IPv4 Internet 243 traffic. [RFC6752] discusses this issue for IPv4, with much of the 244 discussion applying similarly to IPv6 and ULAs. 246 However, this approach is valid if, following Section 2.2 of 247 [RFC4443], and despite using ULA for the point-to-point link, the 248 router is configured with at least one GUA and the source of the 249 ICMPv6 messages are always a GUA, per the IPv6 Default Address 250 Selection algorithm [RFC6724]. 252 5.3. Link-Local Addresses Only 254 Some networks leave the point-to-point links with only Link-Local 255 addresses used at both ends of the link. This is sometimes 256 improperly referred as "unnumbered", because the Link-Local addresses 257 are also "numbers". Furthermore, [RFC4291] requires that all 258 interfaces attached to a link have at least a Link-Local "number" or 259 address from the Link-Local prefix. 261 [RFC7404] (Using Only Link-Local Addressing inside an IPv6 Network) 262 discusses pros and cons of this alternative, which in general apply 263 for the point-to-point links. 265 While this choice might work if the point-to-point link is terminated 266 in a router, which typically will get configured with a suitable 267 routable GUA or ULA, it will not work for devices that can't be 268 further configured, for example if they do not support DHCPv6-PD. 269 This is the case for hosts, when the Operating System is not expected 270 to be a DHCPv6-PD client and are therefore left without any usable 271 GUA to allow traffic forwarding. 273 In the case of a router, the route for the assigned prefix is pointed 274 towards the link-local address on the router WAN port and the default 275 route on the router is pointed towards the link-local address on the 276 upstream network equipment port. 278 This choice seems easier to implement, compared the previous ones, 279 but it also brings some drawbacks, such as difficulties with 280 troubleshooting and monitoring. For example, link local addresses do 281 not appear in traceroute, so it makes more difficult to locate the 282 exact point of failure. 284 It is more useful in scenarios where it is known that only a router 285 will be attached to the point-to-point link, and where the configured 286 address of the router is known. Non-routers connecting to a network, 287 which can't initiate DHCPv6-PD might experience problems and will 288 stay unnumbered upon connection, if a /64 prefix is not used to 289 number the link. This may be also the case for routers, which will 290 not be able to complete the DHCPv6-PD in unnumbered links. 292 The considerations indicated in the previous section, regarding not 293 using ULA as source address of ICMPv6 messages, and instead ensuring 294 there is at least one GUA configured for that, also apply if link- 295 locals are used for the point-to-point link. 297 6. Prefix Pool Choices 299 The logic choice seems to use a dedicated pool of IPv6 addresses, as 300 this is the way we are "used to" with IPv4. Actually, this is done 301 often by means of different IPv6 pools at every PoP in a service 302 provider network. 304 A possible benefit of using a dedicated IPv6 pool, is that allows 305 applying security policies without harming the customers. This is 306 only true if customers always have a CE at their end of the WAN link. 308 However, the fact that the default IPv6 link size is /64 and commonly 309 multiple /64's are assigned to a single customer, provides an 310 interesting alternative approach for combining "best practices" 311 described in the precedent sections. 313 The following section depicts this alternative. 315 7. /64 from Customer Prefix for point-to-point links 317 Using a /64 from the customer prefix, in addition to the advantages 318 already indicated when using /64, simplifies the addressing plan. 320 The use of /64 also facilitates an easier way for routing the shorter 321 aggregated prefix into the point-to-point link. Consequently it 322 simplifies the "view" of a more unified addressing plan, providing an 323 easier path for following up any issue when operating IPv6 networks 324 and typically, will have a great impact in saving expensive hardware 325 resources (lower usage of TCAM, typically by half). 327 This mechanism would not work in broadcast layer two media that rely 328 on ND, because it will try ND for all the addresses within the 329 shorter prefix that is being routed thru the point-to-point link. 331 7.1. Numbering Interfaces 333 Often, in point-to-point links, hardware tokens are not available, or 334 there is the need to keep certain bits (u, g) cleared, so the links 335 can be manually numbered sequentially with most of the bits cleared 336 to zero. This numbering makes as well easier to remember the 337 interfaces, which typically will become numbered as 0 (with 63 338 leading zero bits) for the provider side and 1 (with 63 leading zero 339 bits) for the customer side. 341 Using interface identifiers as 0 and 1 is not only a very simple 342 approach, but also a very common practice. Other different choices 343 can as well be used as required in each case. 345 On the other hand, using the EUI-64, makes it more difficult to 346 remember and handle the interfaces, but provides an additional degree 347 of protection against port (actually address) scanning as described 348 at [RFC7707]. 350 7.2. Routing Aggregation of the Point-to-Point Links 352 Following this approach and assuming that a shorter prefix is 353 typically delegated to a customer, for example a /48, it is possible 354 to simplify the routing aggregation of the point-to-point links. 355 Towards this, the point-to-point link may be numbered using the first 356 /64 of the /48 delegated to the customer. 358 Let's see a practical example: 360 o A service provider uses the prefix 2001:db8::/32 and is using 361 2001:db8:aaaa::/48 for a given customer. 363 o Instead of allocating the point-to-point link from a different 364 addressing pool, it may use 2001:db8:aaaa::/64 (which is the first 365 /64 subnet from the 2001:db8:aaaa::/48) to number the link. 367 o This means that, in the case the non-EUI-64 approach is used, the 368 point-to-point link may be numbered as 2001:db8:aaaa::1/64 for the 369 provider side and 2001:db8:aaaa::2/64 for the customer side. 371 o Note that using the first /64 and interface identifiers 1 and 2 is 372 a very common practice. However other values may be chosen 373 according to each case specific needs. 375 In this way, as the same address pool is being used for both, the 376 prefix and the point-to-point link, one of the advantages of this 377 approach is to make very easy the recognition of the point-to-point 378 link that belongs to a given customer prefix, or in the other way 379 around, the recognition of the prefix that is linked by a given 380 point-to-point link. 382 For example, making a trace-route to debug any issue to a given 383 address in the provider network, will show a straight view, and it 384 becomes unnecessary one extra step to check a database that correlate 385 an address pool for the point-to-point links and the customer 386 prefixes, as all they are the same. 388 Moreover, it is possible to use the shorter prefix as the provider 389 side numbering for the point-to-point link and keep the /64 for the 390 customer side. In our example, it will become: 392 o Point-to-point link at provider side: 2001:db8:aaaa::1/48 394 o Point-to-point link at customer side: 2001:db8:aaaa::2/64 396 This provides one additional advantage as in some platforms the 397 configuration may be easier saving one step for the route of the 398 delegated prefix (no need for two routes to be configured, one for 399 the delegated prefix, one for the point-to-point link). It is 400 possible because the longest-prefix-match rule. 402 The behavior of this type of configuration has been successfully 403 deployed in different operator and enterprise networks, using 404 commonly available implementations with different routing protocols, 405 including RIP, BGP, IS-IS, OSPF, along static routing, and no 406 failures or interoperability issues have been reported. 408 7.3. DHCPv6 Considerations 410 As stated in [RFC3633], "the requesting router MUST NOT assign any 411 delegated prefixes or subnets from the delegated prefix(es) to the 412 link through which is received the DHCP message from the delegating 413 router", however the approach described in this document is still 414 useful in other DHCPv6 scenarios or non-DHCPv6 scenarios. 416 Furthermore, [RFC3633] was updated by Prefix Exclude Option for 417 DHCPv6-based Prefix Delegation ([RFC6603]), precisely to define a new 418 DHCPv6 option, which covers the case described by this document. 420 Moreover, [RFC3769] has no explicit requirement that avoids the 421 approach described in this document. 423 7.4. Router Considerations 425 This approach is being used by operators in both, residential/SOHO 426 and enterprise networks, so the routers at the customer end for those 427 networks MUST support [RFC6603] if DHCPv6-PD is used. 429 In the case of Customer Edge Routers there is a specific requirement 430 ([RFC7084]) WPD-8 (Prefix delegation Requirements), marked as SHOULD 431 for [RFC6603]. However, in a scenario where the approach described 432 in this document is followed, together with DHCPv6-PD, the CE Router 433 MUST support [RFC6603]. 435 8. Security Considerations 437 This document does not have any new specific security considerations. 439 9. IANA Considerations 441 This document does not have any new specific IANA considerations. 443 10. Acknowledgements 445 The author would like to acknowledge the inputs of Mikael 446 Abrahamsson, Brian Carpenter, Eric Vyncke, Mark Smith and TBD. 448 Acknowledge is also due to my co-authors of RIPE-690 (Best Current 449 Operational Practice for Operators: IPv6 prefix assignment for end- 450 users - persistent vs non-persistent, and what size to choose, 451 https://www.ripe.net/publications/docs/ripe-690) and global 452 community, which provided valuable inputs which have been key for 453 this document. 455 Acknowledgement to co-authors, Cesar Olvera and Miguel Angel Diaz, of 456 a previous related document (draft-palet-v6ops-point2point, 2006), as 457 well as inputs for that version from Alain Durand, Chip Popoviciu, 458 Daniel Roesen, Fred Baker, Gert Doering, Olaf Bonness, Ole Troan, 459 Pekka Savola and Vincent Jardin, are also granted. 461 11. References 463 11.1. Normative References 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, 467 DOI 10.17487/RFC2119, March 1997, 468 . 470 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 471 Host Configuration Protocol (DHCP) version 6", RFC 3633, 472 DOI 10.17487/RFC3633, December 2003, 473 . 475 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 476 Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004, 477 . 479 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 480 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 481 2006, . 483 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 484 Control Message Protocol (ICMPv6) for the Internet 485 Protocol Version 6 (IPv6) Specification", STD 89, 486 RFC 4443, DOI 10.17487/RFC4443, March 2006, 487 . 489 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 490 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 491 DOI 10.17487/RFC4861, September 2007, 492 . 494 [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. 495 Troan, "Prefix Exclude Option for DHCPv6-based Prefix 496 Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, 497 . 499 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 500 "Default Address Selection for Internet Protocol Version 6 501 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 502 . 504 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 505 Requirements for IPv6 Customer Edge Routers", RFC 7084, 506 DOI 10.17487/RFC7084, November 2013, 507 . 509 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 510 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 511 May 2017, . 513 11.2. Informative References 515 [IPv6-Survey] 516 Palet Martinez, J., "IPv6 Deployment Survey (Residential/ 517 Household Services)", January 2018, 518 . 521 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 522 and E. Lear, "Address Allocation for Private Internets", 523 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 524 . 526 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 527 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 528 September 2003, . 530 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 531 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 532 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 533 . 535 [RFC6752] Kirkham, A., "Issues with Private IP Addressing in the 536 Internet", RFC 6752, DOI 10.17487/RFC6752, September 2012, 537 . 539 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 540 Addressing inside an IPv6 Network", RFC 7404, 541 DOI 10.17487/RFC7404, November 2014, 542 . 544 [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix 545 Length Recommendation for Forwarding", BCP 198, RFC 7608, 546 DOI 10.17487/RFC7608, July 2015, 547 . 549 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 550 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 551 . 553 Author's Address 555 Jordi Palet Martinez 556 The IPv6 Company 557 Molino de la Navata, 75 558 La Navata - Galapagar, Madrid 28420 559 Spain 561 EMail: jordi.palet@theipv6company.com 562 URI: http://www.theipv6company.com/