idnits 2.17.1 draft-ietf-v6ops-siit-dc-02.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 non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 11, 2015) is 3181 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'BGP' is mentioned on line 923, but not defined == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-siit-eam-01 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-07) exists of draft-bao-v6ops-rfc6145bis-01 == Outdated reference: A later version (-02) exists of draft-ietf-v6ops-siit-dc-2xlat-01 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Anderson 3 Internet-Draft Redpill Linpro 4 Intended status: Informational August 11, 2015 5 Expires: February 12, 2016 7 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments 8 draft-ietf-v6ops-siit-dc-02 10 Abstract 12 This document describes the use of the Stateless IP/ICMP Translation 13 (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this 14 deployment model, traffic from legacy IPv4-only clients on the 15 Internet is translated to IPv6 upon reaching the IDC operator's 16 network infrastructure. From that point on, it may be treated the 17 same as traffic from native IPv6 end users. The IPv6 endpoints may 18 be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. 19 This facilitates a single-stack IPv6-only network infrastructure, as 20 well as efficient utilisation of public IPv4 addresses. 22 The primary audience is IDC operators who are deploying IPv6, running 23 out of available IPv4 addresses, and/or feel that dual stack causes 24 undesirable operational complexity. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 12, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Single Stack IPv6 Operation . . . . . . . . . . . . . . . 3 62 1.2. Stateless Operation . . . . . . . . . . . . . . . . . . . 4 63 1.3. IPv4 Address Conservation . . . . . . . . . . . . . . . . 4 64 1.4. Clients' IPv4 Source Addresses Visible to Applications . 5 65 1.5. Compatible with Standard IPv4 and IPv6 Stacks . . . . . . 5 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7 68 3.1. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9 69 4. Deployment Considerations and Guidelines . . . . . . . . . . 10 70 4.1. Application/Device Support for IPv6 . . . . . . . . . . . 10 71 4.2. Application Support for NAT . . . . . . . . . . . . . . . 10 72 4.3. Application Communication Pattern . . . . . . . . . . . . 10 73 4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 11 74 4.5. Routing Considerations . . . . . . . . . . . . . . . . . 12 75 4.6. Location of the SIIT-DC Border Relays . . . . . . . . . . 12 76 4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 13 77 4.8. Translation of ICMPv6 Errors to IPv4 . . . . . . . . . . 13 78 4.9. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 13 79 4.9.1. IPv4/IPv6 Header Size Difference . . . . . . . . . . 14 80 4.9.2. IPv6 Atomic Fragments . . . . . . . . . . . . . . . . 14 81 4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6 . . 15 82 4.10. IPv4-translatable IPv6 Service Addresses . . . . . . . . 16 83 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 7.1. Mistaking the Translation Prefix for a Trusted Network . 17 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 89 8.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Appendix A. Complete SIIT-DC IDC topology example . . . . . . . 20 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 94 Historically, dual stack [RFC4213] [RFC6883] has been the recommended 95 way to transition from a legacy IPv4-only environment to one capable 96 of serving IPv6 users. However, for IDC operators, dual stack 97 operation has a number of disadvantages compared to single stack 98 operation. In particular, running two protocols rather than one 99 results in increased complexity and operational overhead, with little 100 return on investment for as long as large parts of the public 101 Internet remains predominantly IPv4-only. Furthermore, the dual 102 stack approach does not in any way help with the depletion of the 103 IPv4 address space, which at the time of writing is a pressing 104 concern in most parts of the world. 106 Therefore, some IDC operators may instead prefer an approach in which 107 they only need to operate one protocol in the data centre as they 108 prepare for the future. SIIT-DC is one such approach. Its design 109 goals include: 111 o Promote the deployment of native IPv6 services (cf. [RFC6540]). 113 o Provide IPv4 service availability for legacy users with no loss of 114 performance or functionality. 116 o To ensure that that the legacy users' IPv4 addresses remain 117 visible to the nodes and applications. 119 o To conserve and maximise the utilisation of the operator's public 120 IPv4 addresses. 122 o To avoid introducing more complexity than absolutely necessary, 123 especially on the nodes and applications. 125 o To be easy to scale and deploy in a fault-tolerant manner. 127 The following subsections elaborates on how SIIT-DC meets these 128 goals. 130 1.1. Single Stack IPv6 Operation 132 SIIT-DC allows IDC operators to build their infrastructure and 133 applications on an IPv6-only foundation. IPv4 end-user connectivity 134 becomes a service provided by the network, which systems 135 administration and application development staff do not need to 136 concern themselves with. This promotes universal IPv6 deployment for 137 the IDC operator's services and applications. 139 SIIT-DC requires no special support or change from the underlying 140 IPv6 infrastructure, it is compatible with all standard IPv6 141 networks. Traffic between IPv6-enabled end users and IPv6-enabled 142 services will always be transported native end-to-end; SIIT-DC does 143 not intercept or handle native IPv6 traffic at all. 145 When the day comes to discontinue all support for IPv4, no change 146 needs to be made to the overall architecture - it's only a matter of 147 shutting off the BRs. Operators who deploy native IPv6 along with 148 SIIT-DC will thus avoid requiring any future migration or deployment 149 projects relating to IPv6 deployment and/or IPv4 sun-setting. 151 1.2. Stateless Operation 153 Unlike other solutions that provide either dual stack availability to 154 single-stack services (e.g., Stateful NAT64 [RFC6146] and Layer-4/7 155 proxies), or that provide conservation of IPv4 addresses (e.g., 156 NAPT44 [RFC3022]), SIIT-DC does not keep any state between each 157 packet in a single connection or flow. In this sense it operates 158 exactly like a regular IP router, and has similar scaling properties 159 - the limiting factors are packets per second and bandwidth. The 160 number of concurrent flows and flow initiation rates are irrelevant 161 for performance. 163 This not only allows individual BRs to easily attain "line rate" 164 performance, it also allows for per-packet load balancing between 165 multiple BRs using Equal-Cost Multipath Routing [RFC2991]. 166 Asymmetric routing is also acceptable, which makes it easy to avoid 167 sub-optimal traffic patterns; the prefixes involved may be anycasted 168 from all the BRs in the provider's network, thus ensuring that the 169 most optimal path through the network is used, even where the optimal 170 path in one direction differs from the optimal path in the opposite 171 direction. 173 Finally, stateless operation means that high availability is easily 174 achieved. If a BR should fail, its traffic can be re-routed onto 175 another BR using a standard IP routing protocol. This does not 176 impact existing flows any more than what any other IP re-routing 177 event would. 179 1.3. IPv4 Address Conservation 180 In most parts of the world, it is difficult or even impossible to 181 obtain generously sized IPv4 delegation from the Internet Numbers 182 Registry System [RFC7020]. The resulting scarcity in turn impacts 183 individual end users and operators, which might be forced to purchase 184 IPv4 addresses from other operators in order to cover their needs. 185 This process can be risky to business continuity, in the case no 186 suitable block for sale can be located, and/or turn out to be 187 prohibitively expensive. In spite of this, an IDC operator will find 188 that providing IPv4 service remains essential, as a large share of 189 the Internet end users still do not have IPv6 connectivity. 191 A key goal of SIIT-DC is to help reduce a data centre operator's IPv4 192 address requirement to the absolute minimum, by allowing the operator 193 to remove them entirely from nodes and applications that do not need 194 to communicate with endpoints in the IPv4 Internet. One example 195 would be servers that are operating in a supporting/back-end role and 196 only communicates with to other servers (database servers, file 197 servers, and so on). Another example would be the network 198 infrastructure itself (router-to-router links, loopback addresses, 199 and so on). Furthermore, as LAN prefix sizes must always be rounded 200 up to the nearest power of two (or larger, if one reserves space for 201 future growth), even more IPv4 addresses will often end up being 202 wasted without even being used. 204 With SIIT-DC, the operator can remove these valuable IPv4 addresses 205 from his back-end servers and network infrastructure, and reassign 206 them to the SIIT-DC service as IPv4 Service Addresses. There exists 207 no requirement that IPv4 Service Addresses are assigned in an 208 aggregated manner, so there is nothing lost due to infrastructure 209 overhead; every single IPv4 address assigned to SIIT-DC can be used 210 an IPv4 Service Address. 212 1.4. Clients' IPv4 Source Addresses Visible to Applications 214 SIIT-DC uses the [RFC6052] algorithm to map the entire end-user's 215 IPv4 source address into an predefined IPv6 Translation Prefix. This 216 ensures that there is no loss of information; the end-user's IPv4 217 source address remains available to the application, allowing it to 218 perform tasks like Geo-Location, logging, abuse handling, and so 219 forth. 221 1.5. Compatible with Standard IPv4 and IPv6 Stacks 222 Except for the introduction of the BRs themselves, no change to the 223 network, nodes, applications, or anything else is required in order 224 to support SIIT-DC. SIIT-DC is practically invisible from the point 225 of view of the IPv4 clients, the IPv6 nodes, the IPv6 data centre 226 network, and the IPv4 Internet. SIIT-DC interoperates with all 227 standards-compliant IPv4 or IPv6 stacks. 229 2. Terminology 231 This document makes use of the following terms: 233 SIIT-DC Border Relay (BR) 234 A device or a logical function that performs stateless protocol 235 translation between IPv4 and IPv6 in accordance with [RFC6145] and 236 [I-D.ietf-v6ops-siit-eam]. 238 SIIT-DC Edge Relay (ER) 239 A device or logical function that provides "native" IPv4 240 connectivity to IPv4-only devices or application software. It is 241 very similar in function to a BR, but is typically located close 242 to the IPv4-only component(s) it is supporting rather than on the 243 IDC's outer network border. The ERs is an optional component of 244 SIIT-DC. It is discussed in more detail in 245 [I-D.ietf-v6ops-siit-dc-2xlat]. 247 IPv4 Service Address 248 A public IPv4 address with which IPv4-only clients communicates. 249 This communication will be translated to IPv6 by a BR. The 250 service's "IN A" DNS record will typically point to the IPv4 251 Service Address. 253 IPv4 Service Address Pool 254 One or more IPv4 prefixes routed to the BR's IPv4 interface. IPv4 255 Service Addresses are allocated from this pool. That this does 256 not necessarily have to be a "pool" per se, as it could also be 257 one or more host routes (whose prefix length is equal to /32). 258 The purpose of using a pool rather than host routes is to 259 facilitate IPv4 route aggregation and ease provisioning of new 260 IPv4 Service Addresses. 262 IPv6 Service Address 263 A public IPv6 address assigned to a node (such as a server or 264 load-balancer) or an individual application in the IPv6 network. 265 IPv6-capable clients communicate directly with the IPv6 Service 266 Address using native IPv6. The service's "IN AAAA" DNS record 267 will typically point to the IPv6 Service Address. IPv4-only 268 clients indirectly communicate with the IPv6 Service Address 269 through SIIT-DC. 271 Explicit Address Mapping (EAM) 272 A bi-directional coupling between an IPv4 Service Address and an 273 IPv6 Service Address configured in a BR or ER. When translating 274 between IPv4 and IPv6, the BR/ER changes the address fields in the 275 translated packet's IP header according to any matching EAM. See 276 [I-D.ietf-v6ops-siit-eam]. 278 Translation Prefix 279 An IPv6 prefix into which the entire IPv4 address space is mapped. 280 This prefix is routed to the BR's IPv6 interface. It is either a 281 Network-Specific Prefix or the Well-Known Prefix 64:ff9b::/96, cf. 282 [RFC6052]. When translating between IPv4 and IPv6, a BR/ER 283 inserts or removes the Translation Prefix from the address fields 284 in the translated packet's IP header, unless an EAM for the IP 285 address being translated exists. 287 IPv4-translatable IPv6 addresses 288 As defined in Section 1.3 of [RFC6052]. 290 IDC 291 Short for "Internet Data Centre"; a data centre whose main purpose 292 is to deliver services to the public Internet, the use case SIIT- 293 DC is primarily targeted at. IDCs are typically operated by 294 Internet Content Providers or Managed Services Providers. 296 SIIT 297 The Stateless IP/ICMP Translation algorithm, as specified in 298 [RFC6145]. 300 XLAT 301 Short for "translation". 303 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 304 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 305 document are to be interpreted as described in [RFC2119]. 307 3. Architectural Overview 309 This section describes the basic SIIT-DC architecture. 311 SIIT-DC Architecture 313 IPv6-capable user IPv4-only user 314 <2001:db8::ab:cd> <203.0.113.50> 315 | | 316 (the IPv6 internet) (the IPv4 Internet) 317 | | 318 | +-[BR]---------<192.0.2.0/24>--------------+ 319 | | | 320 | | EAM #1: 192.0.2.1,2001:db8:12:34::1 | 321 | | EAM #2..#n: [...] | 322 | | XLAT Prefix: 2001:db8:46::/96 | 323 | | | 324 | +------------<2001:db8:46::/96>------------+ 325 | | 326 (the IPv6-only data centre network) 327 | 328 +--<2001:db8:12:34::1>--[v6-only server]-+ 329 | | | 330 | +-[2001:db8:12:34::1]--[v6-only app]-+ | 331 | | AF_INET6 socket | | 332 | +------------------------------------+ | 333 +----------------------------------------+ 335 Figure 1 337 In Figure 1, 192.0.2.0/24 is the IPv4 Service Address Pool. 338 Individual IPv4 Service Addresses are assigned from this prefix, and 339 traffic destined for it is routed to the BR's IPv4-facing network 340 interface. There are no restrictions on how many IPv4 Service 341 Address Pools are used or their prefix length, as long as they are 342 all routed to the BR's IPv4-facing network interface. 344 When translating packets between IPv4 and IPv6, the BR uses the EAM 345 to replace any occurrence of the IPv4 Service Address (192.0.2.1) 346 with its corresponding IPv6 Service Address (2001:db8:12:34::1). 347 Addresses that do not match any EAM configured in the BR are 348 translated by inserting or removing the Translation Prefix 349 (2001:db8:46::/96), cf. Section 2.2 of RFC6052 [RFC6052]. 351 The BR can be deployed as a separate device or as a logical function 352 in another multi-purpose device, such as an IP router. Any number of 353 BRs may exist simultaneously in the IDC's network infrastructure, as 354 long as they all configured with the same Translation Prefix and an 355 identical EAM Table. 357 The IPv6 Service Address of should be registered in DNS using an "IN 358 AAAA" record, while its corresponding IPv4 Service Address should be 359 registered using an "IN A" record. This ensures that IPv6-capable 360 clients access the application/service directly using its native IPv6 361 end-to-end, while IP4-only clients will access it through SIIT-DC. 363 3.1. Packet Flow 365 In this example, the "IPv4-only user" from Figure 1 initiates a 366 connection to the application running on the IPv6-only server. After 367 first having looked up the "IN A" record in DNS, the user starts by 368 transmitting an TCP SYN packet to the IPv4 Service Address. This 369 IPv4 packet is routed to the BR, and is there translated to IPv6 as 370 follows: 372 IPv4 to IPv6 translation 374 +--[IPv4]----------+ +--[IPv6]-----------------------+ 375 | SRC 203.0.113.50 | | SRC 2001:db8:46::203.0.113.50 | 376 | DST 192.0.2.1 | --> | DST 2001:db8:12:34::1 | 377 | TCP SYN [..] | | TCP SYN [..] | 378 +------------------+ +-------------------------------+ 380 Figure 2 382 The resulting IPv6 packet is routed to the IPv6-only server, which 383 processes and responds to it as if it had been a native IPv6 packet 384 all along. The server's IPv6 response packet is then routed back to 385 the BR, where it is translated back to IPv4 as follows: 387 IPv6 to IPv4 translation 389 +--[IPv6]-----------------------+ +--[IPv4]----------+ 390 | SRC 2001:db8:12:34::1 | | SRC 192.0.2.1 | 391 | DST 2001:db8:46::203.0.113.50 | --> | DST 203.0.113.50 | 392 | TCP SYN/ACK [..] | | TCP SYN/ACK [..] | 393 +-------------------------------+ +------------------+ 395 Figure 3 397 It is important to note that neither the IPv4 client nor the IPv6 398 server/application need any special support to participate in SIIT- 399 DC. However, the application may optionally be taught to extract the 400 embedded IPv4 source address from incoming IPv6 packets with source 401 addresses within the Translation Prefix. This will allow it to 402 perform IPv4-specific tasks such as Geo-Location, logging, abuse 403 handling, and so on. 405 4. Deployment Considerations and Guidelines 407 4.1. Application/Device Support for IPv6 409 SIIT-DC as described in this document requires that the application 410 (and/or the node the application is located on) supports IPv6 411 networking, and that it has no dependency on local IPv4 network 412 connectivity. However, SIIT-DC supports IPv4-dependent applications 413 and nodes through the introduction of an ER. The ER provides the 414 application or node with seemingly native IPv4 connectivity, by 415 translating the packets (that were previously translated from IPv4 to 416 IPv6) by the BR back to IPv4 before passing them to the 417 IPv4-dependent application or node. This approach is described in 418 more detail in [I-D.ietf-v6ops-siit-dc-2xlat]. 420 4.2. Application Support for NAT 422 The operator should carefully examine whether or not the application 423 protocols he would like to use SIIT-DC with are able to operate in a 424 network environment where rewriting of IP addresses occur. In 425 general, if an application layer protocol works correctly through 426 standard NAT44 (see [RFC3235]), it will most likely work correctly 427 through SIIT-DC as well. 429 Higher-level protocols that embed IP addresses as part of their 430 payload are particularly problematic [RFC2663] [RFC2993] [RFC3022]. 431 One well-known example of such a protocol is FTP [RFC0959]. Such 432 protocols can be made to work with SIIT-DC through the introduction 433 of an ER, which provides end-to-end IPv4 address transparency by 434 reversing the translations performed by the BR before passing the 435 packets to the NAT-incompatible application. This approach is 436 described in more detail in [I-D.ietf-v6ops-siit-dc-2xlat]. 438 4.3. Application Communication Pattern 440 SIIT-DC is best suited for traditional client/server applications 441 where IPv4-only clients on the Internet initiate traffic towards an 442 IPv6-only service, which in turn is passively listening for inbound 443 traffic and responding as necessary. In this case, an IPv4 client 444 looks exactly like an native IPv6 client from the IPv6 service's 445 point of view, and thus does not require any special treatment. One 446 particularly common application protocol that follows this client/ 447 server communication pattern, and thus is ideally suited for use with 448 SIIT-DC, is HTTP [RFC7230]. 450 It is also possible to combine SIIT-DC with DNS64 [RFC6147] in order 451 to allow an IPv6-only application to initiate communication with 452 IPv4-only nodes through SIIT-DC. However, in this case, care must be 453 taken so that all outgoing communication is sourced from an IPv6 454 Service Address that is found in an EAM configured in the BR. If 455 another address is used, the BR will most likely be unable to 456 translate it to IPv4, causing the packet to be discarded. This could 457 be prevented by altering the Default Address Selection Policy Table 458 [RFC6724] on the IPv6 node. 460 An alternative approach to the above would be to place an ER in front 461 of the application in question, as described 462 [I-D.ietf-v6ops-siit-dc-2xlat]. This provides the application with 463 seemingly native IPv4 connectivity, which it may use freely for bi- 464 directional communication with the IPv4 Internet. An application or 465 node located behind an ER does not need to worry about selecting a 466 specific source address, as it will only have valid options 467 available. 469 4.4. Choice of Translation Prefix 471 Either a Network-Specific Prefix (NSP) from the provider's own IPv6 472 address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96 473 (WKP) may be used. From a technical point of view, both work equally 474 well. However, only a single WKP exists, so if a provider would like 475 to deploy more than one instance of SIIT-DC in his network, or 476 another translation technology such as Stateful NAT64 [RFC6146], the 477 operator will be forced to use an NSP for all but one of those 478 deployments. 480 Another consideration is that the WKP cannot be used in inter-domain 481 routing. By using an NSP instead, SIIT-DC will support a deployment 482 where the BR and the IPv6 Service Address are located in different 483 Autonomous Systems. 485 The Translation Prefix may use any of the lengths described in 486 Section 2.2 of RFC6052 [RFC6052], but /96 has two distinct advantages 487 over the others. First, converting it to IPv4 can be done in a 488 single operation by simply stripping off the first 96 bits; second, 489 it allows for IPv4 addresses to be embedded directly into the text 490 representation of an IPv6 address using the familiar dotted quad 491 notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of RFC6052 492 [RFC6052])), instead of being converted to hexadecimal notation. 493 This makes it easier to write IPv6 ACLs and similar that match 494 translated endpoints in the IPv4 Internet. 496 For the reasons discussed above, this document recommends that an NSP 497 with a prefix length of /96 is used. Section 3.3 of [RFC6052] 498 discusses the choice of translation prefix in more detail. 500 4.5. Routing Considerations 502 The prefixes that constitute the IPv4 Service Address Pool and the 503 IPv6 Translation Prefix may be routed to the BRs as any other IPv4 or 504 IPv6 route in the provider's network. If more than one BR is being 505 deployed, it is recommended that a routing protocol (IGP) used to 506 advertise the routes within the provider's network. This will ensure 507 that the traffic that is to be translated will reach the closest BR, 508 reducing or eliminating sub-optimal traffic patterns, as well as 509 providing high availability: Should one BR fail, the IGP will 510 automatically redirect the traffic to the closest alternate BR. 512 4.6. Location of the SIIT-DC Border Relays 514 The goal of SIIT-DC is to facilitate a true IPv6-only application and 515 network architecture, with the sole exception being the IPv4 516 interfaces of the BRs and the network infrastructure required to 517 connect the BRs to the IPv4 Internet. Therefore, the BRs must be 518 located somewhere between the IPv4 Internet and the application 519 delivery stack. This should be understood to include all servers, 520 load balancers, firewalls, intrusion detection systems, and similar 521 devices that are processing traffic to a greater extent than merely 522 forwarding it. 524 It is optimal to place the BRs as close as possible to the direct 525 path between the location of the IPv6 Service Address and the end 526 users. If the closest BR was located a long way from the direct 527 path, all packets in both directions must make a detour in order to 528 traverse the BR. This would increase the RTT between the service and 529 the end user by by two times the extra latency incurred by the 530 detour, as well as cause unnecessary load on the network links on the 531 detour path. 533 Where possible, it is beneficial to implement the BRs as a logical 534 function within the routers would have handled the traffic anyway, 535 had the topology been dual stacked. This way, a SIIT-DC deployment 536 does not require separate networks ports (which might become 537 saturated and impact the service quality), nor will it require extra 538 rack space and energy. Some particularly good choices of the 539 location could be within an IDC's access routers, or within the 540 Autonomous System's border routers. 542 Finally, another possibility is that the IDC operator outsources the 543 SIIT-DC service to another entity, for example his upstream ISP. 544 Doing so allows the IDC operator to build a true IPv6-only 545 infrastructure. 547 4.7. Migration from Dual Stack 549 While this document mainly discusses the use of IPv6-only nodes and 550 applications, it is important to note that SIIT-DC is fully 551 compatible with dual stack infrastructures, including dual stack 552 nodes and applications. 554 Thus, migrating a dual-stacked service to an IPv6-only one where 555 SIIT-DC provides the IPv4 Internet connectivity is easy. The 556 operator would start out by designating the service's current native 557 IPv6 address as the IPv6 Service Address, and assign it a 558 corresponding IPv4 Service Address. At this point, the service will 559 respond on both its old (native) IPv4 address, and the SIIT-DC IPv4 560 Service Address. The operator may now move traffic from the former 561 to the latter by changing the service's "IN A" DNS record. Once all 562 IPv4 traffic has been successfully moved to SIIT-DC, the old IPv4 563 address may be reclaimed. 565 4.8. Translation of ICMPv6 Errors to IPv4 567 In response to an IPv4 packet subsequently translated to IPv6 by the 568 BR, an IPv6 router in the IDC network may need to transmit an ICMPv6 569 error back to the origin IPv4 node. By default, such an ICMPv6 error 570 will most likely be discarded by the BR, unless the source address of 571 the ICMPv6 error happens to be a IPv4-translatable IPv6 address or 572 covered by an EAM. 574 To facilitate reliable delivery of such ICMPv6 errors, an SIIT-DC 575 operator SHOULD implement the recommendations in [RFC6791] in the 576 BRs. 578 4.9. MTU and Fragmentation 580 There are some key differences between IPv4 and IPv6 relating to 581 packet sizes and fragmentation that one should consider when 582 deploying SIIT-DC. They result in a few problematic corner cases, 583 which can be dealt with in a few different ways. The following 584 subsections will discuss these in detail, and provide operational 585 guidance. 587 In particular, the operator may find that relying on fragmentation in 588 the IPv6 domain is undesired or even operationally impossible 589 [I-D.taylor-v6ops-fragdrop]. For this reason, the recommendations in 590 this section seeks to minimise the use of IPv6 fragmentation. 592 Unless otherwise stated, the following subsections assume that the 593 MTU in both the IPv4 and IPv6 domains is 1500 bytes. 595 4.9.1. IPv4/IPv6 Header Size Difference 597 The IPv6 header is up to 20 bytes larger than the IPv4 header. This 598 means that a full-size 1500 bytes large IPv4 packet cannot be 599 translated to IPv6 without being fragmented, otherwise it would 600 likely have resulted in a 1520 bytes large IPv6 packet. 602 If the transport protocol used is TCP, this is generally not a 603 problem, the IPv6 node will advertise a TCP MSS of 1440 bytes during 604 the initial TCP handshake. This causes the IPv4 clients to never 605 send larger packets than what can be translated to a single full-size 606 IPv6 packet, eliminating any need for fragmentation. 608 For other transport protocols, full-size IPv4 packets with the DF 609 flag cleared will need to be fragmented by the BR. This may be 610 avoided by increasing the Path MTU between the BR and the IPv6 nodes 611 to 1520 bytes or greater. If this is done, the MTU on the IPv6 nodes 612 themselves SHOULD NOT be increased accordingly, as doing so would 613 cause them to undergo Path MTU Discovery for all destinations on the 614 IPv6 Internet. The nodes MUST however be able to accept and process 615 incoming packets larger than their own MTU. If the nodes' IPv6 616 implementation allows the initial Path MTU to be set differently for 617 specific destinations, it MAY be increased to 1520 for destinations 618 within the Translation Prefix specifically. 620 4.9.2. IPv6 Atomic Fragments 622 In keeping with the fifth paragraph of Section 4 of RFC6145 623 [RFC6145], a stateless translator like a BR will by default add an 624 IPv6 Fragmentation header to the resulting IPv6 packet when 625 translating an IPv4 packet with the Don't Fragment flag set to 0. 626 This happens even though the resulting IPv6 packet isn't actually 627 fragmented into several pieces, resulting in an IPv6 Atomic Fragment 628 [RFC6946]. These Atomic Fragments are generally not useful in an IDC 629 environment, and it is therefore recommended that this behaviour is 630 disabled in the BRs. To this end, Section 4 of RFC6145 [RFC6145] 631 notes that the "translator MAY provide a configuration function that 632 allows the translator not to include the Fragment Header for the non- 633 fragmented IPv6 packets". 635 Note that IPv6 Atomic Fragments are currently being deprecated by 636 RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that 637 conforms to the updated standard is required to behave as recommended 638 above. 640 In IPv6, the Identification value is located inside the Fragmentation 641 header. That means that if the generation of IPv6 Atomic Fragments 642 is disabled, the IPv4 Identification value will be lost during 643 translation to IPv6. This could potentially confuse some diagnostic 644 tools. 646 4.9.3. Minimum Path MTU Difference Between IPv4 and IPv6 648 Section 5 of RFC2460 [RFC2460] specifies that the minimum IPv6 link 649 MTU is 1280 bytes. Therefore, an IPv6 node can reasonably assume 650 that if it transmits an IPv6 packet that is 1280 bytes or smaller, it 651 is guaranteed to reach its destination without requiring 652 fragmentation or invoking the Path MTU Discovery algorithm [RFC1981]. 653 However, this assumption might prove false if the destination is an 654 IPv4 node reached through a protocol translator such as a BR, as the 655 minimum IPv4 link MTU is 68 bytes. See Section 3.2 of RFC791 656 [RFC0791]. 658 Section 5.1 of RFC6145 [RFC6145] specifies that a stateless 659 translator should set the IPv4 Don't Fragment flag to 1 when it 660 translates a non-fragmented IPv6 packet to IPv4. This means that 661 when the path to the destination IPv4 node contains an IPv4 link with 662 an MTU smaller than 1260 bytes (which corresponds to an IPv6 MTU 663 smaller than 1280 bytes, cf. Section 4.9.1), the Path MTU Discovery 664 algorithm will be invoked, even if the original IPv6 packet was only 665 1280 bytes large. This happens as a result of the IPv4 router 666 connecting to the IPv4 link with the small MTU returning an ICMPv4 667 Need To Fragment error with an MTU value smaller than 1260, which in 668 turns is translated by the BR to an ICMPv6 Packet Too Big error with 669 an MTU value smaller than 1280 which is then transmitted to the 670 origin IPv6 node. 672 When an IPv6 node receives an ICMPv6 Packet Too Big error indicating 673 an MTU value smaller than 1280, the last paragraph of Section 5 of 674 RFC2460 [RFC2460] gives it two choices on how to proceed: 676 o It may reduce its Path MTU value to the value indicated in the 677 Packet Too Big, i.e., limit the size of subsequent packets 678 transmitted to that destination to the indicated value. This 679 approach causes no problems for the SIIT-DC function, as it simply 680 allows Path MTU Discovery to work transparently across the BR. 682 o It may reduce its Path MTU value to exactly 1280, and in addition 683 include a Fragmentation header in subsequent packets sent to that 684 destination. In other words, the IPv6 node will start emitting 685 Atomic Fragments. The Fragmentation header signals to the the BR 686 that the Don't Fragment flag should be set to 0 in the resulting 687 IPv4 packet, and it also provides the Identification value. 689 If the use of the IPv6 Fragmentation header is problematic, and the 690 operator has IPv6 nodes that implement the second option above, the 691 operator should consider enabling the functionality described as the 692 "second approach" in Section 6 of RFC6145 [RFC6145]. This 693 functionality changes the BR's behaviour as follows: 695 o When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big, 696 the resulting packet will never contain an MTU value lower than 697 1280. This prevents the IPv6 nodes from generating Atomic 698 Fragments. 700 o When translating IPv6 packets smaller than or equal to 1280 bytes, 701 the Don't Fragment flag in the resulting IPv4 packet will be set 702 to 0. This ensures that in the eventuality that the path contains 703 an IPv4 link with an MTU smaller than 1260, the IPv4 router 704 connected to that link will have the responsibility to fragment 705 the packet before forwarding it towards its destination. 707 In summary, this approach could be seen as prompting the IPv4 708 protocol itself to provide the "link-specific fragmentation and 709 reassembly at a layer below IPv6" required for links that "cannot 710 convey a 1280-octet packet in one piece", to paraphrase Section 5 of 711 RFC2460 [RFC2460]. 713 Note that IPv6 Atomic Fragments are currently being deprecated by 714 RFC6145bis [I-D.bao-v6ops-rfc6145bis]. As a result, a BR that 715 conforms to the updated standard is required to behave as suggested 716 above. 718 4.10. IPv4-translatable IPv6 Service Addresses 720 SIIT-DC is designed so that the IPv6 Service Addresses are not 721 required to be IPv4-translatable IPv6 addresses. Section 2 of I-D 722 .ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam] discusses why it is 723 desirable to avoid requiring the use of IPv4-translatable IPv6 724 addresses. 726 It is however quite possible to deploy SIIT-DC in combination with 727 IPv4-translatable IPv6 Service Addresses. The primary benefits in 728 doing so are: 730 o The operator is not required to provision EAMs for 731 IPv4-translatable IPv6 Service Addresses onto the BR/ERs. 733 o [RFC6145] translation can be performed in a checksum-neutral 734 manner, cf. Section 4.1 of RFC6052 [RFC6052]. 736 The trade-off is that the IPv4-translatable IPv6 Service Addresses 737 must be configured on the IPv6 nodes, and the applications must be 738 set up to use them - likely in addition to their primary (non- 739 IPv4-translatable) IPv6 addresses. The IPv4-translatable IPv6 740 Service Addresses must also be routed from the BR through the IDC's 741 IPv6 network infrastructure to the nodes on which they are assigned. 742 This essentially requires the entire IPv6 infrastructure to be made 743 aware of and handle translated IPv4 traffic as a special case, which 744 significantly increases complexity. Avoiding such drawbacks is a 745 design goal of SIIT-DC, cf. Section 1.1, therefore the use of 746 IPv4-translatable IPv6 Service Addresses is discouraged. 748 5. Acknowledgements 750 The author would like to thank the following individuals for their 751 contributions, suggestions, corrections, and criticisms: Fred Baker, 752 Cameron Byrne, Brian E Carpenter, Ross Chandler, Dagfinn Ilmari 753 Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed, 754 Andrew Yourtchenko. 756 6. IANA Considerations 758 This draft makes no request of the IANA. The RFC Editor may remove 759 this section prior to publication. 761 7. Security Considerations 763 7.1. Mistaking the Translation Prefix for a Trusted Network 765 If a Network-Specific Prefix from the provider's own address space is 766 chosen for the translation prefix, as recommended in Section 4.4, 767 care must be taken if the translation service is used in front of 768 services that have application-level ACLs that distinguish between 769 the operator's own networks and the Internet at large, as traffic 770 from translated IPv4 end users on the Internet might appear to be 771 originating from the provider's own network. It is therefore 772 important that the translation prefix is treated the same as the 773 Internet at large, rather than as a trusted network. 775 In order to alleviate this problem, the operator may opt to use a 776 Translation Prefix that is distinct from and not a subset of the IPv6 777 prefixes used elsewhere in the network infrastructure. 779 8. References 781 8.1. Normative References 783 [I-D.ietf-v6ops-siit-eam] 784 Anderson, T. and A. Leiva, "Explicit Address Mappings for 785 Stateless IP/ICMP Translation", draft-ietf-v6ops-siit- 786 eam-01 (work in progress), June 2015. 788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 790 RFC2119, March 1997, 791 . 793 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 794 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 795 DOI 10.17487/RFC6052, October 2010, 796 . 798 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 799 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 800 . 802 [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. 803 Huston, "Stateless Source Address Mapping for ICMPv6 804 Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, 805 . 807 8.2. Informative References 809 [I-D.bao-v6ops-rfc6145bis] 810 Li, X., Bao, C., Baker, F., Anderson, T., and F. Gont, "IP 811 /ICMP Translation Algorithm (rfc6145bis)", draft-bao- 812 v6ops-rfc6145bis-01 (work in progress), August 2015. 814 [I-D.ietf-v6ops-siit-dc-2xlat] 815 Anderson, T. and S. Steffann, "SIIT-DC: Dual Translation 816 Mode", draft-ietf-v6ops-siit-dc-2xlat-01 (work in 817 progress), June 2015. 819 [I-D.taylor-v6ops-fragdrop] 820 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 821 M., and T. Taylor, "Why Operators Filter Fragments and 822 What It Implies", draft-taylor-v6ops-fragdrop-02 (work in 823 progress), December 2013. 825 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 826 10.17487/RFC0791, September 1981, 827 . 829 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 830 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 831 . 833 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 834 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 835 1996, . 837 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 838 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 839 December 1998, . 841 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 842 Translator (NAT) Terminology and Considerations", RFC 843 2663, DOI 10.17487/RFC2663, August 1999, 844 . 846 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 847 Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/ 848 RFC2991, November 2000, 849 . 851 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 852 DOI 10.17487/RFC2993, November 2000, 853 . 855 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 856 Address Translator (Traditional NAT)", RFC 3022, DOI 857 10.17487/RFC3022, January 2001, 858 . 860 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 861 Application Design Guidelines", RFC 3235, DOI 10.17487/ 862 RFC3235, January 2002, 863 . 865 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 866 for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/ 867 RFC4213, October 2005, 868 . 870 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 871 NAT64: Network Address and Protocol Translation from IPv6 872 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 873 April 2011, . 875 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 876 Beijnum, "DNS64: DNS Extensions for Network Address 877 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 878 DOI 10.17487/RFC6147, April 2011, 879 . 881 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 882 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 883 RFC 6540, DOI 10.17487/RFC6540, April 2012, 884 . 886 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 887 "Default Address Selection for Internet Protocol Version 6 888 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 889 . 891 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 892 Content Providers and Application Service Providers", RFC 893 6883, DOI 10.17487/RFC6883, March 2013, 894 . 896 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 897 6946, DOI 10.17487/RFC6946, May 2013, 898 . 900 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 901 Internet Numbers Registry System", RFC 7020, DOI 10.17487/ 902 RFC7020, August 2013, 903 . 905 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 906 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 907 7230, DOI 10.17487/RFC7230, June 2014, 908 . 910 Appendix A. Complete SIIT-DC IDC topology example 912 Figure 4 attempts to "tie it all together" and show a more complete 913 SIIT-DC topology, in order to better demonstrate its advantageous 914 properties discussed in Section 1. These are discussed in more 915 detail below. 917 Example SIIT-DC IDC topology 919 /--------------------------------\ /---------------\ 920 | IPv4 Internet | | IPv6 Internet | 921 \-+----------------------------+-/ \--------+------/ 922 | | | 923 | <----------[BGP]---------> | [BGP] 924 | | | 925 +-------<192.0.2.0/24>---------+ +---<192.0.2.0/24>---+ | 926 | BR #1 | | BR #2 | | 927 | EAM Table: | | | | 928 | ========== | | | | 929 | 192.0.2.1,2001:db8:12:34::1 | | | | 930 | 192.0.2.2,2001:db8:12:34::2 | | Exactly the same | | 931 | 192.0.2.3,2001:db8:fe:dc::1 | | configuration as | | 932 | 192.0.2.4,2001:db8:12:34::4 | | BR #1 has | | 933 | 192.0.2.5,2001:db8:fe:dc::e | | | | 934 | | | | | 935 | XLAT Prefix 2001:db8:46::/96 | | | | 936 | | | | | 937 +--------<2001:db8:46::/96>----+ +-<2001:db8:46::/96>-+ | 938 | | | 939 | <------[ECMP]------> | | 940 | | | 941 /-----------------+----------------------+--\ | 942 | IPv6 IDC network w/OSPFv3 +------------/ 943 \-+--------------------------------+--------/ 944 | | 945 | Tenant A's server LAN | Tenant B's server LAN 946 | 2001:db8:12:34::/64 | 2001:db8:fe:dc::/64 947 | | 948 +-- www ::1 (IPv6+SIIT-DC) +-- www-lb ::1 (IPv6+SIIT-DC) 949 | | 950 +-- mta ::2 (IPv6+SIIT-DC) +-- web ::80:01 (IPv6-only) 951 | | [...] 952 +-- ftp ::3 (IPv6) +-- web ::80:99 (IPv6-only) 953 | ::4 (IPv4, via ER) | 954 | | +----+ 955 +-- app01 ::a:01 (IPv6-only) \---- ::e | ER | --\ 956 | [...] +----+ | 957 +- app99 ::a:99 (IPv6-only) | 958 | ftp 192.0.2.5 ---/ 959 +-- db01 ::d:01 (IPv6-only) 960 | [..] 961 \-- db99 ::d:99 (IPv6-only) 963 Figure 4 965 Single Stack IPv6 Operation 966 As discussed in Section 1.1, SIIT-DC facilitates an IPv6-only IDC 967 network infrastructure. The only places where IPv4 is absolutely 968 required is between the BRs and the IPv4 Internet, and between any 969 ERs and the IPv4-only applications or devices they are serving 970 (illustrated here as the two tenants' FTP servers). The figure 971 also illustrates how SIIT-DC does not interfere with native IPv6; 972 when there is no longer a need to support IPv4 clients, the BRs 973 may be decommissioned without causing any impact to native IPv6 974 traffic. 976 Stateless Operation 977 As discussed in Section 1.2, SIIT-DC operates in a stateless 978 fashion. In the illustration, both BRs are simultaneously 979 advertising (i.e., anycasting) the IPv4 Service Address Pool and 980 the IPv6 Translation Prefix, so incoming traffic from the IPv4 981 Internet may arrive at either of the BRs, while outgoing IPv6 982 traffic destined for IPv4 endpoints are load balanced between them 983 using Equal-Cost Multipath Routing. No continuous state 984 synchronisation between the two BRs occurs. Should one of the BRs 985 fail, the BGP and OSPF protocols will ensure that traffic 986 converges on the remaining BR. Existing sessions will not be 987 disrupted, beyond any disruption caused by the BGP/OSPF 988 convergence process itself. 990 IPv4 Address Conservation 991 As discussed in Section 1.3, SIIT-DC conserves the IDC operator's 992 IPv4 address space. Even though the two customers in the example 993 above have several hundred servers, the majority of them are not 994 used to run services made available directly from the Internet, 995 and therefore do not need to consume IPv4 addresses. The IDC 996 network infrastructure consumes no IPv4 addresses, either. 997 Finally, the IPv4 addresses that are assigned to the SIIT-DC 998 function as IPv4 Service Address Pools may assigned with 100% 999 efficiency, one address at a time; there is no requirement to 1000 assign multiple addresses to a single customer in a contiguous 1001 block. 1003 Application support 1004 As discussed in Section 1.5, as long as the application protocol 1005 is translation-friendly (illustrated here with HTTP and SMTP), it 1006 will work with SIIT-DC without requiring any special adaptation. 1007 Furthermore, translation-unfriendly applications (illustrated here 1008 with FTP) will also work when located behind an ER 1009 [I-D.ietf-v6ops-siit-dc-2xlat]. Tenant A's FTP server illustrates 1010 how an ER may be located in the networking stack of a node, while 1011 Tenant B's FTP server illustrates how the ER may be deployed as a 1012 network service. The latter approach enables SIIT-DC to support 1013 IPv4-only nodes/devices. 1015 Author's Address 1017 Tore Anderson 1018 Redpill Linpro 1019 Vitaminveien 1A 1020 0485 Oslo 1021 Norway 1023 Phone: +47 959 31 212 1024 Email: tore@redpill-linpro.com 1025 URI: http://www.redpill-linpro.com