idnits 2.17.1 draft-dupont-6man-nat64handoff-00.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 (April 4, 2019) is 1839 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Dupont 3 Internet-Draft April 4, 2019 4 Intended status: Standards Track 5 Expires: October 6, 2019 7 NAT64 Handoff 8 draft-dupont-6man-nat64handoff-00 10 Abstract 12 This document describes a NAT64 extension which allows IPv4 hosts to 13 learn the real IP address of hosts which they are communicating with 14 and assume responsibility to maintain the authoritative connection 15 tracking table. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 6, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Communication model . . . . . . . . . . . . . . . . . . . . . 3 54 4. Packet formats . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Packet formats from NAT64 to server . . . . . . . . . . . . . 7 56 6. Packet formats from server to NAT64 . . . . . . . . . . . . . 7 57 7. Multiple connection tracking entry format . . . . . . . . . . 7 58 8. NAT64 operation . . . . . . . . . . . . . . . . . . . . . . . 8 59 9. Token validation . . . . . . . . . . . . . . . . . . . . . . 10 60 10. Server operation . . . . . . . . . . . . . . . . . . . . . . 11 61 11. Server side NAT . . . . . . . . . . . . . . . . . . . . . . . 12 62 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 14. Normative References . . . . . . . . . . . . . . . . . . . . 14 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 67 1. Introduction 69 Due to shortage of IPv4 addresses various models of NAT are seeing 70 widespread usage as a way to reach IPv4-only services. The use of 71 NAT has some drawbacks. This document aims to address two of those 72 drawbacks by providing an extension for NAT64. 74 Connection tracking entries on the NAT can be expired due to 75 idleness. When doing such expiry the NAT has no way of knowing if 76 the entry was still in use and may cause connections between client 77 and server to be interrupted. 79 The server doesn't know the real IP address of the client. For the 80 purpose of debugging software bugs and investigating abuse all 81 clients using the same NAT device will appear indistinguishable to 82 the server. 84 This document provides a NAT64 extension which aims to solve these 85 two drawbacks by allowing the server to assume responsibility to 86 maintain the authoritative version of the connection tracking table 87 and allowing the NAT64 to only maintain a cache in which entries can 88 be purged without causing connections to be interrupted. 90 2. Terminology 92 NAT64: A dual-stack host translating TCP and UDP according to 93 [RFC6146] and implementing the NAT64 handoff protocol as specified in 94 this document. 96 Server: An IPv4 host implementing the server component of 97 Client: An IPv6 host which initiates communication through a NAT64 98 capable NAT64. 100 NAT64 handoff: The UDP based protocol specified in this document to 101 exchange connection tracking between NAT64 and server. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 107 as shown here. 109 3. Communication model 111 The communication model involves a many-to-many relation between 112 clients and NAT64 devices as well as a many-to-many relation between 113 NAT64 devices and servers. 115 Application data is transmitted and translated according to 116 [RFC6146]. This document adds a control channel between NAT64 and 117 server. There is a separate control channel per NAT64 and server 118 pair. The control channel is uniquely identified by the pair of IPv4 119 addresses of the NAT64 and server. 121 +--------+ +--------+ +--------+ +--------+ 122 | Client | | Client | | Client | | Client | 123 +--------+ +--------+ +--------+ +--------+ 124 | | | | 125 +-----------+-----+------+-------------+ 126 | 127 +------------V-----------+ 128 | NAT64 | 129 +------------------------+ 130 | | 131 Application | | Control 132 | | 133 +----------V---V---------+ 134 | Server | 135 +------------------------+ 136 Figure 1: The communication model 138 This protocol aims to move as much state as possible from the NAT64 139 to the server and change the remaining state still needed on NAT64 to 140 serve as a cache which can be purged as needed and repopulated from 141 the server. 143 Protection against IP spoofing is done through the use of tokens in 144 the control channel messages. These tokens are chosen by the NAT64 145 in order to allow the NAT64 to use a stateless algorithm to generate 146 tokens. 148 4. Packet formats 150 The NAT64 handoff packets are UDPv4 packets exchanged between a port 151 on the IPv4 address of the NAT64 and the NAT64 handoff server port 152 (TBD) on the IPv4 address of the server. The UDP payload consist of 153 a sequence of messages. 155 Message formats are determined by the first nibble of the message. 156 Following message formats are defined: 158 0 - Reserved to avoid ambiguity in message parsing if NAT64 159 handoff and Teredo are ever accidentally or deliberately mixed 160 on the same port. 162 1 - Reserved for future extensions. 164 2 - Reserved for future extensions. 166 3 - NAT64 handoff messages. 168 4 - IPv4 packet. 170 5 - Reserved for future extensions. 172 6 - IPv6 packet. 174 7-15 - Reserved for future extensions. 176 An implementation of NAT64 handoff MUST support packet formats 3, 4, 177 and 6. A packet containing a message of an unknown format MUST be 178 silently dropped. 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 181 | 3 | Type | Msg Data Len | Message Data 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 184 Type 4-bit identifier of the type of message. 186 Msg Data Len 8-bit unsigned integer. Length of the Message Data 187 field of this message, in 16 bit units. 189 Message Data Variable-length field. Message-Type-specific data. 191 0 - Reserved for future extensions 192 1 - Protocol identifier 194 2 - No-op 196 3 - Invalid 198 4 - Token 200 5 - Token rotation 202 6 - Remote IPv6 address authenticator 204 7 - Connection tracking entry 206 8 - Mapped port hint 208 9-15 - Reserved for future extensions 210 An implementation of the NAT64 handoff server component MUST 211 understand messsage types 4, 5, 6, and 7 and SHOULD understand 212 message types 1 and 8. An implementation of NAT64 with handoff 213 extension MUST understand message types 4, 6, and 7. 215 An implementation of either component MUST ignore messages of unknown 216 types. 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 219 | 3 | 1 | 72 | Message Data 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 222 Message data must be the 144 octet string 224 "[[ This is the NAT64 handoff protocol. The client is using " 225 "IPv6. To know their real IP address you need to use this " 226 "protocol or support IPv6. ]]" 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 229 | 3 | 4/5/6 | Msg Data Len | Message Data 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 232 For message types 4, 5, and 6 the NAT64 choose the contents of 233 message data and its length. The length of message data MUST be an 234 even number of octets and at most 510 octets. The message data 235 SHOULD be generated as a Message Authentication Code of at least 16 236 octets using a secret key known only to the NAT64 itself. The server 237 MUST accept message data of any length from 0 to 510 octets. 239 For message type 4 message data SHOULD be a MAC of the server IPv4 240 address computed using a key known only to the NAT64. 242 For message type 5 message data MUST be computed the same way as 243 message type 4 but using the most recently expired key. 245 For message type 6 message data should be a MAC of the server IPv4 246 address and client IPv6 address computed using a key known only to 247 the NAT64. 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | 3 | 7 | 16 | Mapped port number | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 + + 254 | NAT64 /96 prefix | 255 + + 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 + + 260 | | 261 + Client IPv6 address + 262 | | 263 + + 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Client port number | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | 3 | 8 | 1 | Suggested port number | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Not every concatenation of messages form a valid packet. With the 274 exception of the multi-connection-tracking-entry format explained 275 below a packet MUST NOT contain more than one message of each type. 276 When a receiver parses a message containing multiple messages of same 277 type it MAY pick one message of each type to process and ignore the 278 rest. The sender MAY put the messages in a packet in any order. 280 Any IPv4 or IPv6 packet included in a control channel packet MUST be 281 the last message in the packet. The receiver MAY stop parsing once 282 it sees an IPv4 or IPv6 packet. This also means that a sender is not 283 allowed to include both an IPv4 and an IPv6 packet in the same 284 control channel message. 286 5. Packet formats from NAT64 to server 288 All control channel packets from NAT64 to server MUST include a token 289 message (message type 4). And they MUST include at least one of 290 connection tracking entry (message type 7), IPv4 packet, IPv6 packet. 291 Any IPv4 or IPv6 packet sent from NAT64 to server must be the before 292 translation version of the packet. 294 A packet with a connection tracking entry (messsage type 7), must 295 include a protocol identifier (message type 1) and remote IPv6 296 address authenticator (message type 6). 298 A packet with an IPv6 packet must include a remote IPv6 address 299 authenticator (message type 6). It MAY include a mapped port hint 300 (message type 8). 302 6. Packet formats from server to NAT64 304 All control channel packets from server to NAT64 MUST satisfy at 305 least one of the following three requirements. 307 Include a token message (message type 4) and an IPv4 packet before 308 or after translation. 310 Include a remote IPv6 address authenticator (message type 6) and a 311 post-translation IPv6 packet. 313 Include a remote IPv6 address authenticator (message type 6) and a 314 connection tracking entry (messsage type 7). Packets of this 315 format MAY include any IPv4 or IPv6 packet before or after 316 translation. 318 7. Multiple connection tracking entry format 320 Packets sent from NAT64 to server may follow the format in this 321 section. This is the only packet format which permits multiple 322 messages of the same type. 324 The packet must contain a protocol identifier (message type 1) and a 325 token (message type 4). 327 The packet must contain one or more groups of messages in which each 328 group consists of exactly one remote IPv6 address authenticator 329 (message type 6) followed by one or more connection tracking entries 330 (messsage type 7). The remote IPv6 address authenticator must be 331 valid for all connection tracking entries in the group. 333 The UDP payload MUST NOT exceed 1232 octets. 335 The packet must not contain an IPv4 or IPv6 packet. 337 8. NAT64 operation 339 Upon receiving a packet the NAT64 must first classify the packet as 340 one of the following: 342 Packet subject to NAT 344 Control plane packet 346 ICMP packet 348 Packet with invalid destination IP 350 IPv4 packets are classified as follows: 352 Incoming packets with destination address different from the NAT64 353 public IPv4 address are considered as invalid destination. 355 Packets with protocol number 1 are ICMP. 357 Packets sent from UDP port (TBD) to the client side port (chosen 358 by NAT64) are control packets. 360 Packets with destination port 80 may be treated as HTTP. 362 All other packets are subject to NAT. 364 IPv6 packets are classified as follows: 366 If destination address is within one of the NAT64 prefixes 367 configured on this NAT64 and the first octet of the embedded IPv4 368 address is not 0 or 127 the packet is subject to NAT. 370 Any other destination address is considered as invalid 371 destination. 373 IPv4 packets subject to NAT are handled as follows: 375 If it is neither TCP nor UDP forward it over the control 376 connection to the server. 378 If it matches a cached connection tracking entry from the server 379 perform translation. 381 If it matches a NAT64 generated connection which has previously 382 been used with this IPv4 address perform translation. 384 If it matches a NAT64 generated connection which has not been used 385 with this IPv4 address and no valid control packets have ever been 386 received from that server IPv4 address the NAT64 can choose 387 between performing translation and sending the packet over the 388 control channel to the server. 390 Otherwise send the packet over the control channel to the server. 392 IPv6 packets subject to NAT are handled as follows: 394 If it is neither TCP nor UDP forward it over the control 395 connection to the server. 397 If it matches a cached connection tracking entry from the server 398 perform translation. 400 If it matches a NAT64 generated connection entry which has 401 previously been used with this IPv4 address perform translation. 403 If a valid control packet has previously been received from this 404 server IPv4 address forward it over the control connection to the 405 server. 407 If no NAT64 generated connection tracking entry exists for this 408 source IPv6/port create an entry. Record that the entry (new or 409 existing) has been used with this server IPv4 address. Perform 410 translation. 412 ICMP error messages containing a (truncated) IPv4 error are handled 413 as follows: 415 If the ICMP packet has invalid checksum it is silently dropped. 417 If the embedded packet source address does not match the NAT64 418 public IPv4 address, the ICMP error is silently dropped. 420 If the embedded IP payload is an ICMP packet, handle the packet 421 according to [RFC0792] considering the NAT64 itself to be the 422 final destination of the packet. 424 If the embedded packet is a UDP packet from the client side port 425 (chosen by NAT64) to the server side port (TBD) it's considered to 426 be an undelivered control packet and is silently dropped. If the 427 origin IP of the ICMP error matches the destination IP of the 428 inner IP packet, and the ICMP error has type 3 and code 3, and the 429 payload contains a valid token, the NAT64 must consider the 430 handoff server to be down. The NAT64 must switch back to 431 generating connection entries as if that server IPv4 address never 432 supported handoff in the first place. Any previously cached 433 connection entries from that server must be kept in cache and 434 expired as if the server was still responding. Once the server is 435 confirmed to be responding again the still cached connection 436 entries must be sent to the server. 438 If the embedded IP payload is not TCP or UDP forward the packet 439 over the control connection to the source IP of the embedded IP 440 payload. 442 If the embedded IP payload matches a cached connection from the 443 server perform translation. 445 If the embedded IP payload matches a NAT64 generated connection 446 previously used with the destination IP of the embedded IP packet 447 perform translation. 449 Otherwise forward the packet over the control connection to the 450 source IP of the embedded IP payload. 452 9. Token validation 454 When the NAT64 server component receives a packet with an unknown 455 combination of token, NAT64 IPv4 address and port number, the server 456 MUST validate it according to the following algorithm which requires 457 no per-NAT64 state until validation succeeds. 459 Compute a Message Authentication Code calculated over token, client 460 IPv4 address, and client port. The server may rotate the MAC key 30 461 seconds after it was last used to send a validation packet. If the 462 control channel packet contains an IPv4 packet and the MAC is found 463 inside of that IPv4 packet the client is authenticated and the IPv4 464 address, port number, and token are stored by the server. Then 465 proceed with processing the packet as an authenticated packet. 467 Apply attenuation which is recommended to be implemented as follows: 468 At server start time initialize a counter of packets to process to as 469 two. On recepit of a packet if the counter is zero silently drop the 470 packet and set the counter to 1 or 2 with a 50% probability each. 471 Otherwise decrease the counter and continue processing. The server 472 MAY use a per NAT64 counter if it has previously communicated with 473 that NAT64 but the token is unknown. 475 Generate an IPv4 validation packet to the NAT64 which will not match 476 any connection tracking entry. That packet MUST include a Message 477 Authentication Code calculated by server over token, client IPv4 478 address, and client port. The server may rotate the MAC key 30 479 seconds after it was last used to send a validation packet. 481 The IPv4 validation packet MAY be formatted as a UDP packet from the 482 NAT64 handoff server port (TBD) to UDP port 9 (discard) formatted as 483 a control channel message containing remote IPv6 address 484 authenticator and a no-next-header IPv6 packet using the previously 485 computed MAC as IPv6 payload. 487 The NAT64 must treat this as a packet not matching a known connection 488 tracking entry and encapsulate the entire packet in a UDP packet sent 489 back to the server. If the NAT64 implements attenuation against 490 reflection attacks it must parse the received packet as a control 491 channel packet and look for a valid token or remote IPv6 address 492 authenticator, if either of those is found it must not drop the 493 packet. 495 10. Server operation 497 When the the server receives a packet with a valid token it is 498 handled according to this section. 500 When the server receives an IPv6 packet over the control connection 501 it must look for a matching connection tracking entry and if none 502 exists it must create one. When using the public IPv4 address of the 503 NAT64 for the connection entry it must use a port number in the range 504 1024-65535 avoiding the following port numbers: 506 3544 508 NAT64 handoff server port (TBD) 510 The source port of the current control channel packet. 512 The server must then either: 514 Translate the packet to IPv4 and deliver it directly 516 Translate the packet to IPv4 and return it to the NAT64 518 Return the connection tracking entry and IPv6 packet to the NAT64 520 When the server receives an IPv4 packet over the control connection 521 it must look for a matching connection tracking entry. If no 522 matching connection tracking entry is found the server should return 523 the packet to the NAT64 if it is a TCP or UDP packet and otherwise 524 construct an appropriate ICMP error message which it can either 525 deliver directly or send back over the control connection to the 526 NAT64. 528 If a match is found the server must then either: 530 Translate the packet to IPv6 and deliver it directly 532 Translate the packet to IPv6 and return it to the NAT64 534 Return the connection tracking entry and IPv4 packet to the NAT64 536 11. Server side NAT 538 When the server creates new connection tracking entries it can choose 539 between using the public IPv4 address of the NAT64 or an address from 540 the ranges specified in [RFC1918] or [RFC6598]. 542 A minimal server side implementation will always use the public IPv4 543 address of the NAT64 and never perform NAT itself. This will be 544 limited to TCP and UDP support and will cost an extra roundtrip each 545 time the NAT64 cache needs to be populated. It will be subject to 546 the limitations in choice of port number for connection tracking 547 entries outlined in this protocol. But it still allows a larger 548 number of connections than relying entirely on the NAT64 as it won't 549 be competing against servers on other IPv4 addresses for the same 550 pool of port numbers. 552 Using a local IP range on the server side has several advantages. 553 But it requires server side NAT which also requires the server to run 554 with the additional privileges needed to create a virtual network 555 interface for this purpose. 557 Advantages of server side NAT is that there is access to more IPv4 558 addresses thus a larger pool of available ports. And it is not 559 subject to the requirements that the same port number be used for 560 mappings towards all TCP and UDP ports server side. It also allows 561 translation of all protocols needed by the server, not just TCP and 562 UDP. It also completely avoids the use of cache entries on the NAT64 563 and the roundtrips needed to populate the cache. 565 A mixed mode operation is also possible where the public IPv4 address 566 of the NAT64 is used even with protocols not supported by the NAT64 567 and connections absent from the NAT64 cache. In this mode the NAT64 568 will tunnel IPv6 packets to the server. The server performs NAT and 569 can either deliver the IPv4 packets directly or tunnel them back to 570 the NAT64. 572 IPv4 packets from the server are sent to the NAT64 which tunnels them 573 to the server for translation. Once packets have been translated to 574 IPv6 the server can either deliver them directly or tunnel them back 575 to the NAT64. 577 The extra roundtrip due to all the IPv4 packets needing to go from 578 server to NAT64 and back to the server makes this mode less 579 desirable. The extra roundtrip can be avoided at the cost of very 580 complicated routing rules on the server. Whether to use this 581 operation mode is choice made server side and the complexity of 582 supporting it lies server side. The NAT64 is required to support 583 this operation mode in case any server it communicates with makes use 584 of it. The NAT64 side just needs to support the tunneling required 585 for this. 587 12. Security Considerations 589 This protocol addresses one security concern around NAT64 by making 590 it harder for attacks to go through a NAT64 as a way to hide their IP 591 address. Other security considerations regarding NAT64 still apply. 593 The control channel introudced by this document operates over UDP and 594 as such it needs to protect against reflection attacks. Control 595 channel packets received by the NAT64 all contain either a token or a 596 remote IPv6 address authenticator which can validate their 597 authenticity and spoofed packets can be silently dropped. Control 598 channel packets received by the server are required to be attenuated 599 before processing if they do not contain a known valid token. If 600 attenuation is implemented using the algorithm suggested by this 601 document the attenuation factor will be 60%. That means if packets 602 with spoofed source IP are sent to the server component only 40% of 603 them will generate a response. 605 The tokens and remote IPv6 address authenticators specified in this 606 document not only serves as protection against reflections but also 607 protect against: 609 Connection cache poisoning 611 Using control channel for injecting spoofed packets 613 IPv4 hosts using the NAT64 to send traffic to IPv6 hosts which did 614 not themselves initiate communication through the NAT64. 616 Application layer security mechanisms such as those implemented by 617 SSH and TLS will work the same with and without NAT64 handoff. 619 13. IANA Considerations 621 One UDP port number for the NAT64 handoff server component needs to 622 be allocated by IANA. 624 Service Name: NAT64 handoff 625 Transport Protocol(s): UDP 626 Description: NAT64 handoff 627 Reference: This document. 628 Port Number: TBD -- To be assigned by IANA. 630 14. Normative References 632 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 633 RFC 792, DOI 10.17487/RFC0792, September 1981, 634 . 636 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 637 and E. Lear, "Address Allocation for Private Internets", 638 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 639 . 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 647 NAT64: Network Address and Protocol Translation from IPv6 648 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 649 April 2011, . 651 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 652 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 653 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 654 2012, . 656 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 657 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 658 May 2017, . 660 Author's Address 662 Kasper Dupont 663 Ellemosevaenget 31 664 Tranbjerg J. 8310 665 Denmark 667 Email: kasperd@ntstm.30.mar.2019.kasperd.dk