Vint Cerf Re: Backward Compatibility Re: IPv4 address block

Sat Jan 13 14:48:38 UTC 2024

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 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  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> 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> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240113/3cf9b085/attachment.html>