Vint Cerf Re: Backward Compatibility Re: IPv4 address block
Abraham Y. Chen
aychen at avinta.com
Mon Jan 15 22:06:32 UTC 2024
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 <beecher at 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 at avinta.com
> <mailto:aychen at 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 at eList.ISOC.org
> <mailto:InternetPolicy at 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 at elists.isoc.org
> <mailto:internetpolicy at 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 at psg.com
>> <mailto:randy at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240115/d0f6ed40/attachment.html>
More information about the NANOG
mailing list