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>