From: Int-area <[email protected]> on behalf of Khaled Omar <[email protected]> Date: Friday, September 1, 2017 at 3:16 PM To: int-area <[email protected]> Subject: [Int-area] IPv10.
>Hi Everyone, > >We still can continue the discussion of the IPv10 I-D, I’m asking all of >you if interested to take it easy to start that discussion to participate >through the Internet Area WG or somewhere else (Private or whatever). > > > I thought you threatened us with legal action if we ever mentioned it again? I’m going to respond respectfully and seriously. > > >Below you can find a link to the IPv10 I-D. > >https://datatracker.ietf.org/doc/draft-omar-ipv10/ > > > Detailed review below. > > >Statistics still shows slow speed of IPv6 adoption and the IPv6 only >hosts are having a limited access to the internet resources. > The draft says 15% adoption as of April 2017, but the same resource (Google) now shows over 20% adoption, four months later. If you use a logistic adoption curve, most Internet connections will be over IPv6 in less than two years: https://www.vyncke.org/ipv6status/project.php?metric=p&timeforward=365&time backward=365&country=ww Other notes on the draft: In several places you say “did not,” where I think “have not” is more appropriate. For instance, “most enterprises did not do this migration” should be “most enterprises have not done this migration.” The time to migrate has not passed: they simply have not done it yet. Maybe they never will, but we don’t know. I recommend changing the list under"The recent solutions for IPv4 and IPv6 coexistence are:” Native dual stack (IPv4 and IPv6) Dual-stack Lite NAT64 464xlat MAP (other technologies also exist, like lw6over4; they may have more specific use cases) “Dual stack” not “Dual stacks.” There are two kinds of tunneling techniques: IPv4 over IPv6 (DS-Lite, 4rd, MAP) and IPv6 over IPv4 (6rd, NAT-PMT). NAT-PT was deprecated (except under managed circumstances) by RFC4966 "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status" Section 3 isn’t “Advantages,” it’s the protocol description. Move the “advantages” discussion to the end, if you keep it at all. Section 3.1 In the packet header, you show “Data” prior to the addresses. Is it a packet footer? I don’t understand the format. I referred to Section 4, where it looks like a more conventional packet header, but comparing the two it still looks like data precedes source address (at least in Section 3). The documentation prefixes are 2001:db8:: (rfc3849) and 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 (rfc5737). How does the IPv10 sending host know the ASN and MAC of the IPv4 destination host? Given the concerns expressed in rfc4941 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6” isn’t there a privacy concern with using the MAC address? What benefit is there in using ASN and MAC? Why not just pad with zeroes? You have the host configuration include an IPv4 address for the DNS Address. How will an IPv6-only how use an IPv4 DNS server? If your answer is “IPv10” then I think there’s a bootstrap problem of how to reach the server so you can get information needed to reach the server. Section 3.2 This example is even clearer. In the example, the network is dual stack all the way to the default gateway. If it were dual-stack that far, why not dual-stack the host? Using NAT44, or any of the myriad transition protocols available. In fact, that’s the current dual-stack scenario (native IPv6 plus NAT44), and one which you point out is untenable as we run out of IPv4 addresses to assign to networks. A residential ISP can’t dual-stack a customer’s CPE when they’re out of IPv4 addresses, so how can IPv10 work? Further, if the network is dual-stack, why not enable dual-stack on the host, using existing protocols? Why develop a new one, and require the host to implement all of IPv4, IPv6, and IPv10, and then disable either IPv4 or IPv6? Same question as in 3.1 about the packet format, and how an IPv4 host uses an IPv6 name server. I understand how a host might be able to insert its MAC address into a 128 bit source address, but how does it know its ASN? What does it do if it’s behind NAT44, as is almost universally the case? The routers would have to be updated to recognize the IPv10 address and translate just the IPv4 address bits, right? Firewalls would have to be updated to recognize the IPv10 address format. In the example, it’s confusing to have the packet going from right to left. You’ve changed the order of the header fields, but not the bits in the fields. Section 3.3 Without seeing full header information, I can’t tell how this is different than native IPv6. Section 3.4 In addition to the questions from Section 3.2, I’m confused about why you need IPv10 in this case, when you have two hosts that speak IPv4 and all networks in between speak IPv4. The “Important Notes” should be its own section. As you point out, I cannot understand why this would be faster to deploy than IPv6 when: "IPv4 and IPv6 routing must be enabled on all routers” and "All Internet connected hosts must be IPv10 hosts” IPv6 has a 20% head start over IPv10. IPv10 isn’t useful until it’s 100% deployed. How will it ever catch up? I think you’ve said in the past that IPv10 only requires software updates, but if a header has to be parsed to decide whether to forward over IPv4 or IPv6 (but it can’t use IPv4 because it’s not IPv4, so you have a whole new forwarding plane to develop) it needs to be done at hardware speeds. Punting to the route engine at Internet scale means dropping packets. Section 4 This should come before Section 3, IMHO. Are the Traffic Class, Flow Label, and Next Header field values identical to IPv6 fields? In summary: This might be possible, with enough work, but I can’t see how it will overtake the momentum of IPv6 deployment and existing transition mechanisms. Here’s a possible timeline, being very generous to IPv10: IPv6 IPv10 2018 50% of US WG discussion 2019 50% of world IETF nearing consensus (into 2020) 2021 75% of world first vendor code ships 2026 99% of world Old hardware that couldn’t support new code is cycling out You can prove me wrong: 1. Write an implementation. Show how an IPv4+IPv10 host can communicate with an IPv6+IPv10 host over a dual-stack (or triple-stack) network. If the router implementation is an open-source router, that’s fine at this stage. 2. Have someone else write an implementation that interoperates with yours. That will demonstrate that the document is detailed enough and clear enough. 3. Do some performance testing. Show that it is easier to update to IPv10 than to dual-stack (including IPv6+transition), and that there is no performance penalty for doing so. 4. Convince a router vendor to implement in test code, and run load testing, to demonstrate that it works at Internet scale. If you can get through Step 3, you may be able to get to Step 4, and if you can do Step 4 you have a good shot at convincing other vendors to implement. If you can get through at least Step 3, you’ll be in good shape in looking for IETF consensus, because you’ll have running code. While I am skeptical of this specific proposal, I wish you luck and hope you will engage with other work in the IETF. Lee _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
