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 240.0.0.0/8 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 240.0.0.0/8 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 240.0.0.1/8 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 240.0.0.2/8 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= 240.0.0.1 outer dest=240.0.0.2. The
>> router that serves the shaft at level 1 attracts 240.0.0.0/8
>> 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 240.0.0.2/32 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.
https://www.avast.com/antivirus
-------------- 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