- Test - lists.nanog.org

Network Policies Towards Software Supply Chain Compromise
by Matt Corallo 17 Mar '22

17 Mar '22

Hi network operators, As RPKI validation continues to become increasingly broadly deployed (yay!), I wanted to highlight and ask what deployment policies are towards dependency validation and pinning of RPKI validation software. For example, routinator's dependency graph is somewhat large, and includes at least one or two single-maintainer projects[1] which could inject arbitrary results into the RPKI-based filters. Certainly routinator is not the only project to fall prey to modern development practices which tend to have an exponentially expanding TCB, which makes it a concern that has landed in the laps of sysadmins instead of developers. I assume the large players are considering these issues and taking them into account when deploying, eg by writing tools to compare the feeds of multiple RPKI validators and rejecting any differences, am I correct in that assumption, and are there any open source projects to do so that smaller operators should be looking at using as well? Matt [1] eg https://github.com/vorner/log-reroute could edit your RPKI feed if, vorner wanted to.

1 0

Re: CC: s to Non List Members (Was Re: Making Use of 240/4 NetBlock) Re: 2022031711315.AYC
by Abraham Y. Chen 17 Mar '22

17 Mar '22

Hi, Tom: 1) " ... it has serious deficiencies. ... ": Could you please be specific? Branding something without qualifying information is unprofessional. Regards, Abe (2022-03-17 13:18) ------------------------------ NANOG Digest, Vol 170, Issue 19 Message: 2 Date: Wed, 16 Mar 2022 08:28:36 -0400 From: Tom Beecher<beecher(a)beecher.cc> To: Greg Skinner<gregskinner0(a)icloud.com> Cc:bzs@theworld.com, "North American Network Operators' Group" <nanog(a)nanog.org> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock) Message-ID: <CAL9Qcx5v4Mko-kAdHpRx4KiRZ8e2ubQ-dV6GHg8djOYqxDUMuQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" No quibble about the discussion happening on a NOG list, not at all. But frankly unless the proposal is even starting to move forward in the IETF process such that a standards change is possible, it's just noise. ( I don't predict that the draft being discussed ever gets that far anyways ; it has serious deficiencies.) On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG<nanog(a)nanog.org> wrote: > I agree. iMO, this 240/4 issue is another one of those tussles in > cyberspace > <https://david.choffnes.com/classes/cs4700fa14/papers/tussle.pdf>. But > I don?t fault IETF people or anyone else who pursues technical solutions to > these types of problems as long as they are open and honest about the > limitations of these solutions. > > Also, IMO, the value of having a discussion about this issue here (and > other NOG forums) is to get the perspective of people who (generally > speaking) deal more immediately with the problems the broader ?online" > population has with IETF-based technology. > > ?gregbo > > On Mar 8, 2022, at 9:25 PM,bzs(a)theworld.com wrote: > > > I'm beginning to wonder if the internet will survive the ipv6 adoption > debates. > > Here's the real problem which you all can promptly ignore: > > The IETF et al are full of bright technical people who can design > protocols, packet formats, etc. > > But many of the major problems facing the internet are not, at their > core, engineering problems. > > They're in the realm of social, legal, marketing, politics, int'l > policy, governance, law enforcement, commerce, economics, sociology, > psychology, etc. which TBH as bright as many of the engineers et al > are these problems are way beyond their ken, occasional polymath > excepted. > > But first you have to admit you have a problem, and limitations. > > Shouting at the rafters about address space depletion etc while waving > RFCs may not quite do it. > > Similar can be said about spam, malware attacks, phishing, etc. > > Yet another cryptographic protocol probably won't save the day but as > the expression goes when all you have is a hammer the whole world > looks like a nail. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility |*oo* > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Re: Making Use of 240/4 NetBlock Re: 202203171153.AYC
by Abraham Y. Chen 17 Mar '22

17 Mar '22

Hi, Tom: 1) " I've read the draft. ... ": Then, you still overlooked the essence of the keyword "overlay": A. The EzIP project started with the goal of getting enough IP addresses for end-to-end communication according to the old fashioned definition in telecommunications, such as PSTN. Upon correlated the three private netblocks to the reusable PBX numbering convention and discovered the availability of the 240/4 netblock, we enlisted the Option Word for carrying such additional information to accomplish this goal. B. Next, we realized that since 240/4 is so big, we can deploy it over a much larger area than a commonly known private premises. The concept of RAN (Regional Area Network) was born. Since the existing Internet routers will drop any 240/4 addressed packets, RANs can deploy on their own, without interference in either direction. With each RAN served from one IPv4 public address, the entire RAN can be viewed as an isolated island or a piece of land floating in the air and tethered to the Internet core via one umbilical cord. C. This configuration frees up the need for updating any current Internet equipment while growing by expanding from one IPv4 address. That is, the RAN deployment can be done via SPRs (Semi-Public Routers) as needed. All of these introductory activities do not need to use the Option Word, at all. This phase of the deployment can use the degenerated EzIP header mentioned in the Draft which is actually the conventional basic IPv4 header (without Option Word). D. Only when direct communication between IoTs residing in separate RANs is desired, IoTs capable of the full EzIP header will be used. (These are not wide spread requirement, but case-by-case for elite users.) Since the number of umbilical cords is finite, interconnecting RANs for this purpose can be achieved by deploying SPRs where is needed. Of course, if existing routers are wiling to support (by "trimming down" the existing code), the deployment will go much faster. But, it is not necessary. 2) The above is why "overlay" network can be used to characterize the EzIP architecture. One interesting online graphics that we recently came across depicts this configuration very nicely (see URL below). One can visualize that each continent, country, and even all the way down a Region or an island is floated above the earth core (the Internet) and tethered to it via an umbilical cord (IPv4 address). With this architecture, everything in the RAN can start fresh, yet supported by the core all the time. The involvement of the latter is optional. This relationship is the same as national versus international telephony networks in the PSTN world. In other words, the current Internet proper will serve just the current type of interconnections among RANs, if no update is made to its routers. https://dotconnectafrica.org/icann-wins-by-technical-knockout-dca-blocked-f… Hope I am not boring you by being too wordy. Regards, Abe (2022-03-17 12:20) ------------------------------ NANOG Digest, Vol 170, Issue 19 Message: 9 Date: Wed, 16 Mar 2022 11:38:51 -0400 From: Tom Beecher <beecher(a)beecher.cc> To: "Abraham Y. Chen" <aychen(a)avinta.com> Cc: Mark Andrews <marka(a)isc.org>, NANOG <nanog(a)nanog.org> Subject: Re: Making Use of 240/4 NetBlock Re: 202203161019.AYC Message-ID: <CAL9Qcx46RzdqYWRQ+Fo_+a8L9Kr=ZQi9J2Ej+FNtzTFs=eSpuA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" > 2) Re: Ur. Pt. 2) " So replace every CPE device, including ... ": > It is evident that you even did not glance at the EzIP Draft Abstract > before commenting, but just relying on your recollection of the past 240/4 > efforts. Please spend a minute or two on reading the EzIP Abstract. In > particular, please look for a keyword "overlay". Hint, this was not our > invention. It was a concise characterization by an authoritative Internet > figure. So, we imported it into our latest IETF draft update. Hopefully, > this keyword will steer your opinion on EzIP. I've read the draft. Your proposal appears to rely on a specific value in the IP option header to create your overlay. While that sounds good on paper, it's operationally been best practice for at least the last decade (maybe longer) to drop any packet with an IP option set that you don't explicitly want because a significant number of routers kick every packet with options to CPU, so any substantive traffic flow with options set could knock devices over. I can't speak to the current state of router processing, but I'd bet dollars to donuts most of those filters are still in place. So, assuming your proposal were to eventually become an adopted standard, before it could reliably work across the general internet : - Any device that still treated 240/4 differently would need to be updated to treat it like anything else. - Any existing filters that dropped packets with*any* IP option set would have to be modified to permit the ones you define for EzIP - At least some router software would have to have IP option handling adjusted in some way. ( At one point in the past, one big router vendor only allowed you to configure an ip-options filter based on the IANA defined values, not others. ) This is a LOT of work and time for an overlay. On Wed, Mar 16, 2022 at 10:51 AM Abraham Y. Chen<aychen(a)avinta.com> wrote: > Hi, Mark: > > 1) Re: Ur. Pt. 1) " ISE != IETF. ... ": On a public forum like > NANOG, it is much more expeditious to provide forward guidance than > reciting past failures, especially those of a third party due to improper > system setup. > > 2) Re: Ur. Pt. 2) " So replace every CPE device, including ... ": > It is evident that you even did not glance at the EzIP Draft Abstract > before commenting, but just relying on your recollection of the past 240/4 > efforts. Please spend a minute or two on reading the EzIP Abstract. In > particular, please look for a keyword "overlay". Hint, this was not our > invention. It was a concise characterization by an authoritative Internet > figure. So, we imported it into our latest IETF draft update. Hopefully, > this keyword will steer your opinion on EzIP. > > Regards, > > > Abe (2022-03-16 10:49) > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Re: CC: s to Non List Members (Re: Making Use of 240/4 NetBlock Re: 202203171135.AYC
by Abraham Y. Chen 17 Mar '22

17 Mar '22

Hi, Greg: 1) " ... The IETF has changed its position on several (IMO) key issues during its existence. ... ": Well said! In fact, I believe (from one of the APNIC blogs recounting the Internet history) that CG-NAT was one of those "bastards" who turned to be accepted as a prince whom everyone is defending him now, without realizing that an enhancement is at the front door steps again. Regards, Abe (2022-03-17 11:50) ------------------------------ NANOG Digest, Vol 170, Issue 19 Message: 34 Date: Wed, 16 Mar 2022 15:32:45 -0700 From: Greg Skinner<gregskinner0(a)icloud.com> To: Tom Beecher<beecher(a)beecher.cc> Cc:bzs@theworld.com, North American Network Operators' Group <nanog(a)nanog.org> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock) Message-ID:<109DB49C-2471-4FE2-AC68-E4EEAFE1C886(a)icloud.com> Content-Type: text/plain; charset="utf-8" I have qualms about these drafts also. However, even if the IETF does not move forward with any of them (not even to adopt them as WG items), that doesn?t mean they never will. Times change. Circumstances change. The IETF has changed its position on several (IMO) key issues during its existence. Perhaps this will be one of those times. Incidentally, if you take a look at this post from Theodore Ts?o<https://mailarchive.ietf.org/arch/msg/ietf/IGKkL8IM1IptV4Q3Z3pko6OC1Xs/> he?s pretty much saying the same thing that Barry Shein said, that the IETF isn?t as good at policy as it is in producing protocol standards. (The thread it?s from started from a response to the publication of RFC2008<https://www.rfc-editor.org/rfc/rfc2008.txt> as a Best Current Practice, in spite of ?vigorous opposition?.) The other thing I wanted to say is for anyone who doesn?t know a lot about the IETF workings, the contributions of some of the authors of the Schoen drafts are recognized and respected in the IETF Transport Area. They?re not new to this stuff. They have ?clue?. They do due diligence. They produce running code, and (IMO) are seeking rough consensus. I believe that in the IETF of, say, a quarter century ago, their drafts would have progressed further through the standards process. For various reasons, today?s IETF is different, but could still change its minds. I believe the authors of the Schoen drafts are capable of drumming up support for their ideas even if they don?t (immediately) become IETF drafts, and that the IETF might change its position on their ideas, as a result of such support. ?gregbo > On Mar 16, 2022, at 5:28 AM, Tom Beecher<beecher(a)beecher.cc> wrote: > > No quibble about the discussion happening on a NOG list, not at all. > > But frankly unless the proposal is even starting to move forward in the IETF process such that a standards change is possible, it's just noise. ( I don't predict that the draft being discussed ever gets that far anyways ; it has serious deficiencies.) > > On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG <nanog(a)nanog.org <mailto:nanog@nanog.org>> wrote: > I agree. iMO, this 240/4 issue is another one of those tussles in cyberspace<https://david.choffnes.com/classes/cs4700fa14/papers/tussle.pdf>. But I don?t fault IETF people or anyone else who pursues technical solutions to these types of problems as long as they are open and honest about the limitations of these solutions. > > Also, IMO, the value of having a discussion about this issue here (and other NOG forums) is to get the perspective of people who (generally speaking) deal more immediately with the problems the broader ?online" population has with IETF-based technology. > > ?gregbo > >> On Mar 8, 2022, at 9:25 PM,bzs(a)theworld.com <mailto:bzs@theworld.com> wrote: >> >> >> I'm beginning to wonder if the internet will survive the ipv6 adoption >> debates. >> >> Here's the real problem which you all can promptly ignore: >> >> The IETF et al are full of bright technical people who can design >> protocols, packet formats, etc. >> >> But many of the major problems facing the internet are not, at their >> core, engineering problems. >> >> They're in the realm of social, legal, marketing, politics, int'l >> policy, governance, law enforcement, commerce, economics, sociology, >> psychology, etc. which TBH as bright as many of the engineers et al >> are these problems are way beyond their ken, occasional polymath >> excepted. >> >> But first you have to admit you have a problem, and limitations. >> >> Shouting at the rafters about address space depletion etc while waving >> RFCs may not quite do it. >> >> Similar can be said about spam, malware attacks, phishing, etc. >> >> Yet another cryptographic protocol probably won't save the day but as >> the expression goes when all you have is a hammer the whole world >> looks like a nail. >> >> -- >> -Barry Shein >> >> Software Tool & Die | bzs at TheWorld.com<http://theworld.com/> |http://www.TheWorld.com <http://www.theworld.com/> >> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD >> The World: Since 1989 | A Public Information Utility |*oo* >>

1 0

Looking for a BGP/Routing/NOC contact at Comcast Business...
by Cruze, Brian A 17 Mar '22

17 Mar '22

...regarding a hijacked network. If someone could contact me off-list, I would appreciate it. I've tried abuse(a)comcast.net and CNOC_CoreNetworkOperations(a)cable.comcast.com with no luck.

1 0

Re: Not Making Use of 240/4 NetBlock Re: 202203171125.AYC
by Abraham Y. Chen 17 Mar '22

17 Mar '22

Hi, Mark: 1) " ... known defective products ... ": Could you please define what do you mean? And, what "products" do you have in mind? Otherwise, this sounds like a scare tactic without a foundation. Regards, Abe (2022-03-17 11:32) ------------------------------ NANOG Digest, Vol 170, Issue 19 Message: 35 Date: Thu, 17 Mar 2022 09:48:04 +1100 From: Mark Andrews<marka(a)isc.org> To: Owen DeLong<owen(a)delong.com> Cc: Sylvain Baya<abscoco(a)gmail.com>,bzs(a)theworld.com, Niels Bakker <niels=nanog(a)bakker.net>,nanog(a)nanog.org Subject: Re: Not Making Use of 240/4 NetBlock Message-ID:<1C6B1AD8-399E-4B3C-B3AD-A5C846F62925(a)isc.org> Content-Type: text/plain; charset=utf-8 It?s a business problem for the RIR?s. Selling / leasing known defective products is against lots of consumer law. -- Mark Andrews > On 17 Mar 2022, at 03:43, Owen DeLong<owen(a)delong.com> wrote: > > ? > >>> On Mar 15, 2022, at 19:23 , Mark Andrews<marka(a)isc.org> wrote: >>> >>> >>> >>>> On 16 Mar 2022, at 02:54, Owen DeLong via NANOG<nanog(a)nanog.org> wrote: >>> Having spent nearly 15 years on the ARIN Advisory Council, I think I?m able >>> to claim some detailed knowledge on the subject. >>> >>> In general, the RIRs themselves maintain neutrality about such things, looking to their >>> respective communities for input on what to do. However, so long as the IETF and >>> has not designated the space Unicast Address Space to be delegated to the >>> RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the RIRs >>> won?t, therefore, delegate it to users. >>> >>> If you really want to see this happen (and I still argue that the amount of effort already wasted >>> discussing this idea vastly exceeds what would be needed towards IPv6 to get beyond >>> caring about it), then the first step must be to convince the IETF to designate the >>> space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the RIRs. >>> >>> Once that happens, the rest of the allocation process is basically automatic. From a policy >>> perspective at the RIR level, it will be no different than say 4/8 or 1/8. >> Actually it would be fundamentally different to 4/8 or 1/8. You are looking at firmware upgrades >> rather than dealing with squatters and out-of-date ACLs both of which are self-inflicted by one >> of the parties. Routers and end devices that don?t know how to hand 240/4 are no self inflicted >> injuries. Issuing 4/8 or 1/8 worked for parties that had been following the rules. With 240/4 >> there where no rules to follow which results in RIR?s leasing known defective addresses. > I was speaking from an RIR allocation perspective, NOT talking about the technological hurdles > to implementation. > > I was specifically responding to someone?s question about how the RIRs would be impacted by > this if it were to come to pass. > > I addressed your concern in the following paragraph as an aside, however. > >>> Now, convincing vendors to update their firmware, software, etc. is another matter >>> and entirely outside of the control of the RIRs. Merchant compliance with IETF standards >>> is generally considered useful, but it is entirely voluntary and even in the best of >>> circumstances doesn?t every happen instantaneously and almost always involves >>> some stumbles along the way. >>> >>> Owen >>> >>> >>>> On Mar 15, 2022, at 02:54 , Sylvain Baya<abscoco(a)gmail.com> wrote: >>>> >>>> Dear NANOG-ers, >>>> Hope this email finds you in good health! >>>> Please see my comments below, inline... >>>> >>>> Le mardi 15 mars 2022,<bzs(a)theworld.com> a ?crit : >>>> >>>> >>>> Hi Barry, >>>> Thanks for your email, brother! >>>> >>>> >>>> But the RIRs are the ones fielding requests for IPv4 space, and have >>>> some notion of how policy implementation might work in practice, so >>>> should have a lot of useful input. >>>> >>>> >>>> ...of course, it appears that RIRs have the opportunity >>>> to add their useful inputs, as Impact Analysis Report >>>> (IAR); during the Policy Development Process (PDP) >>>> initiated by the*appropriate* [1] Internet community. >>>> They explain it themselves here [2]. >>>> __ >>>> [1]:<https://tools.ietf.org/html/rfc7020> >>>> [2]:<https://www.nro.net/accountability/rir-accountability/q-and-a/> >>>> >>>> Shalom, >>>> --sb. >>>> >>>> >>>> On March 14, 2022 at 00:45niels=nanog@bakker.net (Niels Bakker) wrote: >>>>> *bzs(a)theworld.com (bzs(a)theworld.com) [Mon 14 Mar 2022, 00:31 CET]: >>>>>> Personally I'd rather hear from the RIRs regarding the value or not >>>>>> of making more IPv4 space such as 240/4 available. They're on the >>>>>> front lines of this. >>>>> You've got your policy development process diagram upside down. The >>>>> community decides what the RIRs implement. They're not in touch with >>>>> merchant silicon manufacturers. >>>>> >>>>> >>>>> -- Niels. >>>> -- >>>> -Barry Shein >>>> >>>> Software Tool & Die |bzs(a)TheWorld.com |http://www.TheWorld.com >>>> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD >>>> The World: Since 1989 | A Public Information Utility |*oo* >>>> >>>> >>>> -- >>>> Best Regards ! >>>> __ >>>> baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> >>>> Subscribe to Mailing List:<https://lists.cmnog.cm/mailman/listinfo/cmnog/> >>>> __ >>>> #?LASAINTEBIBLE?|#?Romains15?:33?Que LE ?#?DIEU? de ?#?Paix? soit avec vous tous! ?#?Amen?!? >>>> ?#?MaPri?re? est que tu naisses de nouveau. #Chr?tiennement? >>>> ?Comme une biche soupire apr?s des courants d?eau, ainsi mon ?me soupire apr?s TOI, ? DIEU!?(#Psaumes42:2) >>>> >>>> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET:marka@isc.org >> ------------------------------ -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Re: Making Use of 240/4 NetBlock Re: 202203162242.AYC
by Abraham Y. Chen 17 Mar '22

17 Mar '22

Hi, Fred: 1) " ... you will need to replace the existing DNS and DHCP systems... ": I am glad that you have touched the next level of considerations. Operating an RAN with one 240/4 netblock, there will be more than enough IP addresses to assign to all client premises. So, the EzIP deployment will operate with static IP address disciplines, negating the fundamental reasons to have DNS and DHCP. That is, transition to running the electronic equivalent of telephony White and Yellow Pages would be what EzIP deployment should rely upon. 2) " ... hear the relevant organizations saying that it changes their networking model, ... similar to what has happened with the IPv6 deployment. ": Do they recognize that implementing EzIP address plan on CG-NAT changes no network model? So, the perturbation is far less than deploying IPv6. Regards, Abe (2022-03-16 22:59) On 2022-03-16 12:03, Fred Baker wrote: >> On Mar 16, 2022, at 7:50 AM, Abraham Y. Chen<aychen(a)avinta.com> wrote: >> >> 2) Re: Ur. Pt. 2) " So replace every CPE device, including ... ": It is evident that you even did not glance at the EzIP Draft Abstract before commenting, but just relying on your recollection of the past 240/4 efforts. > I did read it. Correct my understanding. > > Your proposal is to replace the IP addressing model and IP (yes, you're using options, but the architecture changed). Do so do, you will need to replace the existing DNS and DHCP systems with a PABX-like model - you need to find a way to let systems address each other. It also replaces firewalls with a model that prevents communication with devices that don't know the PABX port numbers. > > Frankly, I can already hear the relevant organizations saying that it changes their networking model, and it starts a process similar to what has happened with the IPv6 deployment. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Regarding BGP offloading
by Anurag Bhatia 17 Mar '22

17 Mar '22

Hello NANOG! I have seen limited talks about offloading of BGP as a whole into containers/VMs etc. Take e.g this old Google blog post <https://www.blog.google/products/google-cloud/making-google-cloud-faster-mo…> from 2017. Quoting from that: *Second, we separate the logic and control of traffic management from the > confines of individual router “boxes.” Rather than relying on thousands of > individual routers to manage and learn from packet streams, we push the > functionality to a distributed system that extracts the aggregate > information. We leverage our large-scale computing infrastructure and > signals from the application itself to learn how individual flows are > performing, as determined by the end user’s perception of quality.* If I am reading this correctly, it gives an impression of just BGP signalling offload (to VMs/containers...). Is that understanding correct? Speaking from network topology wise anyone here has an idea or could point to a resource on how it is actually achieved? If the frontend device simply starts passing TCP 179 requests to some backend server running say bird, frr etc, how will that information be passed back to the forwarding plane? Are there more public deployments of this sort of setup where BGP as a whole (that is sessions, route calculation, policies, filtering etc) is offloaded to some x86 device in the backend? Or am I just reading it wrong and it's actually smaller VM/containers will full router functionality and BGP alone is not being offloaded? So the logical L3 endpoint here is VMs? What sort of config the device sitting in frontend would have at the interface level to achieve that? Appreciate your responses! Thanks. -- Anurag Bhatia anuragbhatia.com

3 3

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock
by Abraham Y. Chen 16 Mar '22

16 Mar '22

Dear Seth: 1) " ... should be ... ": Instead of "hand wave", this is a diplomatic expression to challenge the software engineers' knowledge of the networking program code for the current case. Ever since we started our study, we were quite puzzled by why the 240/4 netblock was regarded so special? Why no one could tell us what led to its current status, and even after IPv4 was set to transition to IPv6? ... etc. We also could not find anyone who could describe to us how was it being handled in the existing programs. This included those who claimed to be experts in the subject. Perhaps they intentionally tried to hide the detail, or they also did not know? One day, we finally came across a program fragment that could perform the "disabling 240/4 netblock" function. Upon presenting it to an acquaintance knowledgeable of networking programs, he confirmed that it was one concise technique to do the job. That was sufficient for our purpose as system engineers, because we should not overstep our duties by doing software engineer's programing task. That is, as long as we can demonstrate that "there exists" a solution, like proofing a mathematics theorem, we have completed our part of the deal. 2) " ... discussed to death many times over ... ": This was what we were told when we first looked into this subject over half a dozen years ago, and more times along the way. As long as there was an issue not resolved, however, every angle should be continuously explored. In science and engineering, if we stopped studying, because of this kind of viewpoint, we would have missed a lot of inventions and discoveries. So, this particular consideration is not in our books. Regards, Abe (2022-03-10 22:49 EST) ------------------------------ NANOG Digest, Vol 170, Issue 11 Message: 10 Date: Wed, 9 Mar 2022 10:29:22 -0800 From: Seth Mattinen<sethm(a)rollernet.us> To:nanog@nanog.org Subject: Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock Message-ID:<0c6c8b63-6e84-92da-2e28-89b2b5c6d639(a)rollernet.us> Content-Type: text/plain; charset=UTF-8; format=flowed On 3/7/22 2:14 PM, Abraham Y. Chen wrote: > The cost of this software engineering should be minimal. So basically no solution is offered to what is the showstopper for this proposal, only a hand wave that it "should be" easy to fix (but that's everyone else's problem). I mean, I believe this has been discussed to death many times over in the past and yet here we still are. ------------------------------ -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

16 29

Re: Making Use of 240/4 NetBlock Re: 202203161019.AYC
by Abraham Y. Chen 16 Mar '22

16 Mar '22

Hi, Mark: 1) Re: Ur. Pt. 1) " ISE != IETF. ... ": On a public forum like NANOG, it is much more expeditious to provide forward guidance than reciting past failures, especially those of a third party due to improper system setup. 2) Re: Ur. Pt. 2) " So replace every CPE device, including ... ": It is evident that you even did not glance at the EzIP Draft Abstract before commenting, but just relying on your recollection of the past 240/4 efforts. Please spend a minute or two on reading the EzIP Abstract. In particular, please look for a keyword "overlay". Hint, this was not our invention. It was a concise characterization by an authoritative Internet figure. So, we imported it into our latest IETF draft update. Hopefully, this keyword will steer your opinion on EzIP. Regards, Abe (2022-03-16 10:49) ------------------------------ NANOG Digest, Vol 170, Issue 18 Message: 42 Date: Wed, 16 Mar 2022 13:04:01 +1100 From: Mark Andrews <marka(a)isc.org> To: "Abraham Y. Chen" <aychen(a)avinta.com> Cc: Tom Beecher <beecher(a)beecher.cc>, "Chen, Abraham Y." <AYChen(a)alum.mit.edu>, NANOG <nanog(a)nanog.org> Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC Message-ID: <DB491106-7130-41B0-8EFA-3C4461E4D06F(a)isc.org> Content-Type: text/plain; charset=utf-8 > On 16 Mar 2022, at 07:27, Abraham Y. Chen<aychen(a)avinta.com> wrote: > > Hi, Tom: > > 1) " .... better to have that conversation via the appropriate IETF channels. ": Thanks for the recommendation. I would appreciate very much if you could guide us to the specific contact. Before we attempt to do so, however, it would be prudent to report the history of our team's experience: > > A. The first IETF Draft on EzIP Project started from 2016-12 as instructed by the ISE (Independent Submission Editor). Although, at that time Working Group SunSet4 had been in session for awhile. But, we were not aware of, nor being informed about such. ISE != IETF. There is no responsible AD assigned so this is not classed as IETF work. For ISE work to become IETF work you need to convince a AD to sponsor the work. https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ > B. In Summer of 2018, we discovered that SunSet4 had Concluded. We contacted the person in charge of keeping an eye on possible future IPv4 activities, but did not receive any instruction to revise our course. > > C. Recently, we were made aware of the Int-Area activities. Attempts to reach the Group Chairs have not received any responses. > > D. I just received an Int-Area Digest Vol 199, Issue 14 requesting IETF to reactivate the IPv4 support. Firstly nobody uses mailing list digests as references. Secondly anyone can post to the mailing list, you just need to subscribe. If you read the thread you can see there is no interest in this. https://mailarchive.ietf.org/arch/msg/int-area/iZnR1Dkomu4D8AfHTI2xR_npJ8Y/ > Hope you can help us to close the loose ends. > > 2) In the meantime, we realized that the simplest implementation of the EzIP proposal is to replace the 100.64/10 netblock used by CG-NAT with the 240/4 netblock. Next, taking advantage of the much larger address pool to begin practicing static address assignment related disciplines, a "packetized PSTN" is realized. From such a base, the EzIP powered CG-NAT behaving as an overlay network in parallel to the existing Internet for providing the same services, many of the drawbacks in the latter are mitigated! So, we decided to discuss the EzIP proposal directly with the NANOG colleagues, because the EzIP deployment can actually be rather stealthy. So replace every CPE device, including the ones you don?t own, to support 240/4 then later replace every CPE device again or replace every CPE device with one that supports the IPv4aaS you have chosen to use and switch to IPv6-only between the ISP and the CPE and get IPv6 delivered to your customers. Lots of ISP?s have already gone to DS-Lite or 464XLAT, to name two IPv4aaS methods, to provide their clients access to the legacy IPv4 internet over IPv6-only links. Note nothing prevents there being a mixture of dual stack and IPv6-only clients on the same access network hardware. Remember even using these addresses as a replacement for 100.64/10 requires every device behind the CPE to also support 240/4 or any traffic emitted from these addresses is subject to be discarded. > I look forward to your thoughts. > > Regards, > > > Abe (2022-03-15 16:26) > > > > On 2022-03-14 14:48, Tom Beecher wrote: >> If you want to garner discussion or support for your draft RFC, it's probably better to have that conversation via the appropriate IETF channels. >> >> On Mon, Mar 14, 2022 at 2:43 PM Abraham Y. Chen<aychen(a)avinta.com> wrote: >> Hi, Fred: >> >> 0) Thank you for a set of references. >> >> 1) We cited only one IETF Draft (Wilson, et al.) among them, because it was the first and only one that clearly stated its limitation (Section 2. Caveats of Use). More importantly, it was written by three top APNIC officials. Later efforts on this topic have not introduced (based on my reading) any more essence to the topic. >> >> 2) "... I was there for those discussions, and I'm not sure how to put it more simply.... ": With your knowledge of the past, you are uniquely qualified to critique on our work. However, it would be more expedient for everyone, if you could first read through at least the Abstract and the Conclusions of the EzIP IETF Draft, before commenting. This is because EzIP proposal is based on the same general idea as the references you cited, but with a slight extra step that produced a series of surprising results. In particular, we took the "Caveats" above to our hearts before proceeding. So, please put such issues behind you while reviewing our work. Thanks, >> >> Regards, >> >> >> >> Abe (2022-03-14 14:39) >> >> >> >> >> >> ------------------------------ >> NANOG Digest, Vol 170, Issue 15 >> Message: 17 -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1