Hi, Warren:
1) " not intended to be endorsement…":
Fully agreed.
2) "Implying that it is is disingenuous… ":
Again, I fully agree.
3) Note that I only stated "It opened our eyes about what were the
implications of EzIP ... ". It was an education moment that was more
than we could expect.
Regards,
Abe (2024-01-15 17:04)
On 2024-01-13 19:50, Warren Kumari wrote:
On Sat, Jan 13, 2024 at 9:48 AM, Tom Beecher <beec...@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 <ayc...@avinta.com
<mailto:ayc...@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.
***********
internetpol...@elist.isoc.org
<mailto:internetpol...@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 <internetpol...@elists.isoc.org
<mailto:internetpol...@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 <ra...@psg.com
<mailto:ra...@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>
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
