Sure thing, Khaled Omar
-----Original Message----- From: Lee Howard [mailto:[email protected]] Sent: Saturday, September 2, 2017 3:38 AM To: Khaled Omar Cc: int-area Subject: Re: [Int-area] IPv10. On 9/1/17, 6:04 PM, "Khaled Omar" <[email protected]> wrote: > > >After all these concerns, I would like to thank you again for adding >your name again to the I-D :-) Leaving aside all other concerns, I have not added my name to the draft. Please do not try again to list me as a co-author. Lee > >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&; >tim >e >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
