idnits 2.17.1 draft-eromenko-ipff-babysitter-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 370 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 93: '... private, and MUST work even beind C...' RFC 2119 keyword, line 128: '...vely, Babysitter MAY implement a full ...' RFC 2119 keyword, line 288: '...itter exists, it SHOULD answer all DAD...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2017-03-29) is 2582 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) -- Missing reference section? 'IPFF-DHCP' on line 284 looks like a reference -- Missing reference section? 'IPFF-LARA' on line 303 looks like a reference -- Missing reference section? 'RFC-6146' on line 318 looks like a reference -- Missing reference section? 'RFC-2766' on line 322 looks like a reference -- Missing reference section? 'RFC-4966' on line 322 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 "Internet Protocol Five Fields: Babysitter", 3 Alexey Eromenko, 2016-09-29, 4 5 expiration date: 2017-03-29 7 Intended status: Standards Track 8 A.Eromenko 9 September 2016 11 IP-FF Babysitter: Stateful Network Address Translation 12 ======================================================== 13 including Port, Protocol and Domain Name Translation 14 for Internet Protocol - Five Fields 15 Specification Draft 17 Abstract 19 Babysitter is a form of an advanced NAT, mostly for desktop clients. 20 It gives mixed IP-FF and IPv4 clients access to IPv4-only Internet. 21 It is somewhat resembling NAT64 + DNS64 combo, and will aid during 22 transition period. 24 Assumption: We work on IPv4-only Internet, but we want to implement 25 both IP-FF and IPv4 hosts inside our organization, so nodes can work 26 between themselves with, and take advantage of, IP-FF, but still 27 able to connect to the Internet. 28 If/when this assumption is invalid, and end-to-end IP-FF becomes 29 commonplace, other forms of connection should be used, 30 and babysitter may be disabled. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents: 64 1. IP-FF Babysitter components 65 2. IP-FF Babysitter requirements 66 3. Address mapping 67 4. DHCP default settings 68 5. DNS ALG translation: conceptual workflow 69 6. NAT table: Logical construction and work flow 70 7. Checksums 71 8. Limitations 72 9. Load-balancing multiple babysitters in parallel, for scalability 73 10. Duplicate Address Detection proxy 75 1. IP-FF Babysitter components 77 Stateful NAT and DHCP (client and server), Stateless DNS ALG and 78 Address mapping. 80 2. IP-FF Babysitter requirements 82 IP-FF babysitter, at a minimum, should support stateful ICMP echo, 83 as well as TCP and UDP protocols and DNS translation 84 by ALG (Application-Level Gateway) 86 Supporting other ICMP commands and transport protocols is a bonus, 87 as are Application-Level Gateways (ALGs) for 88 poorly-behaving protocols. 89 Port redirection is a bonus, too. (so that incoming sessions are made 90 possible on specific ports) 92 IP-FF Babysitter takes only one IPv4 address, either public or 93 private, and MUST work even beind CGN (Carrier-grade NAT), 94 where a private IPv4 address is supplied via DHCP. 96 3. Address mapping 98 Source IP addresses are translated in many-to-one fashion. 99 Destination IP addresses are mapped as a simple one-to-one function. 101 IPv4: a.b.c.d 103 becomes 105 IPFF: 10.a.b.c.d 107 Visually similar ! 109 And if you need private addresses ? 111 10.10.x.x.x/20 - all yours ! 113 When address is mapped, no DAD is performed, since multiple 114 Babysitters can exist on the same network segment. 116 4. DHCP default settings 118 10.10.0.5.999/40 = Default Gateway (babysitter itself) 119 Typically it should give it's DHCPv5 clients the range between 120 10.10.0.5.10-990/40 122 DNS Server's IP may be mapped to whatever DNS address is provided 123 by your Internet Service Provider (ISP). 124 i.e. if your ISP gives you DNS = 82.102.139.10 125 Babysitter maps it as 10.82.102.139.10, and gives it to clients 126 via DHCP reply. 128 Alternatively, Babysitter MAY implement a full DNS proxy with 129 caching. 131 If IPFF-babysitter is a DHCP (v4) client itself, DHCP-FF address 132 leases to clients should be a bit shorter or equal 133 to what this babysitter itself receives. 135 Additionally, to support IPv4 nodes, Babysitter includes a DHCPv4 136 server. 138 10.0.5.254/24 = Default Gateway (babysitter itself) 139 Typically it should give it's DHCPv4 clients the range between 140 10.0.5.10-250/24 142 Any or both of DHCPv4 or DHCPv5 servers can be disabled, 143 or re-configured. 145 5. DNS ALG translation: conceptual workflow 147 This is conceptually similar to DNS64, where Babysitter 148 translates DNS queries on the fly. 149 The NAT itself synthesizing AA records from A records. 151 IPFF-Babysitter DNS, unlike DNS64 or NAT-PT, does not check if 152 companyABC.com supports IPFF "AA" resource record (RR) or not, 153 but looks only for "A" Resource Records. 155 DNS Request: 157 +---------+ +---------------+ +---------------+ 158 |IPFF node|---|IPFF-Babysitter|---|IPv4 DNS Server| 159 +---------+ +---------------+ +---------------+ 160 --> --> 161 "AA" query "A" query 162 companyABC.com companyABC.com 163 (step 1) (step 2) 165 DNS Reply: 167 +---------+ +---------------+ +---------------+ 168 |IPFF node|---|IPFF-Babysitter|---|IPv4 DNS Server| 169 +---------+ +---------------+ +---------------+ 170 <-- <-- 171 "AA" reply "A" reply 172 10.28.211.136.15 28.211.136.15 173 = companyABC.com = companyABC.com 174 (step 4) (step 3) 176 DNS translation should be stateless, but in order to 177 prevent translation of "A" responses, sent from dual-stack or IPv4 178 clients, it should look at the stateful UDP NAT table, and ONLY if 179 the client is IP-FF node (DNS query via IP-FF Transport), then 180 translate DNS responce to "AA" record. 181 If the client is IPv4 node (DNS query via IPv4 Transport), no 182 DNS ALG translation is needed. 184 6. NAT table: Logical construction and work flow 186 Assuming our Babysitter is itself behind IPv4 NAT, and got a private 187 IPv4 address of 10.0.0.4. This will be our translated source IP. 188 And it has an IP-FF client, that got an address 10.10.0.5.10. 190 .10 191 +---------+ 10.0.5.x/24 192 |IPv4 node|----------+ 193 +---------+ | 194 |.254 195 | 196 10.10.0.5.x/40 | 10.0.0.x/24 4.5.6.x/24 197 .10 .999 | .4 .254 .7 .8 198 +---------+ +------+--------+ +--------+ +---------------+ 199 |IPFF node|---|IPFF-Babysitter|---|IPv4 NAT|---|IPv4 Web Server| 200 +---------+ +---------------+ +--------+ +---------------+ 201 traffic to web server traffic to web server 202 from 10.10.0.5.10 from 10.0.0.4 203 to 10.4.5.6.8 to 4.5.6.8 204 --->>> --->>> 205 (step 1) (step 2) 207 For outbound packets, source NAT is always stateful, and port 208 translating. 210 original.src.IP|translated.src.IP|original.src.port|translated.src.port 211 ---------------+-----------------+-----------------+------------------- 212 10.10.0.5.10 | 10.0.0.4 | TCP:1027 | TCP:2031 213 10.0.5.10 | 10.0.0.4 | TCP:1027 | TCP:2032 215 NOTE: "src." = Source 217 Source NAT table must be in mixed IP-FF & IPv4 format, due to the 218 possibility to serve both legacy IPv4 nodes, as well as newer IP-FF 219 nodes. Translated source address is always a single IPv4 address. 220 Since there is only one IPv4 address in the whole IPFF babysitter, 221 so translated source IP can be only it. 223 This single IPv4 address can change if, for example, Babysitter 224 disconnected from 4G/LTE network and went Ethernet or ADSL. 225 IP-FF Babysitter must be able to change it's IPv4 address mapping 226 on the fly. (existing connections may break, but new can be 227 established) 229 Very similar to what NAT devices have now, simplified here. 231 Variety of clients: 233 Assume we have both IPv4 and IP-FF clients. For IPv4 clients, 234 Babysitter acts like a typical NAT (NAPT) does. 235 We must use a single NAT table, to avoid duplicate translated source 236 port. NAT adds IPv4 nodes to it's own NAT table, but keep original 237 source address mixed. 239 7. Checksums 241 Checksums must be recomputed when dealing with address translation, 242 as the IP pseudo-header is always different. 243 Checksums must be computed according to the rules of each Address 244 Family and protocol. 246 8. Limitations 248 Obviously serving content is no joy via a Babysitter. 249 Specific TCP/UDP port forwarding will need to be done manually. 251 "Well-behaved" applications will work great, as they do over 252 standard NAPT. Some may break. 253 But web browsing (HTTP, HTTPS) will work. 255 Standard set of limitations, applied to the NAPT applies to 256 Babysitter also. 258 Babysitter is pretty much incompatible with First Field Overlap 259 (FFlap), as defined in "LARA" spec, since no DAD is performed 260 on mapped addresses. 262 9. Load-balancing multiple babysitters in parallel, for scalability 264 In cases, where one Babysitter can't handle the workload, 265 either due to single IPv4 limitation, or CPU processing 266 limitation, just hard-limit the amount of DHCP addresses leased 267 to something small. Perhaps 30-50 addresses. 269 Add another Babysitter, and because of Duplicate Address Detection, 270 it will find it's own address quickly, and clients will find 271 their own, and if there is a duplicate IP (collision), clients 272 will request the next IP address. 274 Babysitter always gives it's own IP as a default gateway via DHCP. 275 So 2nd babysitter will give itself the next available address in 276 the same subnet, something like : 10.10.0.5.998 277 This allows for per-client load-balancing. 279 DHCP server inside Babysitter should to be smart. That is, it 280 should artificially *delay* giving IP-FF addresses, if CPU usage 281 is high, allowing for another Babysitter to answer DHCP, become 282 a gateway, a NAT and a DNS ALG resolver. 284 For DHCP server throttling, see [IPFF-DHCP], Section 4. 286 10. Duplicate Address Detection proxy 288 When Babysitter exists, it SHOULD answer all DAD requests as 289 a DAD proxy, to (at least inform or ) prevent hosts from taking any 290 possible mapped-IPv4 public address, even if unused. 292 I.e. it should mark all the mapped public IPv4 addresses as "used". 294 For example some node sends a DAD request to check for 10.1.1.1.1, 295 since 1.1.1.1 is a valid public IPv4 address, reserved for mapping, 296 so Babysitter should send a DAD reply indicating this address 297 is used. 299 But if someone sends a DAD request to check for 10.10.0.0.1, 300 which may be a mapped private IPv4 address, Babysitter should not 301 answer (except if used by Babysitter itself). 303 NOTE: DAD is defined in [IPFF-LARA] spec. 305 Acknowledgements: 307 "NAT/SLIRP". This universal NAT component is implemented and deployed 308 across a bunch of Open-Source Software programs, including Qemu/KVM, 309 VirtualBox and Virtual Distributed Ethernet (VDE). 311 It provides source NAT (with PAT), DNS and DHCP services, 312 only lacking the DNS ALG capability and address family translation 313 to become a full-fledged IP-FF babysitter. 314 Conceptually IP-FF babysitter is strongly based on this ideology of 315 integrating NAT+DNS+DHCP services into one. 317 "NAT64" - "Stateful NAT64: Network Address and Protocol Translation 318 from IPv6 Clients to IPv4 Servers."; [RFC-6146] 319 Basically it provides for AFT (Address Family Translation) 320 "DNS64" - "Domain Name System with IPv6-to-v4 translation.";[RFC-6147] 321 "Network Address Translation - Protocol Translation (NAT-PT)", 322 [RFC-2766] and criticism of NAT-PT [RFC-4966]. 324 Authors' Contacts 326 Alexey Eromenko 327 Israel 329 Skype: Fenix_NBK_ 330 EMail: al4321@gmail.com 331 Facebook: https://www.facebook.com/technologov 333 INTERNET-DRAFT 334 Alexey 335 expiration date: 2017-03-29