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

["Abraham Y. Chen" <aychen () avinta com>]

Hi, Tom:

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

    As far as we are aware of, Vint was the first and only person who 
branded EzIP as an "overlay" network. Please identify who else said the 
same. Such characterization opened our eyes, so that we carried on. I 
did not dare to consider it was an endorsement as some colleagues are 
now implying.

2)   "  Wait a second.. what is a 'TCP/IP header'?   ":

    Thanks for pointing this out. We made a conscious decision to 
include only the relevant element of the TCP/IP header in the EzIP 
header diagrams because the need to keep its size down to avoid 
occupying too much paper space when repeating the diagram through 
various steps between two ends, with minor change at each step.


Regards,


Abe (2024-01-15 08:07)




On 2024-01-13 09:48, Tom Beecher 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.
>
> 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.orgeMail 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>
>
>
>     
> <#m_9068981657915465318_m_898116838406432442_m_-7063806684299367540_m_-462970855676450446_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com