Hi Lee, First of all, Thanks for your detailed review.
> 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. Thanks for your review, we can replace "did not" to be "have not". > The time to migrate has not passed: they simply have not done it yet. Maybe > they never will, but we don’t know. We can measure this from the start of asking for migration which is since IPv6 was developed, it wasn't expected that it will take this long time and there was plenty of IPv4 address space remaining. > 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. I think Google measures it by counting the number of hosts accessing Google not by each enterprise where everyone enterprise is counted by +1. > I thought you threatened us with legal action if we ever mentioned it again? It wasn't a threat, it was just protection for the legal rights. > 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). You mean that "Data" should be a header not a trailer, the format on the ID shows "Data" as a segment and part of the IP packet header which is the source and destination addresses. > How does the IPv10 sending host know the ASN and MAC of the IPv4 destination > host? By adding the ASN to the ARP Reply for IPv4 and the RA for IPv6, where every host will store the ASN besides the router advertised information. > isn’t there a privacy concern with using the MAC address? This can be used for security concerns meaning "Host Identification", and the MAC address information sent in the L3 is not routable, just to identify the host. > 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. The IPv10 host with IPv6 address will communicate directly to the DNS from the configured information, I don't understand why bootstrap problem, the communication will be accomplished directly IPv6 --> IPv4 then IPv4 --> IPv6. > 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? The IPv10 deployment will not change the existing configuration, IPv10 is not an IP address structure, it will only allow both IP versions to be encapsulated in the same header. > Same question as in 3.1 about the packet format, and how an IPv4 host uses an > IPv6 name server. The IPv4 host will communicate directly to the DNS configured IP address (it can be IPv4 or IPv6), then the DNS will resolve that name to a host A record or host AAAA record and send the IP address of the destination host which can be an IPv4 or IPv6 host. > 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. This just to mean that all possible communication can be accomplished. > IPv6 has a 20% head start over IPv10. IPv10 isn’t useful until it’s 100% deployed. How will it ever catch up? Correct, if all hosts will be IPv6, IPv10 will disappear automatically, but if only one host with an IPv4 address will still use all 99% of the Internet. After all these concerns, I would like to thank you again for adding your name again to the I-D :-) Best Regards, Khaled Omar -----Original Message----- From: Lee Howard [mailto:[email protected]] Sent: Friday, September 1, 2017 10:54 PM To: Khaled Omar; int-area Subject: Re: [Int-area] IPv10. 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
