Mailing List Archive: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

Vint Cerf Re: Backward Compatibility Re: IPv4 address block

Jan 13, 2024, 4:35 AM

Post #1 of 12 (265 views)

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:
>

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

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

chris at thesysadmin

Jan 13, 2024, 6:32 AM

Post #2 of 12 (263 views)

Permalink

Implementing EzIP, as Forrest mentioned 3 days ago, has far more challenges
than implementing IPv6. It will also cause far more incompatibilities when
it comes to routing traffic between a network which has implemented it and
one that hasn't. It also sounds like another version of NAT, non-routable
addresses behind a box which allows other networks to access it via a
gateway. The implementation of IPv6 can be done within weeks for smaller
organisations and networks and in less than a year for larger
organisations, and the best part is that virtually every hardware vendor
already supports it. The majority of our problems can be solved by using
existing protocols, in my view we don't need another. If anything it only
detracts from what we should be working towards.

Further, over the last three days you've changed the subject line of the
thread at least 12 times. Can you please stop changing it because every
time you do, it starts a new thread and makes it rather difficult to keep
track of the discussion. I also don't believe I'm the first one to raise
this either.

https://i.imgur.com/7WIzwEP.png

Regards,
Christopher Hawker

On Sat, 13 Jan 2024 at 23:35, 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>
> <#m_-4880440387061228082_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

beecher at beecher

Jan 13, 2024, 6:48 AM

Post #3 of 12 (263 views)

Permalink

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.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>
> <#m_9068981657915465318_m_898116838406432442_m_-7063806684299367540_m_-462970855676450446_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

gem at rellim

Jan 13, 2024, 11:45 AM

Post #4 of 12 (263 views)

Permalink

Yo Abraham!

On Sat, 13 Jan 2024 07:35:09 -0500
"Abraham Y. Chen" <aychen@avinta.com> wrote:

> FYI - Please see the below copy of a partial eMail thread. Bold,
> red colored and Italicized letters are to focus on the topic.

Uh, you realize many of us never see your red or italics?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

aychen at avinta

Jan 13, 2024, 12:55 PM

Post #5 of 12 (262 views)

Permalink

Hi, Gary:

0)    My apologies!

1)    I thought that I am one of only a few who insist on using the most
basic tools that get the job done, such preferring hand tools than power
tools if possible. I believed that the ThunderBird eMail client software
was pretty basic. Your message just reminds me that there are colleagues
here probably still using plain text editors for eMail?

I shall keep this in mind for my future eMails.

Regards,

Abe (2024-01-13 15:54)

On 2024-01-13 14:45, Gary E. Miller wrote:
> Yo Abraham!
>
> On Sat, 13 Jan 2024 07:35:09 -0500
> "Abraham Y. Chen"<aychen@avinta.com> wrote:
>
>>     FYI - Please see the below copy of a partial eMail thread. Bold,
>> red colored and Italicized letters are to focus on the topic.
> Uh, you realize many of us never see your red or italics?
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> gem@rellim.com Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can't measure it, you can't improve it." - Lord Kelvin

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

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

bill at herrin

Jan 13, 2024, 12:57 PM

Post #6 of 12 (262 views)

Permalink

On Sat, Jan 13, 2024 at 6:32?AM Christopher Hawker <chris@thesysadmin.au> wrote:
> Further, over the last three days you've changed the subject
> line of the thread at least 12 times. Can you please stop changing
> it because every time you do, it starts a new thread and makes it
> rather difficult to keep track of the discussion. I also don't believe
> I'm the first one to raise this either.

He has indeed been asked to do so before but is too rude to comply.

Stop feeding the troll.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

mike.lyon at gmail

Jan 13, 2024, 1:06 PM

Post #7 of 12 (262 views)

Permalink

Some of us still use pine…
-Mike

On Jan 13, 2024, at 12:57, Abraham Y. Chen <aychen@avinta.com> wrote:

?

Hi, Gary:

0) My apologies!

1) I thought that I am one of only a few who insist on using the most basic tools that get the job done, such preferring hand tools than power tools if possible. I believed that the ThunderBird eMail client software was pretty basic. Your message just reminds me that there are colleagues here probably still using plain text editors for eMail?

I shall keep this in mind for my future eMails.

Regards,

Abe (2024-01-13 15:54)

On 2024-01-13 14:45, Gary E. Miller wrote:

Yo Abraham! On Sat, 13 Jan 2024 07:35:09 -0500 "Abraham Y. Chen" <aychen@avinta.com> wrote:
FYI - Please see the below copy of a partial eMail thread. Bold, red colored and Italicized letters are to focus on the topic.
Uh, you realize many of us never see your red or italics? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient"]Virus-free.https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient"]www.avast.com

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

randy at psg

Jan 13, 2024, 2:58 PM

Post #8 of 12 (254 views)

Permalink

> Some of us still use pine$B!D(B

i thought most pine users had moved to mutt

randy, who uses wanderlust under emacs :)

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

warren at kumari

Jan 13, 2024, 4:50 PM

Post #9 of 12 (254 views)

Permalink

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>
>>
>

Re: classic mail, was Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

johnl at iecc

Jan 13, 2024, 7:34 PM

Post #10 of 12 (254 views)

Permalink

It appears that Randy Bush <randy@psg.com> said:
>> Some of us still use pine$B!D(B
>
>i thought most pine users had moved to mutt

Some, but pine (now called alpine) is still actively maintained and
does some things better than mutt, particularly if you want to keep
track of multiple inboxes on different servers.

>randy, who uses wanderlust under emacs :)
>

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

aychen at avinta

Jan 15, 2024, 5:07 AM

Post #11 of 12 (251 views)

Permalink

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

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block [ In reply to ]

aychen at avinta

Jan 15, 2024, 2:06 PM

Post #12 of 12 (250 views)

Permalink

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@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
> <mailto: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
> <mailto: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
> <mailto: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
>> <mailto: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>
>
>

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