Dear John:
0) The below message just popped up in my InBox. And, it appears that
there has not been any follow-up comments.
1) How about have a look at our work, (URL below), in case you have not
come across? We propose a very specific way of making use of the 240/4
netblock. There are a
to help people have
that choice.
Keep safe;
Pascal
From: Dave Bell
Sent: mardi 5 avril 2022 13:03
To: Pascal Thubert (pthubert)
Cc: Dave Bell ; Matthew Petach ;
Vasilenko Eduard ; NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Hi Pascal
ep safe;
>
>
>
> Pascal
>
>
>
>
>
> *From:* Dave Bell
> *Sent:* mardi 5 avril 2022 9:45
> *To:* Pascal Thubert (pthubert)
> *Cc:* Matthew Petach ; Vasilenko Eduard <
> vasilenko.edu...@huawei.com>; NANOG
> *Subject:* Re: Let's Focus on Moving Forward Re:
, automatically. That’s a bonus
that could become handy.
Keep safe;
Pascal
From: Dave Bell
Sent: mardi 5 avril 2022 9:45
To: Pascal Thubert (pthubert)
Cc: Matthew Petach ; Vasilenko Eduard
; NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
*From:* Matthew Petach
> *Sent:* mardi 5 avril 2022 0:29
> *To:* Vasilenko Eduard
> *Cc:* Pascal Thubert (pthubert) ; Nicholas Warren <
> nwar...@barryelectric.com>; Abraham Y. Chen ; Justin
> Streiner ; NANOG
> *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not s
below, if there’s any article / doc?
Keep safe;
Pascal
From: Matthew Petach
Sent: mardi 5 avril 2022 0:29
To: Vasilenko Eduard
Cc: Pascal Thubert (pthubert) ; Nicholas Warren
; Abraham Y. Chen ; Justin
Streiner ; NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re
On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG
wrote:
> 240.0.01.1 address is appointed not to the router. It is appointed to
> Realm.
> It is up to the realm owner (ISP to Enterprise) what particular router (or
> routers) would do translation between realms.
>
Please forgive me as
...@geordish.org]
Sent: Monday, April 4, 2022 9:21 PM
To: Nicholas Warren
Cc: Vasilenko Eduard ; Abraham Y. Chen
; Pascal Thubert (pthubert) ; Justin
Streiner ; NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
This seems pretty unworkable.
We would
hub...@cisco.com>>; Justin
Streiner mailto:strein...@gmail.com>>
Cc: NANOG mailto:nanog@nanog.org>>
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
2)When you extend each floor to use the whole IPv4 address pool, however,
you
4, 2022 9:21 PM
To: Nicholas Warren
Cc: Vasilenko Eduard ; Abraham Y. Chen
; Pascal Thubert (pthubert) ; Justin
Streiner ; NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
This seems pretty unworkable.
We would now all need to maintain large CG
>
> From: NANOG On Behalf
> Of Vasilenko Eduard via NANOG
> Sent: Monday, April 4, 2022 3:28 AM
> To: Abraham Y. Chen ; Pascal Thubert (pthubert) <
> pthub...@cisco.com>; Justin Streiner
> Cc: NANOG
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Hello Eduard
In the YADA draft 240.0.0.1 is effectively programmed on the shaft router loop
ack and used as router ID on the IGP inside the shaft…
240 addresses are the only ones advertised by the IGP
> To: Nicholas Warren ; Vasilenko Eduard
>> ; Abraham Y. Chen ; Justin
>> Streiner
>> Cc: NANOG
>> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
>> 202203261833.AYC
>>
>> Hello Nicholas
>>
>&
t works
>
> You were mostly there. Just that routing inside the shaft is probably a
> single IGP with no prefix attached, just links and router IDs.
>
>>
>> Shaft and realm are fun words. I see why they picked them.
>>
>
> Cool
>
> Keep safe;
>
: Monday, April 4, 2022 7:20 PM
To: Nicholas Warren ; Vasilenko Eduard
; Abraham Y. Chen ; Justin
Streiner
Cc: NANOG
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Hello Nicholas
Sorry for the distraction with the names; I did not forge realm, found
Eduard ; Nicholas Warren
; Abraham Y. Chen ; Justin
Streiner
Cc: NANOG
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Hello Eduard
As (badly) written, all ASes and IP addresses that exist today in the internet
could be either reused or moved
;
Pascal
> -Original Message-
> From: Vasilenko Eduard
> Sent: lundi 4 avril 2022 16:52
> To: Nicholas Warren ; Abraham Y. Chen
> ; Pascal Thubert (pthubert) ;
> Justin Streiner
> Cc: NANOG
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supporte
ol
Keep safe;
Pascal
> - Nich
>
> From: NANOG On Behalf
> Of Vasilenko Eduard via NANOG
> Sent: Monday, April 4, 2022 3:28 AM
> To: Abraham Y. Chen ; Pascal Thubert (pthubert)
> ; Justin Streiner
> Cc: NANOG
> Subject: RE: Let's Focus on Moving Forward Re: V6 still no
al Message-
From: Nicholas Warren [mailto:nwar...@barryelectric.com]
Sent: Monday, April 4, 2022 5:33 PM
To: Vasilenko Eduard ; Abraham Y. Chen
; Pascal Thubert (pthubert) ; Justin
Streiner
Cc: NANOG
Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
202203
ft and realm are fun words. I see why they picked them.
- Nich
From: NANOG On Behalf Of
Vasilenko Eduard via NANOG
Sent: Monday, April 4, 2022 3:28 AM
To: Abraham Y. Chen ; Pascal Thubert (pthubert)
; Justin Streiner
Cc: NANOG
Subject: RE: Let's Focus on Moving Forward Re: V6 still not support
nderstands, No need for a new name “Shaft”.
Ed/
From: Abraham Y. Chen [mailto:ayc...@avinta.com]
Sent: Saturday, April 2, 2022 12:45 AM
To: Pascal Thubert (pthubert) ; Vasilenko Eduard
; Justin Streiner
Cc: NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203
Sent using a machine that autocorrects in interesting ways...
> On Apr 2, 2022, at 5:57 AM, Abraham Y. Chen wrote:
>
> 1)" ... darknet ... ":I am not aware of this terminology.
> Nonetheless, I believe that bringing in a not commonly known word into a
> discussion like this is
Hi, Christian:
1) I am a person who normally does not do hearsay. This was why I put
the unverified "street legend" about ancient Lord in parentheses to just
hint the possible extreme. Without it, the flow of my short story really
does not change. Since you spotted on it, I went back to
enko Eduard
; Justin Streiner
*Cc:* NANOG
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC
Hi, Pascal:
1) " ... for the next version. ... ": I am not sure that I can
wait for so long, because I am asking for the basics. The
Your take on English history is a delightful fantasy but it is
just that a delightful fantasy. Norman barons were not typically
concerned with the health of their anglo saxon/british serfs / yoemen
other than providing the required tithes.
But taking you at what seems to be your intention.
Hi, Ant:
1) " ... darknet ... ": I am not aware of this terminology.
Nonetheless, I believe that bringing in a not commonly known word into a
discussion like this is just distraction tactic.
2) " ... progress ... ": EzIP proposes a parallel cyberspace to
the current Internet
: NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Hi, Pascal:
1)" ... for the next version. ...":I am not sure that I can wait
for so long, because I am asking for the basics. The reason that I asked for an
IP packet head
On 1 Apr 2022, at 11:17, Abraham Y. Chen wrote:
>
> 4) EzIP proposes an overlay cyberspace with geographic flavor to restore
> the society infrastructure back to Pt. 2) above, while providing the daily
> services of Pt. 3). It essentially offers a parallel Internet for the
> peasants who
On 3/31/22 9:26 PM, Owen DeLong via NANOG wrote:
On Mar 31, 2022, at 20:51, Masataka Ohta
wrote:
Owen DeLong wrote:
It still suffers from a certain amount of opacity across administrative domains.
So, if an IPv6 prefix is assigned to an apartment building and
the building has no
Owen DeLong via NANOG writes:
> Just because there is a small code snippet you found that prevents casting
> 240/4 as unicast on an interface doesn’t mean that removing that code will
> magically make 240/4 usable in the entire stack.
>
> [...]
>
> The code you found may just be a safety
at’s what I mean by baby steps
for those who want to.
Keep safe;
Pascal
*From:* Abraham Y. Chen
*Sent:* vendredi 1 avril 2022 15:49
*To:* Vasilenko Eduard ; Pascal Thubert
(pthubert) ; Justin Streiner
*Cc:* NANOG
*Subject:* Re: Let's Focus on Moving Forward Re: V6 still not
supported re: 20220326
Hi, Christian:
0) Allow me following your "towers of babel world" metaphor to tell a
short story.
1) In the ancient days, peasants labored under the shadow of the
Tower, following the rules of and paid tax to the Lord living in the
Tower. In return, they expected protection from the
On Mar 31, 2022, at 11:51 PM, Masataka Ohta
wrote:
>
> Owen DeLong wrote:
>
>> It still suffers from a certain amount of opacity across administrative
>> domains.
>
> So, if an IPv6 prefix is assigned to an apartment building and
> the building has no logging mechanism on how addresses are
for those
who want to.
Keep safe;
Pascal
From: Abraham Y. Chen
Sent: vendredi 1 avril 2022 15:49
To: Vasilenko Eduard ; Pascal Thubert (pthubert)
; Justin Streiner
Cc: NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Hi, Pascal:
What I would
*To:* Vasilenko Eduard ; Justin Streiner
; Abraham Y. Chen
*Subject:* RE: Let's Focus on Moving Forward Re: V6 still not
supported re: 202203261833.AYC
Hello Eduard:
Did you just demonstrate that POPs cannot exist? Or that there cannot
be a Default Free Zone?
I agree with your real world issue
thread, and the yada-yatt draft.
Keep safe;
Pascal
> -Original Message-
> From: NANOG On Behalf Of Joe
> Maimon
> Sent: vendredi 1 avril 2022 5:46
> To: Owen DeLong
> Cc: NANOG
> Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
> 20220326
On Behalf Of Justin
Streiner
Sent: dimanche 27 mars 2022 18:12
To: Abraham Y. Chen
Cc: NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Abe:
To your first point about denying that anyone is being stopped from working on
IPv4, I'm referring to users
Owen DeLong wrote:
It still suffers from a certain amount of opacity across administrative domains.
is the corner case.
Obviously, if the apartment complex has no log files, then yes, it remains
relatively useless
It is completely useless for the opacity required by police.
In your one
> On Mar 31, 2022, at 20:51, Masataka Ohta
> wrote:
>
> Owen DeLong wrote:
>
>> It still suffers from a certain amount of opacity across administrative
>> domains.
>
> So, if an IPv6 prefix is assigned to an apartment building and
> the building has no logging mechanism on how addresses
Owen DeLong wrote:
It still suffers from a certain amount of opacity across administrative domains.
So, if an IPv6 prefix is assigned to an apartment building and
the building has no logging mechanism on how addresses are used
within the building, the problem of audit trail opacity is
Owen DeLong wrote:
Yep… He’s absolutely right… We need to find a way to get the networks that
aren’t deploying IPv6 to
get off the dime and stop holding the rest of the world hostage in the IPv4
backwater.
Owen
You keep championing that approach, essentially unchanged for the past
20
Pv4?
>>> People can run IPv4 all they want inside their networks for 1000s of years.
>>> What will it take to be IPv6 only?
>>>
>>>
>>>
>>> From: NANOG >> <mailto:nanog-bounces+jacques.latour=cira...@nanog.org>> On Be
> On Mar 31, 2022, at 15:32 , Joe Maimon wrote:
>
>
>
> Matthew Petach wrote:
>>
>>
>> In short, at the moment, you *can't* deploy IPv6 without also having IPv4
>> somewhere in your network. IPv6 hasn't solved the problem of IPv4
>> address shortage, because you can't functionally deploy
> But as anyone who has tried to deploy IPv6-only networks quickly discovers,
> at the present time, you can't deploy an IPv6-only network with any
> success on the global internet today. There's too many IPv6-ish networks
> out there that haven't fully established their infrastructure to be
gt;> When are we going to give up on IPv4?
>> People can run IPv4 all they want inside their networks for 1000s of years.
>> What will it take to be IPv6 only?
>>
>>
>>
>> From: NANOG On Behalf Of
>> Owen DeLong via NANOG
>> Sent: March 29, 2022 3:52
Matthew Petach wrote:
In short, at the moment, you *can't* deploy IPv6 without also having IPv4
somewhere in your network. IPv6 hasn't solved the problem of IPv4
address shortage, because you can't functionally deploy IPv6 without
also having at least some IPv4 addresses to act as
On Wed, Mar 30, 2022 at 12:47 PM Tom Beecher wrote:
> If the IETF has really been unable to achieve consensus on properly
>> supporting the currently still dominant internet protocol, that is
>> seriously problematic and a huge process failure.
>>
>
> That is not an accurate statement.
>
> The
> On Mar 30, 2022, at 17:00 , Joe Maimon wrote:
>
>
>
> Tom Beecher wrote:
>>
>>If the IETF has really been unable to achieve consensus on properly
>>supporting the currently still dominant internet protocol, that is
>>seriously problematic and a huge process failure.
>>
>>
> On Mar 30, 2022, at 09:16 , Joe Maimon wrote:
>
>
>
> Owen DeLong via NANOG wrote:
>> What you’re really complaining about is that it’s been virtually impossible
>> to gain consensus to move anything IPv4 related forward in the IETF since at
>> least 2015.
>>
>> Well… It’s a consensus
> On Mar 29, 2022, at 17:51 , Masataka Ohta
> wrote:
>
> Owen DeLong wrote:
>
>>> As I repeatedly pointed out, end to end NAT is clean preserving
>>> the universal peer to peer nature of the Internet.
>> Nope… It really isn’t.
>
> Wrong.
>
>> The problem of audit trail opacity is still a
rg>> On Behalf Of Owen
> DeLong via NANOG
> Sent: March 29, 2022 3:52 PM
> To: Abraham Y. Chen mailto:ayc...@avinta.com>>
> Cc: NANOG mailto:nanog@nanog.org>>
> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported
> re: 202203261833.AYC
Vasilenko Eduard via NANOG wrote:
IMHO: IETF is only partially guilty. Who was capable to predict in
1992-1994 that:
- Wireless would become so popular (WiFi is from 1997)
IP mobility WG of IETF was formed in 1992.
- Hardware forwarding (PFE) would be invented (1997) that would have
a big
Thursday, March 31, 2022 3:01 AM
To: Tom Beecher
Cc: NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Tom Beecher wrote:
If the IETF has really been unable to achieve consensus on properly
supporting the currently still dominant internet prot
of
IETF work.
Keep safe;
Pascal
> -Original Message-
> From: NANOG On Behalf Of
> Vasilenko Eduard via NANOG
> Sent: jeudi 31 mars 2022 14:36
> To: Joe Maimon ; Tom Beecher
> Cc: NANOG
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported r
: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On
Behalf Of Joe Maimon
Sent: Thursday, March 31, 2022 3:01 AM
To: Tom Beecher
Cc: NANOG
Subject: Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Tom Beecher wrote:
>
> If the IE
Tom Beecher wrote:
If the IETF has really been unable to achieve consensus on properly
supporting the currently still dominant internet protocol, that is
seriously problematic and a huge process failure.
That is not an accurate statement.
The IETF has achieved consensus on
; Cc: NANOG
> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported
> re: 202203261833.AYC
>
> Submit an Internet draft, same as any other IP related enhancement gets
> introduced.
>
> What you’re really complaining about is that it’s been virtually imp
On Wed, 30 Mar 2022 04:47:08 -0700
John Gilmore wrote:
> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
The draft touches on IANA considerations, but this seems inadequate to
make any more progress and gain wider acceptance.
It seems to me there has been compelling
>
> If the IETF has really been unable to achieve consensus on properly
> supporting the currently still dominant internet protocol, that is
> seriously problematic and a huge process failure.
>
That is not an accurate statement.
The IETF has achieved consensus on this topic. It's explained here
Owen DeLong via NANOG wrote:
What you’re really complaining about is that it’s been virtually
impossible to gain consensus to move anything IPv4 related forward in
the IETF since at least 2015.
Well… It’s a consensus process. If your idea isn’t getting consensus,
then perhaps it’s simply
Tom Beecher wrote:
> I'd be curious to see the data you guys have collected on what it has been
> confirmed to work on if that's available somewhere.
The Implementation Status of unicast 240/4 is in the Appendix of our draft:
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
Owen DeLong wrote:
As I repeatedly pointed out, end to end NAT is clean preserving
the universal peer to peer nature of the Internet.
Nope… It really isn’t.
Wrong.
The problem of audit trail opacity is still a major issue with any form
of stateful NAT.
How poorly you understand NAT.
As
> On Mar 26, 2022, at 17:30 , Masataka Ohta
> wrote:
>
> Owen DeLong via NANOG wrote:
>
>> It still looks like NAT to me.
>
> Almost all the people, perhaps other than you, accept NAT
> as is to keep IPv4 Internet or as part of transition
> plan from IPv4 to IPv6.
>
>> NAT is a disgusting
*From:* NANOG *On Behalf
> Of *Owen DeLong via NANOG
> *Sent:* March 29, 2022 3:52 PM
> *To:* Abraham Y. Chen
> *Cc:* NANOG
> *Subject:* [EXT] Re: Let's Focus on Moving Forward Re: V6 still not
> supported re: 202203261833.AYC
>
>
>
> Submit an Internet draft, s
29, 2022 3:52 PM
To: Abraham Y. Chen
Cc: NANOG
Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported re:
202203261833.AYC
Submit an Internet draft, same as any other IP related enhancement gets
introduced.
What you’re really complaining about is that it’s been virtually
Submit an Internet draft, same as any other IP related enhancement gets
introduced.
What you’re really complaining about is that it’s been virtually impossible to
gain consensus to move anything IPv4 related forward in the IETF since at least
2015.
Well… It’s a consensus process. If your idea
Just because there is a small code snippet you found that prevents casting
240/4 as unicast on an interface doesn’t mean that removing that code will
magically make 240/4 usable in the entire stack.
It’s also important to note that there are at least a dozen IPv4 stacks in
common use with
> On Mar 26, 2022, at 09:37 , Tom Beecher wrote:
>
> Have you ever considered that this may be in fact:
>
> */writing/* and */deploying/* the code that will allow the use of 240/4 the
> way you expect
>
> While Mr. Chen may have considered that, he has repeatedly hand waved that
> it's 'not
>
> A traceroute from my machine to 240.1.2.3 goes through six routers at my
> ISP before stopping (probably at the first default-route-free router).
>
My experience is the opposite. My home edge router (dd-wrt) will pass it,
but nothing in my ISP's network will. $DayJob networks aren't worth
> On Mar 26, 2022, at 06:35 , Abraham Y. Chen wrote:
>
> Hi, Owen:
>
> 0)Re: Ur. Pt. 2):This topic is such a tongue-twister. Let's put it
> aside for now, until I can properly convey the EzIP concept and scheme to you.
>
> 00)Re: Ur. Pt. 4):Okay, I was concerned about how to
Joshua Mallad wrote:
I am growing extremely frustrated by the lack of available internet address
space.
Then, let's have NAT with 32bit port numbers.
How many times are you going to extend and hack away at IPv4,
Perhaps, only once, which means NAT.
Anyway, it is a lot less than hacks to
I usually keep quiet on this list, but this topic is relevant to me as a
smaller (non-BGP level) network operator who would really love to see more
IPv6 deployment.
I don't have experience deploying internet technologies at the highest
level, so I can't say I fully understand the difficulties
james.cut...@consultant.com wrote:
Overlap here refers to network address space address space, a
fundamental part of this discussion. Formerly separate networks
containing separately managed rfc1918 spaces are prone to overlap
require ingenious solutions for end-to-end traffic without
Christopher Morrow wrote:
> I think the advice in the draft, and on the quoted page of Google cloud
> docs is that you can use whatever address space you want for your voc
> network. I think it also says that choosing poorly could make portions if
> the internet unreachable.
>
> I don't see that
Hi, Brandon:
1) "So each RAN has no possibility of redundant connections? ..
": There is difference between "via one IPv4 public address" and
"wide bandwidth or multiple channels". The former is called "numbering
plan". The latter is part of "traffic engineering". The former defines
Sent using a machine that autocorrects in interesting ways...
> On Mar 27, 2022, at 12:18 PM, Abraham Y. Chen wrote:
>
> I am baffled by why does it cause problems on this mailing list.
Are you aware that NANOG is not an IETF list? What would you guess might be the
topic of a list
Sent using a machine that autocorrects in interesting ways...
> On Mar 27, 2022, at 12:18 PM, Abraham Y. Chen wrote:
>
> Honestly, I am still trying to figure out what is the "required" etiquette,
> since what I have received were mostly "complaints" not constructive
> "instructions"
Hi, Randy:
1) " ... does not mean it is trivial to get it done on *billions* of
device. ... ": It looks that your mind is focused on upgrading
existing IoTs. They are not to be perturbed according to the initial and
short term EzIP deployment plans, because it basically is following
On Sat, Mar 26, 2022, 21:42 John Gilmore wrote:
>
> Today Google is documenting to its cloud customers that they should use
> 240/4 for internal networks. (Read draft-schoen-intarea-unicast-240 for
> the citation.) We have received inquiries from two other huge Internet
> companies, which are
According to james.cut...@consultant.com :
>> which, in general, requires provider change and renumbering
>> of globally unique addresses, unless you own /24.
>
>Moot since we are not discussing office moves. However, renumbering to global
>IPv6 addressing allows easy coexistence with the global
> On Mar 27, 2022, at 5:00 AM, Masataka Ohta
> wrote:
>
> james.cut...@consultant.com wrote:
>
> > I have yet to find an economical way to manage a business merger
> > involving two large rfc1918 networks where end to end peering is
> > required and which partially or fully overlap.
>
> As
Hi, Justin:
1) " denying that anyone is being stopped from */working on/*
IPv4, I'm referring to users being able to */communicate via /*IPv4.
": The two topics are quite different. It looks that we may have some
language issues here. So, allow me to stop.
Regards,
Abe
Abe:
To your first point about denying that anyone is being stopped from working
on IPv4, I'm referring to users being able to communicate via IPv4. I have
seen no evidence of that.
I'm not familiar with the process of submitting ideas to IETF, so I'll
leave that for others who are more
On 27 March 2022 15:53:25 Brandon Butterworth wrote:
On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:
EzIP proposes to deploy 240/4
address based RANs, each tethering off the current Internet via one IPv4
public address.
So each RAN has no possibility of redundant
On Sun Mar 27, 2022 at 12:31:48AM -0400, Abraham Y. Chen wrote:
> EzIP proposes to deploy 240/4
> address based RANs, each tethering off the current Internet via one IPv4
> public address.
So each RAN has no possibility of redundant connections? Nobody
of scale would accept such a limitation.
james.cut...@consultant.com wrote:
> I have yet to find an economical way to manage a business merger
> involving two large rfc1918 networks where end to end peering is
> required and which partially or fully overlap.
As you mention "overlap", you should mean business merger implies
network and
james.cut...@consultant.com wrote:
On Mar 26, 2022, at 8:30 PM, Masataka Ohta
wrote:
Owen DeLong via NANOG wrote:
It still looks like NAT to me.
Almost all the people, perhaps other than you, accept NAT
as is to keep IPv4 Internet or as part of transition
plan from IPv4 to IPv6.
NAT
John Gilmore wrote:
Tom Beecher wrote:
*/writing/* and */deploying/* the code that will allow the use of 240/4 the
way you expect
While Mr. Chen may have considered that, he has repeatedly hand waved that
it's 'not that big a deal.', so I don't think he adequately grasps the
scale of that
Dear John:
0) Appreciate very much for your comments.
1) "A traceroute from my machine to 240.1.2.3 goes through six
routers at my ISP before stopping (probably at the first
default-route-free router). ": Great, this confirms our experience.
While our team's skill is far inferior
Paul Rolland wrote:
Hello,
On Sat, 26 Mar 2022 09:35:30 -0400
"Abraham Y. Chen" wrote:
touching the hardware, by implementing the EzIP technique (*/disabling/*
the program code that has been */disabling/* the use of the 240/4
netblock), an existing CG-NAT module becomes a RAN! As to
On 3/26/22 17:38, Joe Greco wrote:
It seems like it should only require changes on a few billion nodes,
given the size of the IPv4 address space, right?
Oh, wait, NAT...
Oh, wait again, several million of those few billion nodes have their
code burned into ROM soldered to the board.
--
Tom Beecher wrote:
> > */writing/* and */deploying/* the code that will allow the use of 240/4 the
> > way you expect
>
> While Mr. Chen may have considered that, he has repeatedly hand waved that
> it's 'not that big a deal.', so I don't think he adequately grasps the
> scale of that challenge.
On Mar 26, 2022, at 8:30 PM, Masataka Ohta
wrote:
>
> Owen DeLong via NANOG wrote:
>
>> It still looks like NAT to me.
>
> Almost all the people, perhaps other than you, accept NAT
> as is to keep IPv4 Internet or as part of transition
> plan from IPv4 to IPv6.
>
>> NAT is a disgusting hack
Owen DeLong via NANOG wrote:
It still looks like NAT to me.
Almost all the people, perhaps other than you, accept NAT
as is to keep IPv4 Internet or as part of transition
plan from IPv4 to IPv6.
NAT is a disgusting hack and destroys the universal peer to peer
nature of the internet in favor
On Sat, Mar 26, 2022 at 12:37:59PM -0400, Tom Beecher wrote:
> >
> > Have you ever considered that this may be in fact:
> >
> > */writing/* and */deploying/* the code that will allow the use of 240/4 the
> > way you expect
> >
>
> While Mr. Chen may have considered that, he has repeatedly hand
- On Mar 26, 2022, at 6:16 PM, Abraham Y. Chen ayc...@avinta.com wrote:
> Hi, Tom & Paul:
> 1) " ... hand waved ... ": Through my line of work, I was trained to behave
> exactly the opposite. I am surprised at you jumping to the conclusion, even
> before challenging me about where did I
Hi, Justin:
1) "... no one is stopping anyone from working on IPv4 ... ":
After all these discussions, are you still denying this basic issue? For
example, there has not been any straightforward way to introduce IPv4
enhancement ideas to IETF since at least 2015. If you know the way,
Hi, Tom & Paul:
1) " ... hand waved ... ": Through my line of work, I was trained
to behave exactly the opposite. I am surprised at you jumping to the
conclusion, even before challenging me about where did I get my
viewpoint from. The fact is, it has been clearly documented in our IETF
>
> It was quite frustrating since we did not have the background in
> networking software
You clearly still do not, if you sincerely believe that commenting out a
single function in every vendor software implementation is all that it
would take.
No need to respond ; I will be filtering all
Hi, Paul:
1) " ... may be in fact: /writing/* and */deploying/* the code ...
": Having no idea why and how the 240/4 netblock became so
mysteriously kept away from being used while the IPv4 was officially
already on its way to "Sun Set", we started the conventional approach as
you
1 - 100 of 108 matches
Mail list logo
