Re: Making Use of 240/4 NetBlock Re: 202203161019.AYC
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@isc.org> To: "Abraham Y. Chen" <aychen@avinta.com> Cc: Tom Beecher <beecher@beecher.cc>, "Chen, Abraham Y." <AYChen@alum.mit.edu>, NANOG <nanog@nanog.org> Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC Message-ID: <DB491106-7130-41B0-8EFA-3C4461E4D06F@isc.org> Content-Type: text/plain; charset=utf-8
On 16 Mar 2022, at 07:27, Abraham Y. Chen<aychen@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@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) 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@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)
------------------------------
NANOG Digest, Vol 170, Issue 18
Message: 42 Date: Wed, 16 Mar 2022 13:04:01 +1100 From: Mark Andrews <marka@isc.org> <marka@isc.org> To: "Abraham Y. Chen" <aychen@avinta.com> <aychen@avinta.com> Cc: Tom Beecher <beecher@beecher.cc> <beecher@beecher.cc>, "Chen, Abraham Y." <AYChen@alum.mit.edu> <AYChen@alum.mit.edu>, NANOG <nanog@nanog.org> <nanog@nanog.org> Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC Message-ID: <DB491106-7130-41B0-8EFA-3C4461E4D06F@isc.org> <DB491106-7130-41B0-8EFA-3C4461E4D06F@isc.org> Content-Type: text/plain; charset=utf-8
On 16 Mar 2022, at 07:27, Abraham Y. Chen <aychen@avinta.com> <aychen@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@avinta.com> <aychen@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
<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> <#m_-153197745305042637_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
participants (2)
-
Abraham Y. Chen -
Tom Beecher