nanog mailing list archives
Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC
From: "Abraham Y. Chen" <aychen () avinta com>
Date: Sat, 26 Mar 2022 18:16:44 -0400
Hi, Tom & Paul:1) " ... hand waved ... ": Through my line of work, I was trained to behave exactly the opposite. I am surprised at you jumping to the conclusion, even before challenging me about where did I get my viewpoint from. The fact is, it has been clearly documented in our IETF draft for the last couple years (since Rev-06 on 2019 Dec. 1)! For your convenience, please see below a copy of the potential target code fragment and critique. It appears to me that our software member suggested to comment out only one line (1047).
Regards, Abe (2022-03-26 18:16) ****************D.1 <https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space#appendix-D.1>. Candidate Code for Modification
The following short JavaScript function named "ifip" in the TP-Link Archer C20 V4 source code has been shown to selectively reject specific ranges of IP addresses. In particular, Line 1047 uses a "2's Complement" technique to identify the 240/4 netblock as "PRESERVED", thus rejecting it. A quick scan of the firmware code in the router indicates that this function is a popular utility because there are numerous processes calling for it. So, this should be the best candidate to start testing our concept. lib.js:1040:ifip: function(ip, unalert) { lib.js-1041-if ((ip = $.ip2num(ip)) === false) return $.alert(ERR_IP_FORMAT, unalert); lib.js-1042-if (ip == -1) return $.alert(ERR_IP_BROADCAST, unalert); lib.js-1043-var net = ip >> 24; lib.js-1044-if (net == 0) return $.alert(ERR_IP_SUBNETA_NET_0, unalert); lib.js-1045-if (net == 127) return $.alert(ERR_IP_LOOPBACK, unalert); lib.js-1046-if (net >= -32 && net < -16) return $.alert(ERR_IP_MULTICAST, unalert); lib.js-1047-if (net >= -16 && net < 0) return $.alert(ERR_IP_PRESERVED, unalert); lib.js-1048-return 0; lib.js-1049-},D.2 <https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space-10#appendix-D.2>. Proposed Modification
To stop rejecting the 240/4 netblock addressed packets, below is a modification that comments out Line 1047, a modification that has been shown to eliminate javascript pre-validation of 240/4 IP addresses, allowing them to be sent within the router, where a second layer of validation rejects them in a different way. lib.js:1040: ifip: function(ip, unalert) { lib.js-1041- if ((ip = $.ip2num(ip)) === false) return $.alert(ERR_IP_FORMAT, unalert); lib.js-1042- if (ip == -1) return $.alert(ERR_IP_BROADCAST, unalert); lib.js-1043- var net = ip >> 24; lib.js-1044- if (net == 0) return $.alert(ERR_IP_SUBNETA_NET_0, unalert); lib.js-1045- if (net == 127) return $.alert(ERR_IP_LOOPBACK, unalert); lib.js-1046- if (net >= -32 && net < -16) return $.alert(ERR_IP_MULTICAST, unalert); lib.js-1047- //if (net >= -16 && net < 0) return $.alert(ERR_IP_PRESERVED, unalert); lib.js-1048- return 0; lib.js-1049-}, ****************
On 2022-03-26 12:37, Tom Beecher wrote:
Have you ever considered that this may be in fact: */writing/* and */deploying/* the code that will allow the use of 240/4 the way you expectWhile Mr. Chen may have considered that, he has repeatedly hand waved that it's 'not that big a deal.', so I don't think he adequately grasps the scale of that challenge.On Sat, Mar 26, 2022 at 9:53 AM Paul Rolland <rol () witbe net> wrote: Hello, On Sat, 26 Mar 2022 09:35:30 -0400 "Abraham Y. Chen" <aychen () avinta com> wrote: > touching the hardware, by implementing the EzIP technique (*/disabling/* > the program code that has been */disabling/* the use of the 240/4 > netblock), an existing CG-NAT module becomes a RAN! As to universal Have you ever considered that this may be in fact: */writing/* and */deploying/* the code that will allow the use of 240/4 the way you expect Paul
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Current thread:
- Re: V6 still not supported, (continued)
- Re: V6 still not supported James R Cutler (Mar 24)
- Re: V6 still not supported Owen DeLong via NANOG (Mar 25)
- Re: V6 still not supported Joe Maimon (Mar 26)
- Let's Focus on Moving Forward Re: V6 still not supported Abraham Y. Chen (Mar 25)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Christopher Morrow (Mar 25)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Abraham Y. Chen (Mar 25)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Owen DeLong via NANOG (Mar 25)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Abraham Y. Chen (Mar 26)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Paul Rolland (Mar 26)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Tom Beecher (Mar 26)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC Abraham Y. Chen (Mar 26)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC Randy Carpenter (Mar 26)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC Abraham Y. Chen (Mar 27)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC Fred Baker (Mar 27)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC Fred Baker (Mar 27)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Joe Greco (Mar 26)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Jay Hennigan (Mar 26)
- Re: Let's Focus on Moving Forward Re: V6 still not supported John Gilmore (Mar 26)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Abraham Y. Chen (Mar 26)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Brandon Butterworth (Mar 27)
- Re: Let's Focus on Moving Forward Re: V6 still not supported Christian de Larrinaga via NANOG (Mar 27)