Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC

Sat Mar 26 22:16:44 UTC 2022

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 expect
>
>
> While 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 at witbe.net> wrote:
>
>     Hello,
>
>     On Sat, 26 Mar 2022 09:35:30 -0400
>     "Abraham Y. Chen" <aychen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220326/04b3155b/attachment.html>