Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Warren Kumari <warren () kumari net>]

On Sat, Jan 13, 2024 at 9:48 AM, Tom Beecher <beecher () beecher cc> wrote:

> Vint told you the same thing other people have been telling you for years.
> You don't seem to name drop anyone else. Weird.


Indeed — Vint made an observation, but this was not intended to be
endorsement…

Implying that it is is disingenuous…

W


> Respectfully, you have no credibility in this area. I happened to notice
> this gem re-reading your draft last night,
>
> A.1.1. T1a Initiates a Session Request towards T4a
> >    T1a sends a session request to SPR4 that serves T4a by a plain IP
> >    packet with header as in Figure 5, to RG1. There is no TCP port
> >    number in this IP header yet.
> That's a curious statement there at the end. Let's continue though.
>
> A.1.2. RG1 Forwards the Packet to SPR1
> >      RG1, allowing be masqueraded by T1a, relays the packet toward SPR1
> >    by assigning the TCP Source port number, 3N, to T1a, with a header as
> >    in Figure 6,. Note that the suffix "N" denotes the actual TCP port
> >    number assigned by the RG1's RG-NAT. This could assume multiple
> >    values, each represents a separate communications session that T1a is
> >    engaged in. A corresponding entry is created in the RG1 state table
> >    for handling the reply packet from the Destination site. Since T4a's
> >    TCP port number is not known yet, it is filled with all 1's.
> >
> >         0                   1                   2                   3
> >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      1 |Version|IHL (6)|Type of Service|       Total Length (24)       |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      2 |        Identification         |Flags|     Fragment Offset     |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      3 | Time to Live  |    Protocol   |        Header Checksum        |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      4 |              Source Host Number (240.0.0.0)                   |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      5 |           Destination Host Number (69.41.190.148)             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      6 |       Source Port (3N)        |   Destination Port (All 1's)  |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                  Figure 6  TCP/IP Header: From RG1 to SPR1
> Wait a second.. what is a 'TCP/IP header'?
>
> A.1.5. T4a Replies to SPR4
> >    T4a interchanges the Source and Destination identifications in the
> >    incoming TCP/IP packet to create a header as in Figure 9, for the
> >    reply packet to SPR4.
> >
> >         0                   1                   2                   3
> >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      1 |Version|IHL (6)|Type of Service|       Total Length (24)       |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      2 |        Identification         |Flags|     Fragment Offset     |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      3 | Time to Live  |    Protocol   |        Header Checksum        |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      4 |              Source Host Number (240.0.0.10)                  |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      5 |           Destination Host Number (69.41.190.110)             |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      6 |      Source Port (10C)        |     Destination Port (0C)     |
> >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                  Figure 9  TCP/IP Header: From T4a to SPR4
> Oh my.. you actually meant it.
>
> The draft authors don't appear to understand that TCP headers and IP
> headers **are not the same thing**.
>
> I would suggest reviewing RFC 791 ( IPv4 ) , and RFC 793 / 9293 ( TCP,
> original and updated ).
>
>
>
> On Sat, Jan 13, 2024 at 7:35 AM Abraham Y. Chen <aychen () avinta com> wrote:
>
> > Hi, Tom:
> >
> > 1)        " ...  Implying that Vint Cerf ever said anything about EzIP
> > ... ":
> >
> >     FYI - Please see the below copy of a partial eMail thread. Bold, red
> > colored and Italicized letters are to focus on the topic.
> >
> > ***********
> >
> >
> > InternetPolicy () eList ISOC org  eMail thread
> >
> >
> >  On 2021-10-18 16:34, Abraham Y. Chen wrote:
> >
> >
> > Dear Vint:
> >
> >
> >  Yes, this is one perspective for visualizing the EzIP proposal.
> >
> > Thanks,
> >
> >  Abe (2021-10-18 16:33 EDT)
> >
> >
> >  Re: [Internet Policy] 202110180800.AYC Re: Platform self-regulation
> >
> >
> >  On 2021-10-18 10:39, *vinton cerf* wrote:
> >
> >
> > sounds like *eZIP* is basically an *overlay* network.
> >
> >
> >  *v*
> >
> >
> >  On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy <
> > internetpolicy () elists isoc org> wrote:
> >
> >
> > Hi, Scott:
> >
> >
> >  0)    Thanks for your research.
> >
> >
> >  1)    Both SCION (based on my best understanding) and our work named
> > EzIP (phonetic for Easy IPv4) are technical solutions for improving the
> > Internet from its foundation level (the architecture). There are many
> > implications with such schemes including social and legal if one looks into
> > them.
> >
> >
> >  2)    As I responded to Gene's questions (See my eMail with subject line
> > tag: "202110171756.AYC"), the SCION approach implements certain
> > restrictions ......
> >
> > ************
> >
> > 2)    Prior to the above, we were quite unsure about what our team was
> > doing. So, I purposely avoided having any contact with Vint. We had been
> > describing the EzIP's RANs (Regional Area Networks) as "kites floating in
> > the air over an geographic area anchored by an IPv4 address based cord".
> > Although visually clear, it was too wordy. By using one concise word,
> > *overlay*, Vint eloquently classified the EzIP network in terminology
> > sense. It opened our eyes about what were the implications of EzIP and what
> > could be the interactions with respect to the existing Internet, because
> > EzIP was a non-interfering enhancement to an existing system which was a
> > text book case of systems engineering.
> >
> > Hope the above clears the air.
> >
> >
> > Regards,
> >
> >
> > Abe (2024-01-13 07:34)
> >
> >
> > On 2024-01-12 19:24, Tom Beecher wrote:
> >
> >
> > I go into my cave to finish the todo list for the week, and I come out to
> > see Mr. Chen :
> > - Telling Randy Bush he should "read some history" on IPv6
> > - Implying that Vint Cerf ever said anything about EzIP
> >
> > Fairly impressive sequence of self ownage.
> >
> > On Fri, Jan 12, 2024 at 5:46 PM Randy Bush <randy () psg com> wrote:
> >
> >
> >
> >
> > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> > Virus-free.www.avast.com
> > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>