V6 still not supported R: 202203232156.AYC

Abraham Y. Chen aychen at avinta.com
Sat Mar 26 01:50:50 UTC 2022

********** Resend to go through NANOG ***********

On 2022-03-23 23:11, Abraham Y. Chen wrote:
> Dear Pascal:
> 1)    "   Did you propose this work at a WG in Vienna this week?  
> ":    No, but I was invited to be a coauthor of a HuaWei study 
> comparing addressing schemes that was presented there. See material 
> attached.
> 2)    " I coined the term elevator shaft for the description 
> below....  , but the lawyer language is hard to parse for the rest of 
> us so I paraphrased and exemplified. ... ":    Well, the lawyer got 
> paid for his legalese. But, I doubt the essence of your patent. (See 
> more thoughts below.)
> 3)    ".. And I just picked as an example ...    ":    
> This is not the way to link up with another Intellectual Property 
> work. You need to present your implementation, before paraphrasing to 
> others. Otherwise, it is more than misleading.
> 4)    " Now that you’re aware of the possible prior art ...   ":    
> Not too fast! As I stated, neither myself nor the patent examiner of 
> my case found your work. And, I characterize your claim as "more a 
> general /*concept*/*//*than practice." So, if the examiner did pick up 
> your patent, he probably decided to disregard it. What you need to 
> understand is that the basic criterion for granting a patent is:
>     "The */first/* party who has the */original idea/* that has been 
> reduced to */practice/**//*for teaching the general public."
>     I do not believe that yours could pass such a simple test, not to 
> mention that the proposed header changes were so extensive compared to 
> EzIP's simple no-change approach (using  only the old-fashioned RFC791).
>     Note: There was a historical issue about what qualified an 
> Internet related work for a patent (at least in US) around the turn of 
> this century. The most famous one was the "one-click purchase" scheme 
> by Amazon. Yours appear to be close to the other end of the extreme, 
> because fourteen years later (the patent life of seventeen years is 
> almost over) you are still paraphrasing, without a working model to 
> show. I do not want to burden colleagues on this List with the 
> details. If you want, I can give you a run-down offline.
> 5)    " I guess we need to continue that discussion on an IETF ML 
> rather than here,   ": Let me know where you feel is more appropriate, 
> after you have reviewed the above.
> Regards,
> Abe (2022-03-23 23:10 EDT)
> On 2022-03-23 12:47, Pascal Thubert (pthubert) wrote:
>> Dear Abe:
>> Neat 😊 Did you propose this work at a WG in Vienna this week?
>> Just a few points:
>> * I coined the term elevator shaft for the description below. I just 
>> thought that it may help visualize this story; figuring the Internet 
>> as a 2-D flat in a building, and the special prefix bring a 3^rd 
>> dimension to interconnect levels as an elevator shaft does in the 
>> building. The 20 year old IPR did not use that term or that example, 
>> it was more generic than that, but the lawyer language is hard to 
>> parse for the rest of us so I paraphrased and exemplified.
>> * And I just picked as an example to show that you can 
>> easily build 1000000 parallel Internets because it was discussed in 
>> another thread that would provide a lot less value off it, which may 
>> hint that the way we use that prefix should be thought carefully.
>> * Now that you’re aware of the possible prior art, I believe you are 
>> required by law to notify the USPTO so they determine what to do with 
>> the reference. Sorry for the hassle.
>> * I guess we need to continue that discussion on an IETF ML rather 
>> than here, unless people in the list ask for more. I’ll read with 
>> interest the details of your proposal.
>> The bottom line for NANOG is that the dev guys are willing to help, 
>> whether by evolving IPv6 or proposing IPv4 ideas like the ones below. 
>> But we need push / support from your side to pass the PM bar.
>> Keep safe;
>> Pascal
>> *From:* Abraham Y. Chen <aychen at avinta.com>
>> *Sent:* mercredi 23 mars 2022 16:59
>> *To:* Pascal Thubert (pthubert) <pthubert at cisco.com>
>> *Cc:* Michael Thomas <mike at mtcc.com>; nanog at nanog.org
>> *Subject:* Re: V6 still not supported Re: 202203231017.AYC
>> Dear Pascal:
>> 0)    So glad to see your recount of the history and the analysis!
>> 1)    We have recently formulated a proposal called EzIP (Phonetic 
>> for Easy IPv4) that is very much along the line of what you just 
>> described below, but with a few twists. I browsed through US patent 
>> 7,356,031, but failed to spot the key word "240. It appears to me 
>> that it was more a general concept than practice. Did you submit a 
>> draft on your work to IETF? Perhaps due to these, our (including 
>> patent examiner's) prior art search never came across your work. 
>> Although, your patent was granted in the same year as the Normative 
>> Reference [2] of our IETF draft. Please have a quick read of the 
>> below whitepaper. It provides you an overview of EzIP as well as 
>> references to US Pat. No.11,159,425, the current IETFdraft and a 
>> feasibility demonstration setup.
>> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>> 2)    Here is a few quick comparisons between our two teams' work and 
>> the outline of EzIP benefits:
>>     A.    Your "Realm" is very much equivalent to our RAN (Regional 
>> Area Network). However, instead of utilizing 240.0.0/8, we propose to 
>> use the full 240/4 each to maximize its effectiveness. Each RAN can 
>> serve up to 39M population as large as Tokyo Metro, even before 
>> utilizing the three private netblocks.
>>     B.    Your "Elevator Shaft" making use of part of the 240/4 pool 
>> is equivalent to our single IPv4 public address to tether a RAN from 
>> the Internet core. Ours is a "micro" building block approach that 
>> provides more flexibility. For example, up to 75% of the smaller 
>> countries around the world need only one IPv4 each to achieve the 
>> "Elevator Shaft" configuration.
>>     C.    Your "Inter-Realm Router" is simply the current Internet 
>> core routers in the EzIP scheme.
>>     D.   Instead of proposing any modification to the IP packet 
>> header, EzIP can deploy within the capability of the RFC791. That is, 
>> when inter-RAN traffic is needed, the Option Word mechanism is 
>> activated to carry the 240/4 addresses within the RAN, leaving the 
>> basic source and destination address fields to carry the public IPv4 
>> addresses of the RANs at either end.
>>     E.    EzIP implementation is very straightforward. We have 
>> identified at least one case that only requires "*/disabling/* the 
>> program code that has been */disabling/* the use of the 240/4 
>> netblock". With your software expertise, you likely know other 
>> configurations.
>>     F.    EzIP essentially proposes to expand the address pool 
>> currently used by CG-NAT without any hardware change. In addition, 
>> the simplification in administrating the 240/4 addresses 
>> deterministically can mitigate the root cause to the cyber 
>> insecurity, thus reducing the OpEx.
>>     G.    Treating 240/4 as the fourth netblock in RFC1918 allows the 
>> RAN to operate pretty much independent of the Internet core. On the 
>> other hand, being rejected by current routers enables RANs to be 
>> deployed worldwide by themselves without interference in either 
>> direction. This forms an */overlay /*network providing Internet-like 
>> services while having individualized flexibility per RAN.
>>     H.    As more and more RANs are deployed, there will be 
>> increasing number of IPv4 public addresses becoming "spares". Each 
>> can support one RAN to serve other purposes, such as true test beds 
>> for experimenting new protocols.
>>     I.    There probably are a few more parallelisms that we can 
>> identify, as we discuss more.
>> I look forward to your thoughts and critiques.
>> Regards,
>> Abe (2022-03-23 11:59 EDT)
>> On 2022-03-23 05:01, Pascal Thubert (pthubert) via NANOG wrote:
>>     I see the same thing from the other side, being a S/W developer
>>     for switching and routing boxes since the early 90's. The PM
>>     barrier is a high wall indeed. And yet some techs succeed to pass
>>     it. What I'm arguing is that we can pass that wall if we work
>>     together with the same objective.
>>     I've been monitoring this list for a while, very insightful, very
>>     happy with what I learn in the process. But here I feel compelled
>>     to react. I read that IPv6 did not succeed in 25 years. But
>>     unless I miss something, complaining did not succeed either, did it?
>>     My frustration is that indeed (as a dev guy) we have been trying
>>     hard to serve users our best. We proposed a number of things in
>>     the IPv4 evolution direction that I see being asked on this list.
>>     For larger IPv4 space and smooth migration, I'm personally fond
>>     of the IP-in-IP variation that filed in 20+ years ago as US
>>     patent 7,356,031. Basically we reserve a /8, say, since it is so
>>     popular at this time, 240.0.0./8, and make it the "elevator
>>     shaft" between IPv4 realms. Say the current IPv4 Internet is
>>     realm 1, that Internet would have IP address in the
>>     shaft, and would continue operating as is, without a change in
>>     hosts and routers for traffic staying inside the current
>>     Internet. Now say China builds realm 2; that Internet would have
>>     IP address in the shaft. A host in the Internet that
>>     wants to talk to a host in China would require an update to parse
>>     new DNS double-A (realm, address) records to encapsulate the
>>     packet IP-in-IP, outer src= outer dest= The
>>     router that serves the shaft at level 1 attracts
>>     within realm 1 and routes up the elevator for more specific
>>     (host) routes within that prefix. The router that serves the
>>     shaft at level 2 attracts inside the shaft; upon the
>>     said packet it would swap the inner and outer destination and the
>>     packet would reach the Chinese address with classical routing
>>     within realm 2. Routers serving the shaft need an update, but
>>     then, only those do. Obviously the host in China can only reply
>>     if its stack is updated to understand the format. But all the
>>     other hosts and routers in China can be classical IPv4 as we know
>>     them long as their traffic stays in China. To migrate to IPv6
>>     what you can do is map the elevator shaft prefix in, say, 400::/3
>>     (sadly cannot use F00/3 that would map 240 neatly but is already
>>     assigned). The current internet would own 400:1::/32, China would
>>     own 400:2::/32, etc... You encode the double-A of the host in the
>>     prefix, reserve a well known suffix for IPv4 mapped double-A, and
>>     you have an IPv6 address that can be mapped both ways
>>     statelessly. When migrating to v6, each IPv4 node that owns a
>>     public IPv4 address in one realm gets a full IPv6 /64 for free.
>>     This kind of ideas have existed for long but apparently did not
>>     meet their public.
>>     So we tried evolving IPv6 instead. And we did. I've witnessed
>>     deep evolution in networking technology with, e.g., IoT and SRv6.
>>     I've seen both being despised on this list and I'm not asking for
>>     more fuel on that fire. I just want to use these techs as a proof
>>     that evolution is indeed possible, that it happens in the context
>>     of IPv6, and that done in your direction it could make some folks
>>     happier than the current state of affairs. On the side, since I
>>     see the name, please consider that Cisco ships both techs above,
>>     so it is indeed capable of risk taking, the PM wall can indeed be
>>     passed, as long as there's enough pressure from both side.
>>     For those interested, I'd be happy to chat on how IPv6 ND has
>>     evolved (on paper) but is stuck behind the PM wall as well.
>>     Keep safe;
>>     Pascal
>>     Message-----
>>         From: NANOG <nanog-bounces+pthubert=cisco.com at nanog.org>
>>         <mailto:nanog-bounces+pthubert=cisco.com at nanog.org> On Behalf Of
>>         Michael Thomas
>>         Sent: mardi 22 mars 2022 22:37
>>         To: nanog at nanog.org
>>         Subject: Re: V6 still not supported
>>         On 3/22/22 5:45 AM, Randy Bush wrote:
>>             john,
>>             fwiw your story matches what is left of my memory.  one
>>             nuance
>>                 That’s not to say that there wasn’t "IETF politics”
>>                 involved, but
>>                 rather that such politics were expressed as enormous
>>                 pressure to
>>                 “make a decision”
>>             my take was that cidr had done a lot to relieve the immediate
>>             technical pressure for the short term; but there was a
>>             deep fear that
>>             the industry press was stirring a major poolpah about the
>>             end of the
>>             internet due to
>>             ipv4 exhaustion.  i.e. a seriously flawed technical
>>             compromise was
>>             pushed on us in reaction to a perception of bad press.
>>             i have learned that, when i am under great pressure to DO
>>             SOMETHING,
>>             it's time to step back, go make a cup of tea, and think. 
>>             the ietf did
>>             not.  and here we are, a quarter of a century later,
>>             still trying to
>>             clean up the mess.
>>         So are you saying that an ipng that came out in, say, 2000
>>         which was
>>         according to you was vastly superior having taken the time to
>>         get it
>>         right would have had any better chance of being adopted? My
>>         experience
>>         with Cisco product managers at the time is that they couldn't
>>         give a
>>         shit about the technical aspects of an ipng. If their silicon
>>         forwarding
>>         couldn't handle it, they weren't interested unless customers were
>>         clamoring for it. I can't see how that negative feedback loop
>>         could have
>>         ever been prevented other than other ipng being done in, oh
>>         say, 1993
>>         when it was all still software forwarding.
>>         Mike
>> Image removed by sender. 
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
>> Virus-free. www.avast.com 
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> 

This email has been checked for viruses by Avast antivirus software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220325/df1f68fa/attachment.html>

More information about the NANOG mailing list