Re: Server rental inside of One Wilshire in Los Angeles

[Christopher Hawker]

While it may be a plausible scenario, it IMO is highly unlikely (< 
0.0001%) that this is the case in this situation, given the person that 
is asking...

Regards,
Christopher Hawker

From: NANOG  on behalf of Saku 
Ytti 
Sent: Thursday, August 8, 2024 3:13 PM
To: Christopher Morrow 
Cc: nanog@nanog.org 
Subject: Re: Server rental inside of One Wilshire in Los Angeles

On Wed, 7 Aug 2024 at 20:05, Christopher Morrow  wrote:

> I'd bet the real answer is that someone wants to connect a commodity
> server to an IX and pretend to be
> some network/asn and then do some not terrific things with that setup :(
>
> seen this in AMSIX and DECIX ... don't know that I've not seen it also
> at 1-wilshire ;(

This seems very plausible, considering the chosen demo. Thanks.

--
  ++ytti

RE: Contact mail for Weekly Global Routing Table Report has ended up on Spamhaus HBL

[Christopher Hawker]

It appears that pfsi...@gmail.com is no longer listed, according to the IP and 
Domain Reputation Checker on the Spamhaus website 
(https://check.spamhaus.org/results?query=pfsi...@gmail.com).

Perhaps it has been de-listed?

A suggestion to share this information instead of emailing it is to host it on 
a website somewhere that people can access it if they have a need for it?

Regards,
Christopher Hawker

-Original Message-
From: NANOG  On Behalf Of Philip 
Smith
Sent: Monday, 5 August 2024 12:38 PM
To: Nanog 
Subject: Re: Contact mail for Weekly Global Routing Table Report has ended up 
on Spamhaus HBL

Laura Smith wrote on 4/8/2024 19:42:
> Just as an FYI, it appears the pfsinoz -at- gmail.com address given in the 
> Weekly Global Routing Table Report has sended up on the Spamhaus HBL list.
> 
> You might want to fix this to ensure visibility of the reports are 
> maintained. :)

Sigh, yes, and the role account email address that posts the weekly report too. 
:-(

I'm open to ideas what to do next. Or just stop posting the routing report - 
Geoff has long since stopped posting the CIDR Report (it only goes to APOPS 
list in AsiaPac now).

philip
--

A single place for information relating to the deployment and usage of RPKI

[Christopher Hawker]

Hello All,

When it comes to RPKI, its deployment and usage, there is a fair bit of 
information available on the Internet. Each RIR has their own guides for 
creating ROAs, each router vendor and developer has their own guides for 
deploying route object validation on their devices and software, each Relying 
Party software developer has their own how-to guide on 
installing/configuring/maintaining the software, among others. What I haven’t 
been able to find thus far is a place where all of this information is 
altogether, in one place, for simplicity and ease of comparison to find the 
best solution for a network operator’s needs.

This is where the RPKI Deployment Hub comes in.

The RPKI Deployment Hub is the start of a documentation site that is designed 
to compile all of this information in one place. For new network operators this 
may prove to be an invaluable tool to find the best method of operating their 
own RP software, for students this may be a source of information to help 
further their studies, or for long-standing network operators it may be a 
resource for them to keep up-to-date with the latest methods. It is presently 
being hosted on GitHub pages, where each commit to the underlying repository 
updating the site live.

The site itself is located at https://rpkihub.au<https://rpkihub.au/>, with the 
GitHub repository located at https://github.com/thesysadmindev/rpkihub.

Unfortunately, I can only do so much, and this is where I need to ask for 
contributors to help work on this site. As we all know, there are a large 
number of router vendors on the market, each with their own way of implementing 
RPKI. Cisco, Juniper, MikroTik, Nokia, Arista, and the like all do things 
differently. It would be a wonderful world if they all worked the exact same 
way with the same commands. It’d make life a lot easier for us. What I’m 
calling out to the community for, is for assistance with building this site as 
it is impossible for me to look at every major hardware vendor and model. We 
need information such as router configurations relating to RPKI and the 
commands used, along with the vendor names, hardware models and software 
versions. The idea to this is that people can look at a guide, find their 
router model and it’ll tell them how to configure route object validation. As 
for creating ROAs, it’ll tell them how to do so with their respective RIRs. I 
understand that the best source of information for this is from the RIR itself 
and will always be the case; this is simply designed to provide everything in 
one central location. If there are any members from the other four RIRs (as I 
have already put together a guide for creating ROAs within MyAPNIC) who are 
willing to work with me to develop a guide with screenshots it would be greatly 
appreciated It could even be as simple as sending me an email with the steps 
listed and a few screenshot attachments and I can work on creating the guide 
otherwise you’re welcome to submit a pull request on the repository.

I would also like to hear about people’s experiences with deploying RPKI across 
their networks, why you chose to and for those who haven’t or won’t, why that 
is the case. This sort of information would be valuable to help shape the site.

If you would like to contribute to this project, you can do so via any number 
of ways:


  1.  Open a pull request against the repository on GitHub.
  2.  Click on the “Edit This Page” button on any page on the site to take you 
straight to its source on GitHub where you can make changes and open a PR 
directly from the GitHub site.
  3.  Send me an email to ch...@thesysadmin.au<mailto:ch...@thesysadmin.au>.
  4.  Drop me a direct message on Discord (Username: thesysadmin).


The site itself is licensed under GPLv3, so feel free to tear it apart, share 
it and work together. If you also have any other recommendations as to how it 
can be improved or if you feel there is anything missing, do let me know.

Regards,
Christopher Hawker

Re: Geolocation IP - www.firstinterstatebank.com

[Christopher Hawker]

As trivial as this sounds, do you have a geofeed for your ranges set-up?

https://datatracker.ietf.org/doc/html/rfc8805

Regards,
Christopher Hawker

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: NANOG  on behalf of Jarek 
Kasjaniuk 
Sent: Monday, July 1, 2024 10:34:14 PM
To: nanog@nanog.org 
Subject: Geolocation IP - www.firstinterstatebank.com

Hello,

does anyone have contact to someone from 
www.firstinterstatebank.com<http://www.firstinterstatebank.com> ?

Some IP addessess from ASN 31998 can't access their website.
We see information like:
"we have limited website access for IP addresses outside
of the United States and Canada to online banking platforms only."

I have sent e-mails to contacts found in ARIN, but no response.

Thanks
--
Jarek Kasjaniuk

Re: charging for config changess

[Christopher Hawker]

AS7545 charge fees for changes. Even for trivial things such as updating RDNS 
records.

CH

Get Outlook for Android

From: NANOG  on behalf of Tim 
Burke 
Sent: Monday, July 1, 2024 11:33:46 AM
To: Randy Bush 
Cc: NANOG 
Subject: Re: charging for config changess

First I’ve heard of a provider doing it… and we do business with 3356, the one
carrier I’d expect to do something like this :-)

Might just be me, but I rarely have to have config changes done on circuits
after provisioning, short of enabling dual stack bgp on a circuit that didn’t
have it previously, or if a provider did something silly with your config after
provisioning/acceptance like send you a default route all of a sudden.

Despite that, I know there are lots of people that can’t decide on how they
want to do things, or refuse to use and/or don’t understand things like IRR.
I don’t do anything with 1299 (yet), but I could potentially see this as a
“PITA surcharge” to discourage people from being unable to make their minds up…
surely they would waive it for clueful customers who are making a reasonable
quantity of changes.

> On Jun 30, 2024, at 4:17 PM, Randy Bush  wrote:
>
> has charging for config changes a la
> https://www.arelion.com/customer-excellence/customer-support/online-technical-change-pricing
> become common while i was not looking?  admittedly, i have not looked
> for a long time.
>
> randy

Re: Small Internet border router options?

[Christopher Hawker]

+1 on the CCR2216 routers, rock-solid stuff...

Regards,
Christopher Hawker

From: NANOG  on behalf of Tony 
Wicks 
Sent: Tuesday, May 14, 2024 5:08 AM
To: 'Tom Samplonius' 
Cc: 'NANOG' 
Subject: RE: Small Internet border router options?

Juniper MX204, Nokia SR1/SR1s or for the cheaper side  Mikrotik CCR2216

-Original Message-
From: NANOG  On Behalf Of Tom
Samplonius
Sent: Tuesday, May 14, 2024 6:52 AM
To: NANOG 
Subject: Small Internet border router options?


  What are using for small campus border routers?  So four to eight 10G
ports with a FIB for full scale L3?


Tom

Re: Why are paper LOAs still used?

[Christopher Hawker]

Hi Seth,

LOAs can't be considered more trustworthy than IRR objects. The RIRs operate 
IRRdb services as part of the services they offer which network operators 
should be using instead of the free and paid non-authoritative IRRdb operators.

If you don’t mind, could you please reach out to me off-list with who the VPS 
hosting provider is that is only accepting LOAs? I’d like to reach out to them 
to discuss their decision.

I’m doing a talk at APRICOT 2024 on using ROAs to replace LOAs. In my view 
there's no reason why network operators cannot use ROAs instead to validate the 
routes received from their peers, be they upstream or downstream.

Regards,
Christopher Hawker


Sent from my iPhone

On 27 Feb 2024, at 1:57 am, Seth Mattinen via NANOG  wrote:

Why do companies still insist on, or deploy new systems that rely on paper LOA 
for IP and ASN resources? How can this be considered more trustworthy than RIR 
based IRR records?

And I'm not even talking about old companies, I have a situation right now 
where a VPS provider I'm using will no longer use IRR and only accepts new 
paper LOAs. In the year 2024. I don't understand how anyone can go backwards 
like that.

~Seth

Re: The Reg does 240/4

[Christopher Hawker]

Owen,

This is the first time we've presented this case so I'm uncertain as to how 
you've come to the conclusion that I've "presented [my] case numerous times" 
and that we "continue to persist".

I also don't know how us diverting energy from 240/4 towards IPv6 deployment in 
privately-owned networks will help. People cannot be made to adopt IPv6 
(although IMO they should) and until they are ready to do so we must continue 
to support IPv4, for new and existing networks. While we can encourage and help 
people move towards IPv6 we can't force adoption through prevention of access 
to IPv4.

Regards,
Christopher Hawker

From: Owen DeLong 
Sent: Thursday, February 15, 2024 4:23 AM
To: Christopher Hawker 
Cc: Tom Beecher ; North American Operators' Group 

Subject: Re: The Reg does 240/4

This gift from the bad idea fairy just keeps on giving. You’ve presented your 
case numerous times. The IETF has repeatedly found no consensus for it and yet 
you persist.

Think how many more sites could have IPv6 capability already if this wasted 
effort had been put into that, instead.

Owen


On Feb 13, 2024, at 14:16, Christopher Hawker  wrote:


Hi Tom,

We aren't trying to have a debate on this. All we can do is present our case, 
explain our reasons and hope that we can gain a consensus from the community.

I understand that some peers don't like the idea of this happening and yes we 
understand the technical work behind getting this across the line. It's easy 
enough for us to say "this will never happen" or to put it into the "too hard" 
basket, however, the one thing I can guarantee is that will never happen, if 
nothing is done.

Let's not think about ourselves for a moment, and think about the potential 
positive impact that this could bring.

Regards,
Christopher Hawker
________
From: Tom Beecher 
Sent: Wednesday, February 14, 2024 1:23 AM
To: Christopher Hawker 
Cc: North American Operators' Group ; aus...@lists.ausnog.net 
; Christopher Hawker via sanog ; 
apnic-t...@lists.apnic.net 
Subject: Re: The Reg does 240/4

Now, we know there's definitely going to be some pushback on this. This won't 
be easy to accomplish and it will take some time.

 It won't ever be 'accomplished' by trying to debate this in the media.

On Tue, Feb 13, 2024 at 5:05 AM Christopher Hawker 
mailto:ch...@thesysadmin.au>> wrote:
Hello all,

[Note: I have cross-posted this reply to a thread from NANOG on AusNOG, SANOG 
and APNIC-Talk in order to invite more peers to engage in the discussion on 
their respective forums.]

Just to shed some light on the article and our involvement...

Since September 1981, 240/4 has been reserved for future use, see 
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml. 
This space has always been reserved for future use and given the global 
shortage of available space for new network operators we feel it is appropriate 
for this space to be reclassified as Unicast space available for delegation by 
IANA/PTI to RIRs on behalf of ICANN.

At present, the IP space currently available for RIRs to delegate to new 
members is minimal, if any at all. The primary goal of our call for change is 
to afford smaller players who are wanting to enter the industry the opportunity 
to do so without having to shell out the big dollars for space. Although I do 
not agree with IP space being treated as a commodity (as this was not what it 
was intended to be), those who can afford to purchase space may do so and those 
who cannot should be able to obtain space from their respective RIR without 
having to wait over a year in some cases just to obtain space. It's not 
intended to flood the market with resources that can be sold off to the highest 
bidder, and this can very well be a way for network operators to plan to 
properly roll out IPv6. At this point in time, the uptake and implementation of 
IPv6 is far too low (only 37% according to https://stats.labs.apnic.net/ipv6) 
for new networks to deploy IPv6 single-stack, meaning that we need to continue 
supporting IPv4 deployments.

The reallocation of IPv4 space marked as Future Use would not restrict or 
inhibit the deployment of IPv6, if anything, in our view it will help the 
deployment through allowing these networks to service a greater number of 
customers than what a single /24 v4 prefix will allow. Entire regions of an 
economy have the potential to be serviced by a single /23 IPv4 prefix when used 
in conjunction with IPv6 space.

Now, some have argued that we should not do anything with IPv4 and simply let 
it die out. IPv4 will be around for the foreseeable future and while it is, we 
need to allow new operators to continue deploying networks. It is unfair of us 
to say "Let's all move towards IPv6 and just let IPv4 die" how

Re: The Reg does 240/4

[Christopher Hawker]

Hi Christian,

The idea to this is to allow new networks to emerge onto the internet, without 
potentially having to fork out substantial amounts of money.

I am of the view that networks large enough to require more than a /8 v4 for a 
private network, would be in the position to move towards IPv6-only. Meta has 
already achieved this 
(https://engineering.fb.com/2017/01/17/production-engineering/legacy-support-on-ipv6-only-infra/)
 by rolling out dual-stack on their existing nodes and enabling new nodes as 
IPv6-only. I cannot think of a bigger waste of resources that have the 
possibility of being publicly used, than to allocate an additional 16 x /8 to 
RFC1918 space.

The same argument could be had about using larger than a /8 for private 
networking. Why not use IPv6?

Regards,
Christopher Hawker

From: Christian de Larrinaga 
Sent: Wednesday, February 14, 2024 11:51 PM
To: Christopher Hawker 
Cc: Denis Fondras ; nanog@nanog.org 
Subject: Re: The Reg does 240/4

excuse top posting -

I don't see a case for shifting 240/4 into public IP space if it is just
going to sustain the rentier sinecures of the existing IPv4
incumbencies. In other words if RIRs don't use it boost new entrants it
will just add another knot to the stranglehold we are in vis IPv4.

I can see a potential case for shifting it from experimental to private
space given the fact that "the rest of us" without public IP space and
natted behind CGNATs have taken to use IPv4 for wireguard, containers,
zero configs and so on, to tie our various locations, services and
applications together within our own private distributed nets and expose
our services for public consumption over IPv6.


C

Christian de Larrinaga


Christian Christopher Hawker  writes

> Hi Denis,
>
> It will only be burned through if RIR communities change policies to allow 
> for larger delegations than what is
> currently in place. I believe that some level of change is possible whilst 
> limiting the exhaustion rate, e.g. allowing
> for delegations up to a maximum holding of a /22, however we shouldn't go 
> crazy (for want of a better phrase)
> and allow for delegations of a /20, /19 etc.
>
> If this was only going to give us a potential 1-3 years' worth of space, then 
> I would agree in saying that it is a waste
> of time, would take far too long to make the space usable and wouldn't be 
> worth it. However, as long as we don't
> get greedy, change the maximum allowed delegation to large delegations, and 
> every Tom/Dick/Harry applying
> for a /16 allocation then 240/4 will last us a lengthy amount of time, at 
> least a few decades.
>
> Regards,
> Christopher Hawker
> -
> From: NANOG  on behalf of Denis 
> Fondras via NANOG
> 
> Sent: Wednesday, February 14, 2024 11:10 PM
> To: nanog@nanog.org 
> Subject: Re: The Reg does 240/4
>
> Le Tue, Feb 13, 2024 at 03:24:21PM -0800, David Conrad a écrit :
>> This doesn’t seem all that positive to me, particularly because it’s 
>> temporary
>> since the underlying problem (limited resource, unlimited demand) cannot be
>> addressed.
>>
>
> I agree with this.
> Yet I am in favor of changing the status of 240/4, just so it can get burned
> fast, we stop this endless discussion and can start to deploy IPv6 again.
>
> Denis


--
Christian de Larrinaga

Re: The Reg does 240/4

[Christopher Hawker]

John,

If you feel that it is wasted time, you are welcome to not partake in the 
discussion. Your remarks have been noted.

It's all well and good to say that "more sites could have IPv6 if time wasn't 
being wasted on 240/4" however we can only do so much regarding the deployment 
of v6 within networks we manage. All we can do is educate people on the 
importance of IPv6 uptake, we can not force people to adopt it. The only way to 
rapidly accelerate the uptake of IPv6 is for networks is to either offer better 
rates for v6 transit, or disable v4 connectivity completely.

Otherwise v6 connectivity is going to dawdle at the current rate it is.

Regards,
Christopher Hawker

From: NANOG  on behalf of John 
Levine 
Sent: Thursday, February 15, 2024 10:11 AM
To: nanog@nanog.org 
Subject: Re: The Reg does 240/4

It appears that William Herrin  said:
>On Wed, Feb 14, 2024 at 9:23 AM Owen DeLong via NANOG  wrote:
>> Think how many more sites could have IPv6 capability already if this wasted 
>> effort had been put into that, instead.
>
>"Zero-sum bias is a cognitive bias towards zero-sum thinking;

Well, OK, think how many more sites could hav IPv6 if people weren't
wasting time arguing about this nonsense.

R's,
John

Re: The Reg does 240/4

[Christopher Hawker]

Hi David,

I agree with the fact that introducing this space has the very real risk of it 
being obtained by the highest bidder. Perhaps I may be naive in believing that 
we have a possible chance to delegate this space wisely and prevent it from 
being exhausted at a rather rapid rate, however I can only hope that people 
will see the potential benefit that this could bring, and policy not being 
changed to benefit the larger players in the space.

IP resources were never intended to become a commodity, rather a tool that 
allowed people to globally connect. It should never have become a commodity, 
and it's a shame that it is being treated as such with a price tag put on it.

Regards,
Christopher Hawker

From: David Conrad 
Sent: Wednesday, February 14, 2024 1:03 PM
To: Christopher Hawker 
Cc: North American Operators' Group 
Subject: Re: The Reg does 240/4

Christopher,

On Feb 13, 2024, at 4:14 PM, Christopher Hawker  wrote:
This is a second chance to purposefully ration out a finite resource.

Perhaps I’m overly cynical, but other than more players and _way_ more money, 
the dynamics of [limited resource, unlimited demand] don’t appear to have 
changed significantly from the first time around. However, I suspect the real 
roadblock you’ll face in policy discussions (aside from the folks who make 
their money leasing IPv4 addresses) is the argument that efforts to ration and 
thereby extend the life of IPv4 will continue to distort the market and impede 
the only useful signal to network operators regarding the costs of remaining 
with IPv4 compared to supporting IPv6.  Good luck!

Regards,
-drc

Re: The Reg does 240/4

[Christopher Hawker]

Hi Denis,

It will only be burned through if RIR communities change policies to allow for 
larger delegations than what is currently in place. I believe that some level 
of change is possible whilst limiting the exhaustion rate, e.g. allowing for 
delegations up to a maximum holding of a /22, however we shouldn't go crazy 
(for want of a better phrase) and allow for delegations of a /20, /19 etc.

If this was only going to give us a potential 1-3 years' worth of space, then I 
would agree in saying that it is a waste of time, would take far too long to 
make the space usable and wouldn't be worth it. However, as long as we don't 
get greedy, change the maximum allowed delegation to large delegations, and 
every Tom/Dick/Harry applying for a /16 allocation then 240/4 will last us a 
lengthy amount of time, at least a few decades.

Regards,
Christopher Hawker

From: NANOG  on behalf of Denis 
Fondras via NANOG 
Sent: Wednesday, February 14, 2024 11:10 PM
To: nanog@nanog.org 
Subject: Re: The Reg does 240/4

Le Tue, Feb 13, 2024 at 03:24:21PM -0800, David Conrad a écrit :
> This doesn’t seem all that positive to me, particularly because it’s temporary
> since the underlying problem (limited resource, unlimited demand) cannot be
> addressed.
>

I agree with this.
Yet I am in favor of changing the status of 240/4, just so it can get burned
fast, we stop this endless discussion and can start to deploy IPv6 again.

Denis

Re: The Reg does 240/4

[Christopher Hawker]

Hi Bill,

I agree, that a more viable path may be to look at moving it from reserved to 
unicast (which in itself would be relatively easy to accomplish). Once this has 
been done we could then look at possible use-cases for it instead of trying to 
trying to jump 4 steps ahead.

The idea to this discussion is to get feedback/input and talk about this. If 
there is such a strong push away from this from all stakeholders (and not just 
the top 1% of network operators) then it may not be the way to go. Everyone 
needs to be afforded a say.

Regards,
Christopher Hawker

From: William Herrin 
Sent: Wednesday, February 14, 2024 10:06 AM
To: Christopher Hawker 
Cc: North American Operators' Group 
Subject: Re: The Reg does 240/4

On Tue, Feb 13, 2024 at 2:34 PM Christopher Hawker  wrote:
> Having [240/4] reclassified as unicast space is indeed much easier.

Hi Chris,

If I were spending my time on the effort, that's what I'd pursue. It's
a low-impact change with no reasonable counter-argument I've seen. As
you noted, half the vendors already treat it as unicast space anyway.


> With that, comes the argument - what about legacy hardware
> that vendors no longer support, or are out of warranty and no
> longer receive software updates?

What about legacy hardware that doesn't support CIDR? What about the
1990s Sparc Stations that don't have enough ram to run anything
vaguely like a modern web browser? You make the key standards change
(from reserved undefined use to reserved unicast use) and over time
varying potential uses for those unicast addresses become practical
despite the receding legacy equipment.

None of us has a crystal ball saying when IPv4 use will start to fall
off. It's entirely possible It'll still be going strong in 20 more
years. If so, and if 240/4 was defined as unicast now, it'll surely be
practical to use it by then.

Making the simple standards change also lets us debate the "best" use
of the addresses while the needed software change happens in parallel,
instead of holding up the software changes while we debate. Allocating
them to the RIRs isn't the only practical use of a new set of unicast
IP addresses. Other plausible uses include:

* More RFC1918 for large organizations.

* IXP addresses which only host routers, not the myriad servers and
end-user client software.

* ICMP unreachable source address block, for use by routers which need
to emit a destination unreachable message but do not have a global IP
address with which to do so.

* A block of designated private-interconnect addresses intended to be
used by off-internet networks using overlapping RFC1918 which
nevertheless need to interconnect.

Indeed, the only use for which we definitely -don't- need more IPv4
addresses is Multicast.

So, a rush to deploy 240/4 to RIRs is not really warranted.

Regards,
Bill Herrin


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

Re: The Reg does 240/4

[Christopher Hawker]

Hi David,

In order to forecast exhaustion rates, we needed something to measure against. 
It would be rather naive of us to assume that allocation policy would remain 
the same tomorrow as it was yesterday, if APNIC received a /8 from IANA. This 
is where we looked at pre-prop127 delegation sizes of up to a /22. If we were 
to allow applicants who have received either a /23 or /24 post-prop127 to apply 
for resources up to a maximum holding of /22 this would last (again, under 
current policy) 20+ years. These of course as mentioned are dependent on 3 x /8 
prefixes.

The intent of this isn't just to drop more space into the wild to be snatched 
up by the highest bidder, it's supposed to afford new players an opportunity to 
connect without having to fork out a small fortune to do so. I can only hope 
that people understand and see this, and instead of selfishly saying no, see 
what it's trying to do, who it can impact and at least understand. I definitely 
understand that RIR policy can change in as little as 12 months and it very 
well could happen that policies will change that see the exhaustion policies 
implemented over the last 15 years all undone for the sake of being able to get 
a quick /20 and for space to disappear in a few years (again) which I don't 
really think is the right way to go. This is a second chance to purposefully 
ration out a finite resource.

Regards,
Christopher Hawker

From: David Conrad 
Sent: Wednesday, February 14, 2024 10:24 AM
To: Christopher Hawker 
Cc: North American Operators' Group 
Subject: Re: The Reg does 240/4

Christopher,

On Feb 13, 2024, at 2:15 PM, Christopher Hawker  wrote:
Let's not think about ourselves for a moment, and think about the potential 
positive impact that this could bring.

Let’s assume that the class E checks in all IP stacks and application code that 
do or can connect to the Internet are magically removed (not going to argue 
feasibility of this) and control of 240/4 is put into the hands of IANA to 
allocate to the RIRs. Subsequent steps would be:

1. RIRs, following 
https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en, would 
request new /8s, and receive those allocations.
2. Entities[*] with pent up demand would submit requests and have those 
requests filled by the RIRs
3. While more /8s in 240/4 remain, go to step 1
4. Return to status quo ante.

In other words, while the IANA free pool is not (again) empty, network 
operators would be able to get IPv4 address space at a fraction of the market 
price, and then we’d go back to the way things are now.

This suggests the length of time the primary benefit (cheap IPv4 addresses) 
would be enjoyed depends on RIR allocation policies.  ISTR a comment from you 
earlier suggesting that based on current consumption rates, 240/4 would fulfill 
needs for 50 years.  However, this appears to assume that current “soft 
landing” (etc) policies would remain in place.  Why would you assume that?  I 
would imagine there would be non-trivial pressure from the RIR memberships to 
return to the pre-runout policy regime which was burning through multiple /8s 
in months. In particular, I’d think the large scale buyers of address space (as 
well as IP market speculators) who tend to be the most active in RIR policy 
forums would jump at the opportunity to get “huge tracts of land” at bargain 
basement prices again.

This doesn’t seem all that positive to me, particularly because it’s temporary 
since the underlying problem (limited resource, unlimited demand) cannot be 
addressed.  What positive impact do you predict?

Thanks,
-drc
* I’ve purposefully ignored the geopolitical aspect of this here. In reality, I 
suspect there would be pressure for ‘entities’ to include countries, etc.

Re: The Reg does 240/4

[Christopher Hawker]

Hello John,

It'll only take "98 years" if we drag our feet. In practicality, I'm of the 
belief that the first prefix from 240/4 can be delegated in as little as 
optimistically 2 years, and conservatively 5 years.

Regards,
Christopher Hawker

From: NANOG  on behalf of John 
Levine 
Sent: Wednesday, February 14, 2024 8:26 AM
To: nanog@nanog.org 
Subject: Re: The Reg does 240/4

It appears that Lyndon Nerenberg (VE7TFX/VE6BBM)  said:
>And what are they going to do when 240/4 runs out?

That will be a hundred years from now, so who cares?

R's,
John

PS: I know this because it will take 98 years of process before the
RIRs can start allocating it.

Re: The Reg does 240/4

[Christopher Hawker]

Per my original email, looking at current exhaustion rates in the APNIC service 
region, if we stuck to allocating space to new entities and maintained 
allocating a maximum of a /22 to networks, just 3 x /8 would last over 20 
years. This should be a more than sufficient timeframe for a much wider v6 
adoption and deployment.

Regards,
Christopher Hawker

From: NANOG  on behalf of Lyndon 
Nerenberg (VE7TFX/VE6BBM) 
Sent: Wednesday, February 14, 2024 7:42 AM
To: North American Operators' Group 
Subject: Re: The Reg does 240/4

And what are they going to do when 240/4 runs out?

Re: The Reg does 240/4

[Christopher Hawker]

We understand that having 240/4 reclassified as public space for 
assignment/allocation by RIRs will take some time and we are not expecting it 
to happen overnight. Having it reclassified as unicast space is indeed much 
easier. The Linux kernel already supports this (thanks Dave Taht), Windows is a 
"Patch Tuesday" away, and many hardware vendors can enable support for 240/4 
with a minor firmware revision if they already do not.

With that, comes the argument - what about legacy hardware that vendors no 
longer support, or are out of warranty and no longer receive software updates? 
There are a few ways this could go, either network operators replace their 
equipment with equipment that supports this space (and grants allocated for 
organisations in LDCs who may have issues with funding equipment replacement) 
or hardware vendors release a special public firmware update that only 
addresses this change in routability which is exempt from support contract 
requirements (resulting in less equipment from being scrapped).

Regards,
Christopher Hawker

From: William Herrin 
Sent: Wednesday, February 14, 2024 3:43 AM
To: Christopher Hawker 
Cc: North American Operators' Group 
Subject: Re: The Reg does 240/4

On Tue, Feb 13, 2024 at 2:03 AM Christopher Hawker  wrote:
> [Note: I have cross-posted this reply to a thread from NANOG on
> AusNOG, SANOG and APNIC-Talk in order to invite more peers
> to engage in the discussion on their respective forums.]

Chris,

Do not cross-post lists. Many of the folks who want to discuss are
only subscribed to one of the lists and thus cannot post to the
others. This inevitably results in a disjoint and confusing set of
posts with replies to messages for which the originals didn't make it
to the local list. If you want to discuss something on multiple lists
with multiple audiences, start a separate discussion on each.

Honestly, how can you not know this. It's only been mailing list
etiquette for decades.


> we feel it is appropriate for this space to be reclassified as
> Unicast space available for delegation by IANA/PTI to RIRs
> on behalf of ICANN.

That is probably unrealistic. Getting 240/4 reclassified as unicast is
at least plausible. As you say, there's no residual value in
continuing to hold it in reserve. The opportunity cost has fallen near
zero. But before anybody with a clue is willing to see it allocated to
RIRs for general Internet use they'll want to see studies and
experiments which demonstrate that it's usable enough on the public
Internet to be usefully deployed there.

Regards,
Bill Herrin

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

Re: The Reg does 240/4

[Christopher Hawker]

Hi Tom,

We aren't trying to have a debate on this. All we can do is present our case, 
explain our reasons and hope that we can gain a consensus from the community.

I understand that some peers don't like the idea of this happening and yes we 
understand the technical work behind getting this across the line. It's easy 
enough for us to say "this will never happen" or to put it into the "too hard" 
basket, however, the one thing I can guarantee is that will never happen, if 
nothing is done.

Let's not think about ourselves for a moment, and think about the potential 
positive impact that this could bring.

Regards,
Christopher Hawker

From: Tom Beecher 
Sent: Wednesday, February 14, 2024 1:23 AM
To: Christopher Hawker 
Cc: North American Operators' Group ; aus...@lists.ausnog.net 
; Christopher Hawker via sanog ; 
apnic-t...@lists.apnic.net 
Subject: Re: The Reg does 240/4

Now, we know there's definitely going to be some pushback on this. This won't 
be easy to accomplish and it will take some time.

 It won't ever be 'accomplished' by trying to debate this in the media.

On Tue, Feb 13, 2024 at 5:05 AM Christopher Hawker 
mailto:ch...@thesysadmin.au>> wrote:
Hello all,

[Note: I have cross-posted this reply to a thread from NANOG on AusNOG, SANOG 
and APNIC-Talk in order to invite more peers to engage in the discussion on 
their respective forums.]

Just to shed some light on the article and our involvement...

Since September 1981, 240/4 has been reserved for future use, see 
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml. 
This space has always been reserved for future use and given the global 
shortage of available space for new network operators we feel it is appropriate 
for this space to be reclassified as Unicast space available for delegation by 
IANA/PTI to RIRs on behalf of ICANN.

At present, the IP space currently available for RIRs to delegate to new 
members is minimal, if any at all. The primary goal of our call for change is 
to afford smaller players who are wanting to enter the industry the opportunity 
to do so without having to shell out the big dollars for space. Although I do 
not agree with IP space being treated as a commodity (as this was not what it 
was intended to be), those who can afford to purchase space may do so and those 
who cannot should be able to obtain space from their respective RIR without 
having to wait over a year in some cases just to obtain space. It's not 
intended to flood the market with resources that can be sold off to the highest 
bidder, and this can very well be a way for network operators to plan to 
properly roll out IPv6. At this point in time, the uptake and implementation of 
IPv6 is far too low (only 37% according to https://stats.labs.apnic.net/ipv6) 
for new networks to deploy IPv6 single-stack, meaning that we need to continue 
supporting IPv4 deployments.

The reallocation of IPv4 space marked as Future Use would not restrict or 
inhibit the deployment of IPv6, if anything, in our view it will help the 
deployment through allowing these networks to service a greater number of 
customers than what a single /24 v4 prefix will allow. Entire regions of an 
economy have the potential to be serviced by a single /23 IPv4 prefix when used 
in conjunction with IPv6 space.

Now, some have argued that we should not do anything with IPv4 and simply let 
it die out. IPv4 will be around for the foreseeable future and while it is, we 
need to allow new operators to continue deploying networks. It is unfair of us 
to say "Let's all move towards IPv6 and just let IPv4 die" however the reality 
of the situation is that while we continue to treat it as a commodity and allow 
v6 uptake to progress as slowly as it is, we need to continue supporting it v4. 
Some have also argued that networks use this space internally within their 
infrastructure. 240/4 was always marked as Reserved for Future Use and if 
network operators elect to squat on reserved space instead of electing to 
deploy v6 across their internal networks then that is an issue they need to 
resolve, and it should not affect how it is reallocated. It goes against the 
bottom-up approach of policy development by allowing larger network operators 
to state that this space cannot be made unicast because they are using it 
internally (even though it's not listed in RFC1918), and its reallocation would 
affect their networks.

In the APNIC region, there is a policy which only allows for a maximum of a /23 
IPv4 prefix to be allocated/assigned to new members and any more space required 
must be acquired through other means. If (as an example) APNIC were to receive 
3 x /8 prefixes from the 240/4 space this would allow for delegations to be 
made for approximately the next ~50 years whereas if policy was changed to 
allow for delegations 

Re: The Reg does 240/4

[Christopher Hawker]

Hello all,

[Note: I have cross-posted this reply to a thread from NANOG on AusNOG, SANOG 
and APNIC-Talk in order to invite more peers to engage in the discussion on 
their respective forums.]

Just to shed some light on the article and our involvement...

Since September 1981, 240/4 has been reserved for future use, see 
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml. 
This space has always been reserved for future use and given the global 
shortage of available space for new network operators we feel it is appropriate 
for this space to be reclassified as Unicast space available for delegation by 
IANA/PTI to RIRs on behalf of ICANN.

At present, the IP space currently available for RIRs to delegate to new 
members is minimal, if any at all. The primary goal of our call for change is 
to afford smaller players who are wanting to enter the industry the opportunity 
to do so without having to shell out the big dollars for space. Although I do 
not agree with IP space being treated as a commodity (as this was not what it 
was intended to be), those who can afford to purchase space may do so and those 
who cannot should be able to obtain space from their respective RIR without 
having to wait over a year in some cases just to obtain space. It's not 
intended to flood the market with resources that can be sold off to the highest 
bidder, and this can very well be a way for network operators to plan to 
properly roll out IPv6. At this point in time, the uptake and implementation of 
IPv6 is far too low (only 37% according to https://stats.labs.apnic.net/ipv6) 
for new networks to deploy IPv6 single-stack, meaning that we need to continue 
supporting IPv4 deployments.

The reallocation of IPv4 space marked as Future Use would not restrict or 
inhibit the deployment of IPv6, if anything, in our view it will help the 
deployment through allowing these networks to service a greater number of 
customers than what a single /24 v4 prefix will allow. Entire regions of an 
economy have the potential to be serviced by a single /23 IPv4 prefix when used 
in conjunction with IPv6 space.

Now, some have argued that we should not do anything with IPv4 and simply let 
it die out. IPv4 will be around for the foreseeable future and while it is, we 
need to allow new operators to continue deploying networks. It is unfair of us 
to say "Let's all move towards IPv6 and just let IPv4 die" however the reality 
of the situation is that while we continue to treat it as a commodity and allow 
v6 uptake to progress as slowly as it is, we need to continue supporting it v4. 
Some have also argued that networks use this space internally within their 
infrastructure. 240/4 was always marked as Reserved for Future Use and if 
network operators elect to squat on reserved space instead of electing to 
deploy v6 across their internal networks then that is an issue they need to 
resolve, and it should not affect how it is reallocated. It goes against the 
bottom-up approach of policy development by allowing larger network operators 
to state that this space cannot be made unicast because they are using it 
internally (even though it's not listed in RFC1918), and its reallocation would 
affect their networks.

In the APNIC region, there is a policy which only allows for a maximum of a /23 
IPv4 prefix to be allocated/assigned to new members and any more space required 
must be acquired through other means. If (as an example) APNIC were to receive 
3 x /8 prefixes from the 240/4 space this would allow for delegations to be 
made for approximately the next ~50 years whereas if policy was changed to 
allow for delegations up to and including a /22 this would extend the current 
pool by well over 20 years, based on current exhaustion rates and allowing for 
pool levels to return to pre-2010 levels.

Now, we know there's definitely going to be some pushback on this. This won't 
be easy to accomplish and it will take some time. However, if we do nothing 
then nothing will happen. The currently available pool has reached severe 
exhaustion levels yet we have a block representing about 6% of the total 
possible IP space which may not seem like a lot yet it can go a long way.

This call for change is not about making space available for existing networks. 
It is about new networks emerging into and on the internet. While we do work 
towards IPv6 being the primary addressing method we need to continue allow 
those who may not be able to deploy IPv6 to connect to the internet.

Regards,
Christopher Hawker


From: NANOG  on behalf of Jay R. 
Ashworth 
Sent: Tuesday, February 13, 2024 5:19 PM
To: North American Operators' Group 
Subject: The Reg does 240/4

I know we had a thread on this last month, but I can't remember what it
was titled.

ElReg has done a civilian-level backgrounder on the 240/4 issue, for anyone
who wants to read and scoff at it.

Re: The Reg does 240/4

[Christopher Hawker]

Hey there Jay,

It's certainly going to make for a good discussion at APRICOT in a few weeks :-)

Regards,
Christopher Hawker

From: NANOG  on behalf of Jay R. 
Ashworth 
Sent: Tuesday, February 13, 2024 5:19 PM
To: North American Operators' Group 
Subject: The Reg does 240/4

I know we had a thread on this last month, but I can't remember what it
was titled.

ElReg has done a civilian-level backgrounder on the 240/4 issue, for anyone
who wants to read and scoff at it.  :-)

https://www.theregister.com/2024/02/09/240_4_ipv4_block_activism/

Cheers,
-- jra

--
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a reference…)

[Christopher Hawker]

Hello Warren,

Speaking from my experience here.

You've understood correctly. You need to create a null/blackhole route within 
your routing table (static routes work best as it guarantees the route exists) 
in order to announce the /24 supernet if you're using longer subnets (/25 to 
/32). The route needs to exist in the routing table in order for it to be 
advertised. In all the prefixes I've configured and further broken up, I've 
always configured blackhole routes for the /24 with a distance of 254, never 
worked for me without it. Same deal for IPv6.

Regards,
Christopher Hawker

From: NANOG  on behalf of Warren 
Kumari 
Sent: Thursday, February 1, 2024 7:30 AM
To: North American Network Operators' Group 
Subject: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a 
reference…)

Hey all,

This falls into the "Somebody is wrong on the Internet …" category.

So, let's say I'm announcing some address space (e.g 
192.0.2.0/24<http://192.0.2.0/24>), but I'm only using part of it internally 
(e.g 192.0.2.0/25<http://192.0.2.0/25>). I've always understood that it's best 
practice[0] to have a discard route (eg static to null0/discard or similar[1]) 
for what I'm announcing.

There are a bunch of reasons for this, but the standard (or easiest to explain 
one!) is what happens if this comes from some provider space, and they announce 
a supernet/covering route. If I *don't* have a discard/hold-down route, and a 
packet is sent to part of the space I'm not using (e.g 192.0.2.200), I would 
send it to the covering route, they would just send it back to the more 
specific, I'd return it to them, etc…

Many, but not all mechanisms that people use for advertising a route in BGP 
automagically create this sort of discard route (e.g Juniper's 'aggregate'), 
but I wasn't really able to find any useful documentation suggesting that if 
you announce a route, you should make sure that you have some route covering 
all of the space…

Perhaps there isn't really anything saying this (because it's obvious), but I'd 
really like to find something so that I can point at it….

Can anyone help me win this somewhat pointless argument?
W

[0]: Best practice as in "you should do this, unless you've got some weird 
corner case and have thought about it for more than a few seconds"
[1]: Yes, in some cases I'll have e.g an interface that match the announcement, 
and that accomplishes the same thing.
[3]: E.g. 192.0.2.0/24<http://192.0.2.0/24> comes from a provider, and they are 
announcing something shorter.

RE: Mail to Microsoft being falsely marked as spam/bulk

[Christopher Hawker]

For me, it did. To be fair I did have two tickets open through two different 
channels. One of the tickets came back with advice that they had reset the 
score on the domain and IP address as I advised them that it was a private mail 
server, in use by one person (myself) with 2-3 mailboxes in use on the Axigen 
Mail Server software.

It's all about who you get on the day at the time you open the ticket and who 
replies.

Regards,
Christopher Hawker

-Original Message-
From: NANOG  On Behalf Of Bjoern 
Franke via NANOG
Sent: Tuesday, January 23, 2024 11:51 PM
To: nanog@nanog.org
Subject: Re: Mail to Microsoft being falsely marked as spam/bulk


> 
> Yes. Or just sending new stuff in the old ticket. (Apparently, you get 
> a different guy each time, keep trying until you find one who is 
> willing to act.)
> 

That didn't help either.
First, they asked for a proof that I did not use the IP before. After sending 
that proof, they told me that the issue (mails junked) was caused by forwarding 
spam and that I should confirm to Outlooks Technical Standards. After 
confirming this, they told me that they can't do anything, they have no liberty 
to discuss the source of the block and that I should take care of complying to 
Hotmails Technicals Standards.

I've asked them why they even asked for the proof for the usage of the IP if 
they can't do anything and got no reply.

Regards
Bjoern

Re: Mail to Microsoft being falsely marked as spam/bulk

[Christopher Hawker]

I tried this, got a scripted response:

"Unfortunately, after reviewing the information you provided and in
compliance with our mail policies, we are unable to offer immediate resolve
for your deliverability issue."

Will give them credit though for the timing in their response, received it
a few hours later after submission.

Regards,
Christopher Hawker

On Sat, 20 Jan 2024 at 22:19, Stephane Bortzmeyer  wrote:

> On Sat, Jan 20, 2024 at 10:07:39PM +1100,
>  Christopher Hawker  wrote
>  a message of 132 lines which said:
>
> > If there is anyone from Microsoft around that can look into mail issues,
> > could you please reach out to me off-list? Or if anyone has any
> > ideas/suggestions as to how to resolve this, I'd be thankful to hear from
> > you.
>
> In my experience with self-hosting, reporting it to Microsoft with
> <https://olcsupport.office.com/> works sometimes. (Patience and calm
> required.)
>
>

Mail to Microsoft being falsely marked as spam/bulk

[Christopher Hawker]

Hi folks,

I'm having an issue with Microsoft email filtering, where it is flagging
messages from a private mail server as spam, with an SCL of 9 and a BCL of
7, resulting in it being sent to the Junk folder.

We are not seeing this issue with Google's mail environment (being filtered
to junk), confirmed that SPF, DMARC and DKIM are all correct and valid and
that the domain and IP addresses are not on any block lists.

If there is anyone from Microsoft around that can look into mail issues,
could you please reach out to me off-list? Or if anyone has any
ideas/suggestions as to how to resolve this, I'd be thankful to hear from
you.

Thanks,
Christopher Hawker

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

According to the diagram on page 8 of the presentation on your website at
https://www.avinta.com/phoenix-1/home/EzIPenhancedInternet.pdf, it simply
identifies 240/4 as CGNAT space. Routing between regional access networks
typically doesn't take place when using such space on an ISP network, and
most ISPs (that I know of) will offer public addressing when it is
required. Further, if you think the need for DHCP will be eliminated
through the use of your solution, I hate to say it, but ISPs will not
statically configure WAN addressing on CPE for residential services. It
would simply increase the workload of their support and provisioning teams.
Right now, in cases where ISPs use DHCP, they can simply ship a router to
an end-user, the user plugs it in, turns it on, and away they go.
Connectivity to the internet.

If an end-user has a router that does not support OpenWRT, it will require
the end-user to replace their router with one that does in order to connect
to an EzIP-enabled network. This is not reasonably practical. This would
also require router vendors to support connectivity to a proprietary
"semi-public router".

Again, for the sake of completeness, this solution is a waste of time and
resources. A carrier would not have a need for more than ~4.1m devices on a
single regional access network and some may run more than one in a single
region, so as not to put all of their proverbial eggs into the same basket.

Regards,
Christopher Hawker

On Fri, 19 Jan 2024 at 14:49, Abraham Y. Chen  wrote:

> Hi, Christopher:
>
> 1)" If "EzIP" is about using 240/4 as CGNAT space, ...   ":
>
> This correlation is just the starting point for EzIP deployment, so
> that it would not be regarded as a base-less crazy dream. Once a 240/4
> enabled RAN is established as a new network overlaying on the CG-NAT
> infrastructure, the benefits of making use of the 240/4 resources can begin
> to be considered. For example, with sufficient addresses, static address
> administration can be practiced within a RAN which will remove the need for
> DHCP service. From this, related consequences may be discussed.
>
> 2)" I don't think you quite grasp the concept that OpenWRT is not
> compatible with devices that do not support it.  it would not be
> appropriate to expect every device vendor to support it.  ...   ":
>
> Perhaps we have some offset about the terminology of "who supports
> whom?" My understanding of the OpenWrt project is that it is an open-source
> program code that supports a long list (but not all) of primarily
> commercial RGs (Residential/Routing Gateways) and WiFi routers that serve /
> support CPE devices (on-premises IoTs). Its basic purpose is to let private
> network owners to replace the firmware code in the RGs with the OpenWrt
> equivalent so that they will have full control of their RGs and then modify
> them if desired. Thus, the basic release of each OpenWrt code maintains
> most of the original functionalities in the OEM device. So, neither the
> original RG nor any IoT manufacturers need be involved with the OpenWrt,
> let alone supporting it. My reference to its V19.07.3 was the version that
> expanded its usable address pool to include 240/4. That was all.
>
> For sure, OpenWrt does not run on all RGs in the field. But, this does
> not restrict an overlay network like RAN from starting to network only
> those premises with RGs that run on OpenWrt (plus those RGs compatible with
> 240/4 from the factories). Since the existing CG-NAT is not disturbed and
> daily Internet services are going normally, RAN growth can take its time.
> 3)" You've provided a link to a D-Link managed switch, not a router.
> Just because it can support L2 routing, doesn't make it a router.   ":
>
> Correct, this is just a basic example for networking the RGs to
> experiment the RAN configuration. It is not intended to be a full-fledged
> router which will have other considerations that are way beyond what EzIP
> should be involved with.
>
>
> Regards,
>
>
> Abe (2024-01-18 22:48)
>
>
> On 2024-01-15 18:33, Christopher Hawker wrote:
>
> If "EzIP" is about using 240/4 as CGNAT space, let's call it what it is,
> not rename something that already exists and attempt to claim it as a new
> idea.
>
> It is completely unnecessary to use 240/4 as CGNAT space. Here are a few
> reasons why:
>
>1. There are 4,194,304 IPv4 addresses in a /10 prefix. Allowing for a
>/24 from this to be used for CGNAT gateways, load balancing, etc. this
>still allows for 4,194,048 usable addresses for CPE. When performing NAT,
>you would need to allocate each subscriber approximately 1000 ports for NAT
>to work successfully.

Re: Any clue as to when bgp.he.net will be back?

[Christopher Hawker]

It'd be interesting to know how Mimecast made the determination that
bgp.tools is compromised.

Regards,
Christopher Hawker

On Thu, 18 Jan 2024 at 09:47, Rubens Kuhl  wrote:

> It might be due to usage of a new gTLD like .tools. A number of new
> gTLDs use heavy discounting and this is a magnet for abusive
> registrations, unfortunately.
>
> Rubens
>
> On Wed, Jan 17, 2024 at 2:15 PM Tim Burke  wrote:
> >
> > +1 for bgp.tools, it is a superior tool. Sadly, the corporate IT-forced
> DNS filtering at work for “cybersecurity” (Mimecast) thinks it is a
> compromised website for some reason, so bgp.he.net ends up being used
> while I am at the office.
> >
> > On Jan 16, 2024, at 8:44 AM, Ian Chilton  wrote:
> >
> > Hi,
> >
> > Not a direct answer to your question, but if you're not aware of it,
> https://bgp.tools/ is a great tool and shows the same info.
> >
> > Ian
> >
> >
>

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Christopher Hawker]

It was always about using 240/4 as shared service provider space, just a
roundabout way of doing it.

You can call a horse a horse, or you can call it "an animal that pulls a
wagon which carries people and items from A to B". At the end of the day,
it's still a horse.

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 14:00, Brandon Jackson  wrote:

> If I remember correctly, quite a few years ago, "EzIP" was something else
> entirely.
>
> I vaguely remember them talking about having some kind of extended IPv4
> address or to use an extension header or something like that. It was
> something that would essentially require the entire Internet to be reworked
> in order to work. Kind of like this, but even more so because these
> modified bastardized packets would be sent across the DFZ.
>
> And it seems now it's morphed into simply opening up and reusing 240/4
>
>
> Brandon Jackson
> bjack...@napshome.net
>
>
> On Mon, Jan 15, 2024, 19:47 Christopher Hawker 
> wrote:
>
>> From what I gather, "EzIP" is just a fancy name for repurposing the 240/4
>> address space as RFC6598 shared address space for service providers and
>> adding another gateway into a network to make it look like a new
>> technology, nothing more. It does absolutely nothing more than what is
>> already available and in use today. It's a solid NO from me, in case it's
>> not already clear.
>>
>> Regards,
>> Christopher Hawker
>>
>> On Tue, 16 Jan 2024 at 11:16,  wrote:
>>
>>> The reality is your whole concept for EzIP is so impractical and so
>>> unlikely to be implemented by any service provider with half a clue, that
>>> I’m not sure why I would even try to explain to you why a Radio Access
>>> Network is relevant to the Internet.  You obviously have decided you are
>>> smarter than everyone else on NANOG.
>>>
>>> Shane
>>>
>>> On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen  wrote:
>>>
>>> 
>>> Hi, Sronan:
>>>
>>> 1) “Radio Access Network”:
>>>
>>> Thanks for bringing this up. Being an RF engineer by training, I am
>>> aware of this terminology. However, how specific is its claimed applicable
>>> domain?
>>>
>>> 2)I went to search on an acronym site and found a long list of
>>> expressions that abbreviate to RAN. It starts with Royal Australian Navy
>>> and Rainforest Action Network as the third. Then, Return Authorization
>>> Number is the fourth:
>>>
>>> https://www.acronymfinder.com/RAN.html
>>>
>>> 3)In fact, "Regional Area Network" is about twentieth on it! So,
>>> unless there is some kind of Registered Trademark conflict, this probably
>>> is on my low priority to-do list for the time being.
>>> 4) Of course, if you have any alternative to suggest, my ears are
>>> all yours.
>>>
>>> Regards,
>>>
>>> Abe (2024-01-15 18:48)
>>>
>>>
>>>
>>>
>>>
>>> On 2024-01-15 17:14, sro...@ronan-online.com wrote:
>>>
>>> Please don’t use the term RAN, this acronym already has a very specific
>>> definition in the telecom/network space as “Radio Access Network.”
>>>
>>> Shane
>>>
>>> On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen 
>>>  wrote:
>>>
>>> 
>>> Hi, Forrest:
>>>
>>> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
>>> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
>>> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
>>> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
>>> don't see how an upgrade of such equipment to IPv6 could be simpler and
>>> less work. Please elaborate.
>>>
>>> 2)Re: Ur. Pt. 2): Since the RAN still appear to be the original
>>> CG-NAT to the Internet through the same IPv4 link to the Internet core,
>>> services from Google, YouTube, etc. will not know something has changed
>>> either.
>>>
>>> 3)" ... someone with enough market power is going to basically say
>>> "enough is enough"  ...  ":
>>>
>>> We need to look at this transition with a "Divide and Conquer"
>>> perspective. That is, the CG-NAT and consequently the RAN are part of IAP
>>> (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs
>>> (Internet Conten

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Christopher Hawker]

>From what I gather, "EzIP" is just a fancy name for repurposing the 240/4
address space as RFC6598 shared address space for service providers and
adding another gateway into a network to make it look like a new
technology, nothing more. It does absolutely nothing more than what is
already available and in use today. It's a solid NO from me, in case it's
not already clear.

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 11:16,  wrote:

> The reality is your whole concept for EzIP is so impractical and so
> unlikely to be implemented by any service provider with half a clue, that
> I’m not sure why I would even try to explain to you why a Radio Access
> Network is relevant to the Internet.  You obviously have decided you are
> smarter than everyone else on NANOG.
>
> Shane
>
> On Jan 15, 2024, at 6:46 PM, Abraham Y. Chen  wrote:
>
> 
> Hi, Sronan:
>
> 1) “Radio Access Network”:
>
> Thanks for bringing this up. Being an RF engineer by training, I am
> aware of this terminology. However, how specific is its claimed applicable
> domain?
>
> 2)I went to search on an acronym site and found a long list of
> expressions that abbreviate to RAN. It starts with Royal Australian Navy
> and Rainforest Action Network as the third. Then, Return Authorization
> Number is the fourth:
>
> https://www.acronymfinder.com/RAN.html
>
> 3)In fact, "Regional Area Network" is about twentieth on it! So,
> unless there is some kind of Registered Trademark conflict, this probably
> is on my low priority to-do list for the time being.
> 4) Of course, if you have any alternative to suggest, my ears are all
> yours.
>
> Regards,
>
> Abe (2024-01-15 18:48)
>
>
>
>
>
> On 2024-01-15 17:14, sro...@ronan-online.com wrote:
>
> Please don’t use the term RAN, this acronym already has a very specific
> definition in the telecom/network space as “Radio Access Network.”
>
> Shane
>
> On Jan 15, 2024, at 5:12 PM, Abraham Y. Chen 
>  wrote:
>
> 
> Hi, Forrest:
>
> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
> OpenWrt. So that none of the on-premises IoTs will sense any changes. I
> don't see how an upgrade of such equipment to IPv6 could be simpler and
> less work. Please elaborate.
>
> 2)Re: Ur. Pt. 2): Since the RAN still appear to be the original
> CG-NAT to the Internet through the same IPv4 link to the Internet core,
> services from Google, YouTube, etc. will not know something has changed
> either.
>
> 3)" ... someone with enough market power is going to basically say
> "enough is enough"  ...  ":
>
> We need to look at this transition with a "Divide and Conquer"
> perspective. That is, the CG-NAT and consequently the RAN are part of IAP
> (Internet Access Provider) facility. While Google, YouTube, etc. are ICPs
> (Internet Content Providers). Relatively speaking, the IAP is like the
> hardware part of a system, while ICP is the software. They are two separate
> parts when combined will provide the service that customers want. Normally,
> these two parts are separate businesses, although some may be under the
> same owner in some situations. The scenario that you are proposing is like
> back to the old Bell System days when AT&T decided everything. I am sure
> that Internet players will try very hard to avoid being labelled as such.
>
> Regards,
>
>
> Abe (2024-01-15 00:02)
>
>
> On 2024-01-13 03:30, Forrest Christian (List Account) wrote:
>
> A couple of points:
>
> 1) There is less work needed to support IPv6 than your proposed solution.
> I'm not taking about 230/4.  I'm talking about your EzIP overlay.
>
> 2) Assume that Google decided that they would no longer support IPv4 for
> any of their services at a specific date a couple of years in the future.
> That is,  you either needed an IPv6 address or you couldn't reach Google,
> youtube, Gmail and the rest of the public services.  I bet that in this
> scenario every eyeball provider in the country all of a sudden would be
> extremely motivated to deploy IPv6, even if the IPv4 providers end up
> natting their IPv4 customers to IPv6.  I really expect something like this
> to be the next part of the end game for IPv4.
>
> Or stated differently: at some point someone with enough market power is
> going to basically say "enough is enough" and make the decision for the
> rest of us that IPv4 is effectively done on the public internet.   The
> large tech companies all have a

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

If "EzIP" is about using 240/4 as CGNAT space, let's call it what it is,
not rename something that already exists and attempt to claim it as a new
idea.

It is completely unnecessary to use 240/4 as CGNAT space. Here are a few
reasons why:

   1. There are 4,194,304 IPv4 addresses in a /10 prefix. Allowing for a
   /24 from this to be used for CGNAT gateways, load balancing, etc. this
   still allows for 4,194,048 usable addresses for CPE. When performing NAT,
   you would need to allocate each subscriber approximately 1000 ports for NAT
   to work successfully. The entire /10 (less the /24) would require the
   equivalent of a /16 public IPv4 prefix to use the entire 100.64/10 space in
   one region. To put this into comparison, you would use the entire 100.64/10
   space in a city the size of New York or Los Angeles allowing for one
   internet service per 4 or 2 people respectively. It's not practical.
   2. Multiple CGNAT regions that are at capacity would not have a need for
   uniquely routable IP space between them. It's heavily designed for traffic
   from the user to the wider internet, not for inter-region routing. Carriers
   already have systems in place where subscribers can request a public
   address if they need it (such as working from home with advanced corporate
   networks, etc).

100.64/10 is not public IP space, because it is not usable in the DFZ. I
don't believe there is any confusion or ambiguity about this space because
if you do a Whois lookup on 100.64.0.0/10 at any one of the five RIRs, it
reflects that it is IANA shared address space for service providers.
Footnote 6 on the page you referenced reads "100.64.0.0/10 reserved for
Shared Address Space". It has not been delegated to ARIN. Rather clear as
to its use case.

I don't think you quite grasp the concept that OpenWRT is not compatible
with devices that do not support it. It would only work on routers for
which it is compatible and it would not be appropriate to expect every
device vendor to support it. To add-on to this, why would vendors need to
enable 240/4 CGNAT support when their customers don't have a need for it?

You've provided a link to a D-Link managed switch, not a router. Just
because it can support L2 routing, doesn't make it a router.

I'm all for discussing ideas and suggestions and working towards proper
IPv6 deployment. It certainly appears to be the case that the community
does not support your proposed "EzIP" solution. If you are recommending
that 240/4 space be used for CGNAT space under RFC6598, then call it as it
is instead of inventing new terminology.

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 03:27, Abraham Y. Chen  wrote:

> Hi, Christopher:
>
> 1)" Hang on... So EzIP is now about using 240/4 as CGNAT space? Wait,
> I'm lost...   ":
>
> Correct. This is one way to visualize the EzIP deployment. This
> configuration is so far the most concise manner to describe the the EzIP
> building block, RAN (Regional Area Network). The nice thing about this
> approach is that everything exists and is already working daily in each
> CG-NAT cluster. All needed to expand its capability is a larger netblock.
> Since 240/4 is fundamentally not an outlier in the overall IPv4 address
> pool, except being classified as "Reserved" for a long time, enabling it to
> work in a CG-NAT should not be any big challenge.
> 2)"   ... There is no such thing as "semi-private" space in the world
> of CGNAT, ... ":
>
> Correct. However, not distinguishing 100.64/10 netblock from the
> common public and private parts of the IPv4 space made it vague as which
> function does it provide. That is, in terms of re-usability for each
> isolated geographical area, it is like another RFC1918 private netblock. On
> the other hand, CG-NAT is clearly used in geographically public areas. So,
> 100.64/10 should be classified as "public". In addition, 100.64/10 is
> listed according to "IANA IPv4 Address Space Registry" as part of the 100/8
> netblock under ARIN, but now used by everyone worldwide. To avoid similar
> ambiguity that leads to confusions, we decided to call 240/4 as
> "semi-public" to more explicitly convey the concept. (Actually, we
> initially called 240/4 "semi-private" thinking that it could be the fourth
> RFC1918 netblock, until we realized that the RFC6589 environment was a much
> better fit.)
>
> 3)" Your "solution" to residential gateways not supporting the use of
> 240/4 space being upgraded to OpenWrt won't work, because not all CPE
> supports OpenWrt.   ":
>
> OpenWrt is just an open source RG code that can replace that in
> commercial RGs that have been supporting CPEs. Like the EzIP concept, 

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Christopher Hawker]

You most certainly can, it's called a VPN. One side initiates a connection
to the other.

;)

Regards,
Christopher Hawker

On Tue, 16 Jan 2024 at 07:21, Abraham Y. Chen  wrote:

> Hi, Forrest:
>
> 1)I have a question:
>
> If I subscribe to IPv6, can I contact another similar subscriber to
> communicate (voice and data) directly between two homes in private like the
> dial-up modem operations in the PSTN? If so, is it available anywhere right
> now?
>
> Regards,
>
>
> Abe (2024-01-15 15:20)
>
>
> Let me start with I think we're largely on the same page here.
>
> The transition I see happening next is that the consumer traffic largely
> moves to IPv6 with no CG-NAT.  That is, if you're at home or on your phone
> watching video or doing social media or using whatever app is all the rage
> it's going to be over IPv6.
>
> My point was largely that I believe that at some point the big consumer
> (not business) focused companies are going to realize they can use market
> forces to encourage the remaining IPv4-only eyeball networks to transition
> to support IPv6 connections from their customers.  I don't know if the
> timeframe is next year or 20 years from now,  but I do know the tech
> companies are very good at looking at the costs of maintaining backwards
> compatibility with old tech and figuring out ways to shed those costs when
> they no longer make sense.  If they can utilize various forms of pressure
> to make this happen quicker, I fully expect them to do so.
>
> Inside a business network,  or even at home,  it wouldn't surprise me if
> we're both long gone before IPv4 is eradicated.   I know there is going to
> be a lot of IPv4 in my network for years to come just because of product
> lifecycles.
>
> As far as "CG-NAT-like" technologies go (meaning NAT in a provider's
> network), they're unfortunately going to be with us for a long time since
> customers seem to want to be able to reach everything regardless of the
> IPv4 or IPv6 status of the customer or endpoint.   I also expect that most
> service providers with business customers are going to be carrying both
> IPv4 and IPv6 for a long time, not to mention doing a fair bit of
> translation in both directions.
>
> I won't go deeply into the whole IPv4 vs IPv6 discussion for a business
> customer's "public address" because the topic is far too nuanced for an
> email to cover them accurately.   Suffice it to say that I don't disagree
> that business today largely wants IPv4, but some seem to be becoming aware
> of what IPv6 can do and are looking to have both options available to them,
> at least outside the firewall.
>
> On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara  wrote:
>
>> Ok you've triggered me on your point 2.  I'll address the elephant in the
>> room.
>>
>> IPv4 is never ever going away.
>>
>> Right now consumer services are mostly (mobile, wireless, landline, wide
>> generalization) are IPv6 capable.  Most consumer applications are ipv6
>> capable, Google, Facebook, etc.There is light at the very end of the tunnel
>> that suggests that one day we won't have to deploy CGNAT444 for our
>> consumers to get to content, we may only have to do NAT64 for them to get
>> to the remaining Ipv4 Internet.  We're still working hard on removing our
>> reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a
>> long way off, but it's coming.
>>
>> Here's the current problem.  Enterprise doesn't need ipv6 or want ipv6.
>> You might be able to get away with giving CGNAT to your consumers, but your
>> enterprise customer will not accept this. How will they terminate their
>> remote users?  How will they do B2B with out inbound NAT?  Yes, there are
>> solutions, but if you don't need to, why?  They pay good money, why can't
>> they have real ipv4?  All their internal networks are IPv4 rfc1918.  They
>> are happy with NAT.  Their application service providers are ipv4
>> only. Looking at the services I access for work things like SAP,
>> SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many
>> more, none can not be accessed on ipv6 alone..  Their internal network
>> lifecycle is 10+ years.  They have no interest in trying new things or
>> making new technology work without a solid financial reason and there is
>> none for them implementing ipv6.   And guess where all the IP addresses
>> we're getting back from our consumers are going?  Straight to our good
>> margin enterprise customers and their application service providers.
>> 

Re: IPv6 Traffic Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

I strongly disagree that IPv6 is very much an afterthought.

A perfect example is that in Australia, our largest mobile network provider
Telstra, has completely moved to IPv6 single-stack on their mobile network
for pre-paid and post-paid customers. Russell Langton made the announcement
in February 2020 that Telstra was making the transition and they have since
completed this transition. T-Mobile US also went single-stack back in 2014.
India, with a population of 1.43 billion people (accounting for 17% of the
world's population, sits at 81.24% capable, 80.71% preferred.

With a global rate of 36.49% IPv6 capable and 35.61% IPv6 preferred, we
still have a long way to go however our current achievements to-date should
be commended.

Regards,
Christopher Hawker

Links:
https://lists.ausnog.net/pipermail/ausnog/2020-February/043869.html
https://www.internetsociety.org/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/
https://stats.labs.apnic.net/ipv6

On Mon, 15 Jan 2024 at 20:09, Saku Ytti  wrote:

> On Mon, 15 Jan 2024 at 10:59, jordi.palet--- via NANOG 
> wrote:
>
> > No, I’m not saying that. I’m saying "in actual deployments", which
> doesn’t mean that everyone is deploying, we are missing many ISPs, we are
> missing many enterprises.
>
> Because of low entropy of A-B pairs in bps volume, seeing massive
> amounts of IPv6 in IPv6 enabled networks is not indicative of IPv6
> success. I don't disagree with your assertion, I just think it's
> damaging, because readers without context will form an idea that
> things are going smoothly.  We should rightly be in panic mode and
> forget all the IPv4 extension crap and start thinking how do we ensure
> IPv6 happens and how do we ensure we get back to single stack
> Internet.
>
> IPv6 is very much an afterthought, a 2nd class citizen today. You can
> deploy new features and software without IPv6, and it's fine. IPv6 can
> be broken, and it's not an all-hands-on-deck problem, no one is
> calling.
>
> --
>   ++ytti
>

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

To my knowledge IPv6 is designed to replace IPv4. Anyone, feel free to
correct me if I'm wrong. There are just short of 4.3 billion IPv4
addresses, where the number of IPv6 addresses is 39 digits long.

Regards,
Christopher Hawker

On Mon, 15 Jan 2024 at 15:18, Abraham Y. Chen  wrote:

> Hi, Randy:
>
> 1)   " ... unfortunately i already had grey hair in the '90s and was in
> the room for all this,  ...  ":
>
> My apologies! For an uninitiated, I misread your message as if IPv6
> was originally designed with a plan to assure smooth transition from IPv4.
>
> Regards,
>
>
> Abe (2024-01-14 23:17)
>
>
> On 2024-01-12 17:45, Randy Bush wrote:
>
> Perhaps you are too young to realize that the original IPv6 plan was
> not designed to be backward compatible to IPv4, and Dual-Stack was
> developed (through some iterations) to bridge the transition between
> IPv4 and IPv6? You may want to spend a few moments to read some
> history on this.
>
> ROFL!!!  if there is anything you can do to make me that young, you
> could have a very lucrative career outside of the internet.
>
> hint: unfortunately i already had grey hair in the '90s and was in the
> room for all this, and spent a few decades managing to get some of the
> worst stupidities (TLA, NLA, ...) pulled out of the spec.  at iij, we
> rolled ipv6 on the backbone in 1997.
>
> randy
>
>
>
>
> <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_854094815002427858_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

Hang on... So EzIP is now about using 240/4 as CGNAT space? Wait, I'm
lost...

With CGNAT, there is either public IP space in front of the gateway, or
private space behind it. There is no such thing as "semi-private" space in
the world of CGNAT, as devices with public IPs can't directly access
devices behind a CGNAT gateway with a 100.64/10 address. It's either a
public address, or a private address (not to be confused with an RFC1918
private address).

Let's talk hypothetically for a minute and assume that 240/4 is used as
CGNAT space. Your "solution" to residential gateways not supporting the use
of 240/4 space being upgraded to OpenWRT won't work, because not all CPE
supports OpenWRT.

Instead of attempting to use a larger prefix for CGNAT, IPv6 is definitely
the easier solution to implement as the vast majority of vendors already
support v6.

Regards,
Christopher Hawker

On Mon, 15 Jan 2024 at 15:06, Abraham Y. Chen  wrote:

> Hi, Mike:
>
> 1)   "... only private use. ...":
>
> The EzIP deployment plan is to use 240/4 netblock as "Semi-Public"
> addresses for the existing CG-NAT facility. With many RG-NATs (Routing /
> Residential Gateway -NATs) already capable of being 240/4 clients thru the
> upgrade to OpenWrt, no IoT on any private premises will sense any change.
>
> Regards,
>
>
> Abe (2024-01-14 23:04)
>
>
> On 2024-01-12 15:16, Mike Hammett wrote:
>
> I'm not talking about global, public use, only private use.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions <http://www.ics-il.com/>
> <https://www.facebook.com/ICSIL>
> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
> <https://www.linkedin.com/company/intelligent-computing-solutions>
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> --
> *From: *"Tom Beecher"  
> *To: *"Mike Hammett"  
> *Cc: *"Ryan Hamel"  , "Abraham Y.
> Chen"  , nanog@nanog.org
> *Sent: *Friday, January 12, 2024 2:06:32 PM
> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
> address block
>
> You don't need everything in the world to support it, just the things
>> "you" use.
>
>
> You run an ISP, let me posit something.
>
> Stipulate your entire network infra, services, and applications support
> 240/4, and that it's approved for global , public use tomorrow. Some
> company gets a block in there, stands up some website. Here are some
> absolutely plausible scenarios that you might have to deal with.
>
> - Some of your customers are running operating systems / network gear that
> doesn't support 240/4.
> - Some of your customers may be using 3rd party DNS resolvers that don't
> support 240/4.
> - Some network in between you and the dest missed a few bogon ACLs ,
> dropping your customer's traffic.
>
> All of this becomes support issues you have to deal with.
>
> On Fri, Jan 12, 2024 at 2:21 PM Mike Hammett  wrote:
>
>> I wouldn't say it's unknowable, just that no one with a sufficient enough
>> interest in the cause has been loud enough with the research they've done,
>> assuming some research has been done..
>>
>> You don't need everything in the world to support it, just the things
>> "you" use.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions <http://www.ics-il.com/>
>> <https://www.facebook.com/ICSIL>
>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
>> <https://www.linkedin.com/company/intelligent-computing-solutions>
>> <https://twitter.com/ICSIL>
>> Midwest Internet Exchange <http://www.midwest-ix.com/>
>> <https://www.facebook.com/mdwestix>
>> <https://www.linkedin.com/company/midwest-internet-exchange>
>> <https://twitter.com/mdwestix>
>> The Brothers WISP <http://www.thebrotherswisp.com/>
>> <https://www.facebook.com/thebrotherswisp>
>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>> --
>> *From: *"Tom Beecher" 
>> *To: *"Mike Hammett" 
>> *Cc: *"Ryan Hamel" , "Abraham Y. Che

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Christopher Hawker]

Bryan:

> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
should work per the RFC appendix.

Actually, no it's not. RFC5322 reads: "This specification is not intended
to dictate ... any of the characteristics of user interface programs that
create or read messages".

5822 has not been issued, see https://www.rfc-editor.org/info/rfc5822.

Abraham:

> For more than one year, I have been accused of breaking the eMail
etiquette established by a standard, yet identified.

If multiple people have been asking you for over a year to not change
subject headings on emails, does this not indicate a bigger issue regarding
your mailing list etiquette? The fact that it continues indicates a
complete disregard. I cannot think of one technical reason to include a
manual timestamp in a subject line (such as your 202401102221.AYC).

> If we have trouble to keep our communication tool's framework solid, we
will be spending needless extra resources on technical discussions. This is
not productive.

One person changing the subject line of a mailing list thread every few
emails for their own benefit, and no one else, is not productive. There is
nothing wrong with MUAs currently in use. A user adapts to the MUA, not the
other way around.

> Obviously, I am just barely able to read the exchanges on this thread due
to so many terminologies that I have never heard of.

If a number of people on a mailing list were using terminologies that I
didn't understand, I would:
1. Listen to and understand what they are saying.
2. Contact them off-list and ask for clarification.
3. Heed their advice.

Regards,
Christopher Hawker

On Mon, 15 Jan 2024 at 00:12, Abraham Y. Chen  wrote:

> Hi, Bryan:
>
> 1)"  ...  Gmail is therefore in violation of the RFC5822. ...  I
> think it's quite unreasonable to expect others to compensate for an MUA which
> doesn't implement 25+ year old standards properly. ...  ":
>
> I am so glad that you decided to come out to be a well-informed
> referee. For more than one year, I have been accused of breaking the eMail
> etiquette established by a standard, yet never identified. It seriously
> distracted our attention from the topic of essence. You now have
> demonstrated that the reverse appears to be the case. What a big surprise!
>
> 2)If we have trouble to keep our communication tool's framework solid,
> we will be spending needless extra resources on technical discussions. This
> is not productive.
>
> 3)Obviously, I am just barely able to read the exchanges on this
> thread due to so many terminologies that I have never heard of. I shall
> remain silent on this thread from now on, awaiting for you to lead us out
> of this puzzlement.
>
> Sincerely and Best Regards,
>
>
> Abe (2024-01-14 08:11 EST)
>
>
>
> On 2024-01-14 03:53, Bryan Fields wrote:
>
> On 1/14/24 1:01 AM, William Herrin wrote:
>
> Respectfully, your MUA is not the only MUA. Others work differently.
>
> Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even the
> zimbra web interface.  All follow and implement RFC5822 as it pertains to
> threading.
>
> Note, threading works fine in the list archives too, but only displays two
> levels deep.
>
>
> GMail, for example, follows the message IDs as you say but assumes
> that if you change the subject line in your reply (more than adding
> "Re:") then you intend to start a new thread from that point in the
> discussion. It groups messages accordingly.
>
> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
> should work per the RFC appendix.
>
>
> This is not an unreasonable expectation: if you merely want to
> continue the current conversation without going off on a new tangent
> then there's no need for a different subject line.
>
> I think it's quite unreasonable to expect others to compensate for an MUA
> which doesn't implement 25+ year old standards properly.
>
>
>
>
> <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_4325909844379148972_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: IPv4 address block

[Christopher Hawker]

> at least in the ripe ncc service region, all this proved was that if the
> cost of registering a company (or LIR) and applying for an allocation
> was lower than the market rate of ipv4 addresses, then people would do
that.

Funny you say that, I had the same discussion with someone yesterday. It
wouldn't be hard from a PDP perspective to implement a policy that
prohibits companies from the same corporate group from applying for
allocations to ensure a fair distribution for new members, so for example
if two LLCs had the same owners/directors (forgive the terminology) both
LLCs could not both hold resources, it'd be one or the other.

Going back to allocation rates...

After looking at the APNIC Resource Explorer (https://rex.apnic.net/) since
policy "prop-127: Change maximum delegation size of 103/8 IPv4 address pool
to a /23" was implemented, there have been on average (the equivalent of)
1834 x /23 prefixes delegated per-year, from 09 May 2019 to 08 May 2024.
I've averaged the future delegation rates from 09 January to 08 May based
on the prior 8 months. Looking at the equivalent number of /23 prefixes in
3 x /8 prefixes, this calculates to quite a substantial 98,304 x /23
prefixes in 3 x /8 which would last ~50 years based on delegation rates in
the APNIC region. Even if we were to reserve 10% of that pool, that would
still give us a timeframe of about 48 years. Want to increase the maximum
delegation to a /22 and retrospectively apply it to those who could only
apply for a /23? Still gives us just under 22 years.

A substantial amount of time.

Regards,
Christopher Hawker

P.S. All the figures above are based on the 5 RIRs getting an equal
distribution of 3 x /8 prefixes. LACNIC and AFRINIC may (as an example)
only receive 1x or 2x /8 prefixes due to their service region sizes with
the balance distributed between ARIN, RIPE NCC and APNIC. This again, would
affect figures and is difficult to forecast.

On Sun, 14 Jan 2024 at 01:39, Nick Hilliard  wrote:

> Matthew Petach wrote on 13/01/2024 00:27:
> > In light of that, I strongly suspect that a second go-around at
> > developing more beneficial post-exhaustion policies might turn out
> > very differently than it did when many of us were naively thinking
> > we understood how people would behave in a post-exhaustion world.
>
> Naah, any future relitigation would end up the same if new ipv4
> addresses fell out of the sky and became available. The ipv4 address
> market turned out exactly like most people suspected: it was a market;
> people bought and sold addresses; the addresses cost money; there
> were/are some sharks; life moved on.
>
> > If you limit each requesting organization to a /22 per year, we can
> > keep the internet mostly functional for decades to come,
>
> at least in the ripe ncc service region, all this proved was that if the
> cost of registering a company (or LIR) and applying for an allocation
> was lower than the market rate of ipv4 addresses, then people would do
> that.
>
> The root problem is unavoidable: ipv4 is a scarce resource with an
> inherent demand. Every policy designed to mitigate against this will
> create workarounds, and the more valuable the resource, the more
> inventive the workaround.
>
> In terms of hard landings vs soft landings, what will make ipv6 succeed
> is how compelling ipv6 is, rather than whether someone created a policy
> to make ipv4 less palatable. In particular, any effect from a hard
> landing compared would have been ephemeral.
>
> Nick
>

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Christopher Hawker]

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  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  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> 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  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: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

Wow... There is some serious learning about the internet to be done here!

When Randy was deploying IPv6 across the IIJ backbone, I was running around
in kindergarten. I didn't even know what the internet was back then.

Amazing what can happen in 26 years...

Regards,
Christopher Hawker

On Sat, 13 Jan 2024 at 09:35, Abraham Y. Chen  wrote:

> Hi, Randy:
>
> 1)" ... dual-stack mess ...   it was intended. it was the original
> transition plan. ":
>
> Perhaps you are too young to realize that the original IPv6 plan was
> not designed to be backward compatible to IPv4, and Dual-Stack was
> developed (through some iterations) to bridge the transition between IPv4
> and IPv6? You may want to spend a few moments to read some history on this.
>
>
> Regards,
>
>
> Abe (2024-01-12 17:34)
>
>
>
> On 2024-01-12 00:11, Randy Bush wrote:
>
> We don't need to extend IPv4, we need to figure out why we are in this
> dual-stack mess, which was never intended, and how to get out of it.
>
> it was intended.  it was the original transition plan.  like many things
> about ipv6, it could have been a bit better thought out.
>
> randy
>
>
>
>
> <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_-2764172948748324147_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Streamline the CG-NAT Re: 202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

"Source NAT changes the source address in IP header of a packet. It may
also change the source port in the TCP/UDP headers. The typical usage is to
change the a private (rfc1918) address/port into a public address/port for
packets leaving your network."

"Destination NAT changes the destination address in IP header of a packet.
It may also change the destination port in the TCP/UDP headers.The typical
usage of this is to redirect incoming packets with a destination of a
public address/port to a private IP address/port inside your network."

Source:
https://serverfault.com/questions/119365/what-is-the-difference-between-a-source-nat-destination-nat-and-masquerading

Regards,
Christopher Hawker

On Fri, 12 Jan 2024 at 23:17, Abraham Y. Chen  wrote:

> Hi, Christopher:
>
> 1)   "  destination/source NAT  ":
>
> I am not sure about this terminology. Could you please elaborate? If
> you are referring EzIP being a bigger CG-NAT, it is exactly correct. That
> is, the first step of EzIP implementation is just to give CG-NAT a larger
> netblock to work with, so that the chore of dynamic address assignment to
> the client may be avoided.
>
> Regards,
>
> Abe (2024-01-12 07:16)
>
>
>
> On 2024-01-11 22:46, Christopher Hawker wrote:
>
> Not going to lie, EzIP just seems to be some version of destination/source
> NAT on steroids.
>
> Regards,
> Christopher Hawker
>
> On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen  wrote:
>
>> Hi, Forrest:
>>
>> 0)Thanks for your in-depth analysis.
>>
>> 1) However, my apologies for not presenting the EzIP concept clearer.
>> That is, one way to look at the EzIP scheme is to substitute the current
>> 100.64/10  netblock in the CG-NAT with 240/4. Everything else in the
>> current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64
>> fold bigger. And, various capabilities become available.
>>
>> Regards,
>>
>> Abe (2024-01-11 22:35)
>>
>>
>>
>> On 2024-01-11 02:02, Forrest Christian (List Account) wrote:
>>
>> I shouldn't probably go down this path... as I know this has been
>> discussed but I'm hoping that this might make a difference.
>>
>> Abraham,
>>
>> Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT
>> box between the 240/4 addressed devices and the non-EzIP internet.  That
>> NAT box will have to remain in place until such time as every single
>> publically addressed device on the public internet has been updated to
>> support EzIP.  In addition, protocols such as DNS, SIP, and others which
>> pass around addresses will need to be updated to be able to pass the full
>> EzIP addressing around so endpoints can properly insert the EzIP header,
>> and so on.
>>
>> The point I'm trying to make is that, at this point, deploying EzIP as an
>> end to end address exhaustion solution has MORE challenges that simply
>> deploying IPv6 would.  This is because, just like EzIP, deploying IPv6
>> requires a NAT box of some sort to be put in place until the last IPv4
>> device is turned off.   But unlike EzIP, almost every new device coming out
>> supports IPv6 out of the box.   All of the technical standards work has
>> already been done.   Thus, the only meaningful barrier to IPv6 at this
>> point is convincing people to use it, not convincing people to use it PLUS
>> convincing the tech companies to support it,  and doing protocol changes
>> like you would with EzIP.
>>
>> I applaud your attempt at a unique solution but I really feel that ship
>> has sailed, at least for an EzIP type of solution. Maybe something like
>> this would have better received years ago, but at this point IPv6 is a much
>> more logical path forward.
>>
>> I do wonder,  however,  if some of your concepts might be able to be
>> applied to the IPv6 transition.  I have some ideas here,  but most, if not
>> all, of them are only partially cooked but some have similar approaches as
>> EzIP but with an actual IPv6 packet inside.
>>
>>
>>
>>
>>
>>>
>>> <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_7003280393758044796_m_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>
>>
>

Re: Reusable 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

Yes, my suggestion wasn't to permit 240/4 for use in EzIP, rather it was
for it to be reclassified as Unicast (instead of Reserved) space for
delegations by RIRs to members.

100.64/10 will never go back into the free pool, it's too heavily
integrated into CG-NATted networks. The technical involvement for global
networks to renumber makes this impossible. It's akin to recalling
192.168/16 RFC1918 space.

Regards,
Christopher Hawker

On Fri, 12 Jan 2024 at 15:40, Abraham Y. Chen  wrote:

> Hi, Christopher:
>
> 1)" ... I would like to see 240/4 reclassified as unicast space ...
> ":
>
> We are in agreement with this first part.
>
> 2)" ... 2 x /8s delegated to each RIR with the /8s for AFRINIC ...   ":
>
> This second part is not what EzIP is proposing, because it will run
> into the old trap of "quickly used up". Instead, 240/4 should be used to
> replace 100.64/10 in creating RANs (Regional Area Networks) that are the
> same as the existing CG-NAT clusters but 64 fold bigger. So that 240/4 is
> reused worldwide like the RFC6598 netblocks, plus other possible benefits
> such as putting 100.64/10 back into the allocatable pool (Wasn't this
> pulled out of ARIN for worldwide use?) doing so, we do not have 240/4
> exhaustion issue to consider.
>
> Regards,
>
> Abe (2024-01-11 23:40)
>
>
>
> On 2024-01-11 05:54, Christopher Hawker wrote:
>
> There really is no reason for 240/4 to remain "reserved". I share Dave's
> views, I would like to see 240/4 reclassified as unicast space and 2 x /8s
> delegated to each RIR with the /8s for AFRINIC to be held until their
> issues have been resolved.
>
> Reclassifying this space, would add 10+ years onto the free pool for each
> RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th
> of a /8 pool available for delegation, another 1/6th reserved.
> Reclassification would see available pool volumes return to pre-2010 levels.
>
> https://www.apnic.net/manage-ip/ipv4-exhaustion/
>
> In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast
> Extensions Project, a very strong case was presented to convert this space.
>
> https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html
>
> Regards,
> Christopher Hawker
>
> On Thu, 11 Jan 2024 at 20:40, Dave Taht  wrote:
>
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  wrote:
>> >>
>> >> There's a whole bunch of software out there that makes certain
>> >> assumptions about allowable ranges. That is, they've been compiled with
>> >> a header that defines ..
>> >
>> >
>> > Of course correct. It really depends on the vendor / software /
>> versions in an environment. A lot of vendors removed that years ago,
>> because frankly a lot of large networks have been using 240/4 as pseudo
>> RFC1918 for years. Others have worked with smaller vendors and open source
>> projects to do the same.
>> >
>> > It's consistently a topic in the debates about 240/4 reclassification.
>>
>> There's debates still? I gave up. After making 240/4 and 0/8 work
>> across all of linux and BSD and all the daemons besides bird (which
>> refused the patch , I took so much flack that I decided I would just
>> work on other things. So much of that flack was BS - like if you kill
>> the checks in the OS the world will end - that didn't happen. Linux
>> has had these two address ranges just work for over 5 years now.
>>
>> 240/4 is intensely routable and actually used in routers along hops
>> inside multiple networks today, but less so as a destination.
>>
>> I would really like, one day, to see it move from reserved to unicast
>> status, officially. I would have loved it if 0/8 was used by a space
>> RIR, behind CGNAT, for starters, but with a plan towards making it
>> routable. I am not holding my breath.
>>
>> The principal accomplishment of the whole unicast extensions project
>> was to save a nanosecond across all the servers in the world on every
>> packet by killing the useless 0/8 check. That patch paid for itself
>> the first weekend after that linux kernel deployed. It is the
>> simplest, most elegant, and most controversial patch I have ever
>> written.
>>
>> https://news.ycombinator.com/item?id=20430096
>>
>>
>> >
>> > On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <
>> i...@protected-networks.net> wrote:
>> >>
>> >> On 1/10/24 10:12, Tom Beecher wrote:
>> >> > Karim-
>> >> >
>> >

Re: Streamline the CG-NAT Re: 202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

Not going to lie, EzIP just seems to be some version of destination/source
NAT on steroids.

Regards,
Christopher Hawker

On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen  wrote:

> Hi, Forrest:
>
> 0)Thanks for your in-depth analysis.
>
> 1) However, my apologies for not presenting the EzIP concept clearer.
> That is, one way to look at the EzIP scheme is to substitute the current
> 100.64/10  netblock in the CG-NAT with 240/4. Everything else in the
> current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64
> fold bigger. And, various capabilities become available.
>
> Regards,
>
> Abe (2024-01-11 22:35)
>
>
>
> On 2024-01-11 02:02, Forrest Christian (List Account) wrote:
>
> I shouldn't probably go down this path... as I know this has been
> discussed but I'm hoping that this might make a difference.
>
> Abraham,
>
> Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT
> box between the 240/4 addressed devices and the non-EzIP internet.  That
> NAT box will have to remain in place until such time as every single
> publically addressed device on the public internet has been updated to
> support EzIP.  In addition, protocols such as DNS, SIP, and others which
> pass around addresses will need to be updated to be able to pass the full
> EzIP addressing around so endpoints can properly insert the EzIP header,
> and so on.
>
> The point I'm trying to make is that, at this point, deploying EzIP as an
> end to end address exhaustion solution has MORE challenges that simply
> deploying IPv6 would.  This is because, just like EzIP, deploying IPv6
> requires a NAT box of some sort to be put in place until the last IPv4
> device is turned off.   But unlike EzIP, almost every new device coming out
> supports IPv6 out of the box.   All of the technical standards work has
> already been done.   Thus, the only meaningful barrier to IPv6 at this
> point is convincing people to use it, not convincing people to use it PLUS
> convincing the tech companies to support it,  and doing protocol changes
> like you would with EzIP.
>
> I applaud your attempt at a unique solution but I really feel that ship
> has sailed, at least for an EzIP type of solution. Maybe something like
> this would have better received years ago, but at this point IPv6 is a much
> more logical path forward.
>
> I do wonder,  however,  if some of your concepts might be able to be
> applied to the IPv6 transition.  I have some ideas here,  but most, if not
> all, of them are only partially cooked but some have similar approaches as
> EzIP but with an actual IPv6 packet inside.
>
>
>
> On Wed, Jan 10, 2024, 7:11 PM Abraham Y. Chen  wrote:
>
>> Hi, Enno:
>>
>> 0)Thanks for your comments referring to historical efforts.
>>
>> 1)However, the "IPv4 Unicast Extension Project" that your paper cited
>> does not make any specific recommendation about how to utilize the 240/4
>> netblock uniformly across the entire Internet. Our proposal, EzIP outlines
>> a scheme that makes a clear use of the 240/4 by the general public,
>> basically discouraging disparate private usages. We were very much lost
>> with what has been going on with the 240/4 netblock, because there was no
>> information about who were using it for what. The RIPE-Lab report clarified
>> the fact that it has been fragmented due to unannounced activities by
>> multi-national conglomerates and likely nerds, while under the cover of
>> "Reserved for Future Use".
>>
>> 2)" As you state yourself this could be considered "unorthodox, if
>> not controversial". ... usually means 'breaks something' ":
>>
>> I am afraid that  you read into my diplomatic expression too far.
>>
>> A.The first step of the EzIP proposal is to enhance the CG-NAT by
>> providing it with a much larger netblock, as I presume that Karim is
>> looking for. Such process (disabling the program code that has been
>> disabling the use of 240/4) does not need any running code to prove it. To
>> be blunt, anyone who claims that this will be a real task only shows that
>> he does not know his own code.
>>
>> B.The second EzIP step is to utilize RFC791 for setting up
>> end-to-end links which the Internet has not been able to deliver. This is
>> because the current predominant CG-NAT based CDN business is a master-slave
>> model which does not support it. However, this capability is like
>> international postal or telephony services that are not daily needs for
>> everyone. So, it should be treated as a premium service that can be
>

Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

Hi Tom,

I'm not too sure I understand where the idea came from that 2 x /8 would
only last one year. APNIC received their final allocation of the 103/8
prefix from ICANN/IANA on 03 February 2011, and commenced delegating space
from the prefix on 18 April 2011. With the right policies in place, it can
be well and truly extended.

Looking at an APNIC Blog article authored by Guangliang Pan on 09 October
2023 (https://blog.apnic.net/2023/10/09/nearing-the-end-of-103-8/), as of
the time the article was written there were 121 available /24 prefixes from
the 103/8 pool still available. Not a great deal in the grand scheme of
things, however, it demonstrates that policy works in preserving what
finite resources we have left, and that a 2 x /8 will last a lot longer
than one year.

I could say the same, that 2 x /8 lasting a little more than a year is an
extremely remote and highly unlikely assumption. Bear in mind that APNIC
policy was changed 1/2 way through to drop 103/8 delegations from a /22 to
a /23. Based on this, 65,536 x /23 delegations can be made to new members
and as Peter said, if post-exhaustion policy is applied to 240/4 it'll go
an extremely long way.

Regards,
Christopher Hawker



On Fri, 12 Jan 2024 at 04:26, Tom Beecher  wrote:

> Christopher-
>
> Reclassifying this space, would add 10+ years onto the free pool for each
>> RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th
>> of a /8 pool available for delegation, another 1/6th reserved.
>> Reclassification would see available pool volumes return to pre-2010 levels.
>>
>
> Citing Nick Hilliard from another reply, this is an incorrect statement.
>
> on this point: prior to RIR depletion, the annual global run-rate on /8s
>> measured by IANA was ~13 per annum. So that suggests that 240/4 would
>> provide a little more than 1Y of consumption, assuming no demand
>> back-pressure, which seems an unlikely assumption.
>>
>
> I share Dave's views, I would like to see 240/4 reclassified as unicast
>> space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held
>> until their issues have been resolved.
>>
>
> This has been discussed at great length at IETF. The consensus on the
> question has been consistent for many years now; doing work to free up
> 12-ish months of space doesn't make much sense when IPv6 exists, along with
> plenty of transition/translation mechanisms. Unless someone is able to
> present new arguments that change the current consensus, it's not going to
> happen.
>
> On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker 
> wrote:
>
>> There really is no reason for 240/4 to remain "reserved". I share Dave's
>> views, I would like to see 240/4 reclassified as unicast space and 2 x /8s
>> delegated to each RIR with the /8s for AFRINIC to be held until their
>> issues have been resolved.
>>
>> Reclassifying this space, would add 10+ years onto the free pool for each
>> RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th
>> of a /8 pool available for delegation, another 1/6th reserved.
>> Reclassification would see available pool volumes return to pre-2010 levels.
>>
>> https://www.apnic.net/manage-ip/ipv4-exhaustion/
>>
>> In the IETF draft that was co-authored by Dave as part of the IPv4
>> Unicast Extensions Project, a very strong case was presented to convert
>> this space.
>>
>> https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html
>>
>> Regards,
>> Christopher Hawker
>>
>> On Thu, 11 Jan 2024 at 20:40, Dave Taht  wrote:
>>
>>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  wrote:
>>> >>
>>> >> There's a whole bunch of software out there that makes certain
>>> >> assumptions about allowable ranges. That is, they've been compiled
>>> with
>>> >> a header that defines ..
>>> >
>>> >
>>> > Of course correct. It really depends on the vendor / software /
>>> versions in an environment. A lot of vendors removed that years ago,
>>> because frankly a lot of large networks have been using 240/4 as pseudo
>>> RFC1918 for years. Others have worked with smaller vendors and open source
>>> projects to do the same.
>>> >
>>> > It's consistently a topic in the debates about 240/4 reclassification.
>>>
>>> There's debates still? I gave up. After making 240/4 and 0/8 work
>>> across all of linux and BSD and all the daemons besides bird (which
>>> refused the patch , I took so much flack that I decided I would just
>>> work on other things.

Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

There really is no reason for 240/4 to remain "reserved". I share Dave's
views, I would like to see 240/4 reclassified as unicast space and 2 x /8s
delegated to each RIR with the /8s for AFRINIC to be held until their
issues have been resolved.

Reclassifying this space, would add 10+ years onto the free pool for each
RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th
of a /8 pool available for delegation, another 1/6th reserved.
Reclassification would see available pool volumes return to pre-2010 levels.

https://www.apnic.net/manage-ip/ipv4-exhaustion/

In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast
Extensions Project, a very strong case was presented to convert this space.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

Regards,
Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht  wrote:

> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher  wrote:
> >>
> >> There's a whole bunch of software out there that makes certain
> >> assumptions about allowable ranges. That is, they've been compiled with
> >> a header that defines ..
> >
> >
> > Of course correct. It really depends on the vendor / software / versions
> in an environment. A lot of vendors removed that years ago, because frankly
> a lot of large networks have been using 240/4 as pseudo RFC1918 for years.
> Others have worked with smaller vendors and open source projects to do the
> same.
> >
> > It's consistently a topic in the debates about 240/4 reclassification.
>
> There's debates still? I gave up. After making 240/4 and 0/8 work
> across all of linux and BSD and all the daemons besides bird (which
> refused the patch , I took so much flack that I decided I would just
> work on other things. So much of that flack was BS - like if you kill
> the checks in the OS the world will end - that didn't happen. Linux
> has had these two address ranges just work for over 5 years now.
>
> 240/4 is intensely routable and actually used in routers along hops
> inside multiple networks today, but less so as a destination.
>
> I would really like, one day, to see it move from reserved to unicast
> status, officially. I would have loved it if 0/8 was used by a space
> RIR, behind CGNAT, for starters, but with a plan towards making it
> routable. I am not holding my breath.
>
> The principal accomplishment of the whole unicast extensions project
> was to save a nanosecond across all the servers in the world on every
> packet by killing the useless 0/8 check. That patch paid for itself
> the first weekend after that linux kernel deployed. It is the
> simplest, most elegant, and most controversial patch I have ever
> written.
>
> https://news.ycombinator.com/item?id=20430096
>
>
> >
> > On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <
> i...@protected-networks.net> wrote:
> >>
> >> On 1/10/24 10:12, Tom Beecher wrote:
> >> > Karim-
> >> >
> >> > Please be cautious about this advice, and understand the full context.
> >> >
> >> > 240/4 is still classified as RESERVED space. While you would certainly
> >> > be able to use it on internal networks if your equipment supports it,
> >> > you cannot use it as publicly routable space. There have been many
> >> > proposals over the years to reclassify 240/4, but that has not
> happened,
> >> > and is unlikely to at any point in the foreseeable future.
> >>
> >> While you may be able to get packets from point A to B in a private
> >> setting, using them might also be .. a challenge.
> >>
> >> There's a whole bunch of software out there that makes certain
> >> assumptions about allowable ranges. That is, they've been compiled with
> >> a header that defines ..
> >>
> >> #define IN_BADCLASS(i)  (((in_addr_t)(i) & 0xf000) == 0xf000)
> >>
> >> Michael
> >>
>
>
> --
> 40 years of net history, a couple songs:
> https://www.youtube.com/watch?v=D9RGX6QFm5E
> Dave Täht CSO, LibreQos
>

Re: IPv4 address block

[Christopher Hawker]

Hello,

I would suggest looking at IPv4.Global, they have quite a few blocks in a
number of sizes, available for purchase.

For pricing, take a look at https://auctions.ipv4.global/.

Regards,
Christopher Hawker

On Mon, 8 Jan 2024 at 14:48, KARIM MEKKAOUI  wrote:

> Hi Nanog Community
>
>
>
> Any idea please on the best way to buy IPv4 blocs and what is the price?
>
>
>
> Thank you
>
>
>
> KARIM
>
>
>

Re: Issue with Geolocation in Lasvegas

[Christopher Hawker]

As Peter and I have mentioned, you'll need to register a geofeed with
Google. An example can be downloaded from
https://isp.google.com/static/downloads/example-geo-feed.csv and registered
in the ISP Portal.

Having said that, it may be worthwhile checking-in with your internal IP
Network Operations team (if you don't have access to manage this). Being
Qualcomm, I'd imagine relationships with Google would already exist.

Regards,
Christopher H.

On Thu, 4 Jan 2024 at 18:28, Raja Sekhar Gullapalli 
wrote:

> Hi Christopher,
>
>
>
> It is used only in continental US & we also reported this issue to at
> n...@google.com.
>
>
>
> Any further info to be provided to resolve this issue.
>
>
>
> Regards,
>
> Raja
>
>
>
>
>
> *From:* Christopher Hawker 
> *Sent:* Thursday, January 4, 2024 12:54 PM
> *To:* Raja Sekhar Gullapalli 
> *Cc:* nanog@nanog.org
> *Subject:* Re: Issue with Geolocation in Lasvegas
>
>
>
> *WARNING:* This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
> Looks like (according to RDNS) it's a "global NAT" address. Is it only
> being used in the continental US, or other countries?
>
>
>
> If the former, check that geofeeds are correctly configured and registered
> with Google in their ISP Portal.
>
>
>
> If the latter, you're going to encounter issues.
>
>
>
> Regards,
>
> Christopher H.
>
>
>
> On Thu, 4 Jan 2024 at 18:14, Raja Sekhar Gullapalli via NANOG <
> nanog@nanog.org> wrote:
>
>
>
> Team,
>
>
>
> We are having issues in our lasvegas office & it shows geolocation in all
> browsers as Israel instead of US region when we access news.google.com in
> our PC.
>
>
>
> Our public ip is 129.46.96.20.
>
>
>
> Can you help to whom we can contact to resolve the issue.
>
>
>
>
>
> Regards,
>
> Raja
>
>
>
>
>
>

Re: Issue with Geolocation in Lasvegas

[Christopher Hawker]

Looks like (according to RDNS) it's a "global NAT" address. Is it only
being used in the continental US, or other countries?

If the former, check that geofeeds are correctly configured and registered
with Google in their ISP Portal.

If the latter, you're going to encounter issues.

Regards,
Christopher H.

On Thu, 4 Jan 2024 at 18:14, Raja Sekhar Gullapalli via NANOG <
nanog@nanog.org> wrote:

>
>
> Team,
>
>
>
> We are having issues in our lasvegas office & it shows geolocation in all
> browsers as Israel instead of US region when we access news.google.com in
> our PC.
>
>
>
> Our public ip is 129.46.96.20.
>
>
>
> Can you help to whom we can contact to resolve the issue.
>
>
>
>
>
> Regards,
>
> Raja
>
>
>
>
>

Re: Interesting Ali Express web server behavior...

[Christopher Hawker]

Starting to digress here for a minute...

How big would a network need to get, in order to come close to
exhausing RFC1918 address space? There are a total of 17,891,328 IP
addresses between the 10/8 prefix, 172.16/12 space and 192.168/16 space. If
one was to allocate 10 addresses to each host, that means it would require
1,789,132 hosts to exhaust the space.

- Christopher H.

On Sun, 10 Dec 2023 at 18:45, Sabri Berisha  wrote:

> - On Dec 9, 2023, at 9:55 PM, Owen DeLong via NANOG nanog@nanog.org
> wrote:
>
> Hi,
>
> > Location: http://33.3.37.57/
>
> > But why would AliExpress be redirecting to DDN space? Is this
> legitimate? Ali
> > hoping to get away with squatting, or something else?
>
> Not very long ago I worked for a well-known e-commerce platform where we
> nearly
> ran out of RFC1918 space. We seriously considered using what was then
> un-advertised DOD space to supplement RFC1918 space inside our data
> centers.
>
> Perhaps AliExpress did get to that level of desperateness?
>
> Thanks,
>
> Sabri
>

Re: CPE/NID options

[Christopher Hawker]

Hi Ross,

I've found these Mikrotik devices to be excellent and reliable:

CRS310-8G+2S+IN: 8 x 2.5G copper ethernet ports, 2 x SFP+ cages, 
rack-mountable. Uses a single DC barrel-jack. 
https://mikrotik.com/product/crs310_8g_2s_in
CRS305-1G-4S+IN: 4 x SFP+ cages, dual DC barrel-jack ports for redundant power, 
1 x 1G copper ethernet port for OOB management. 
https://mikrotik.com/product/crs305_1g_4s_in
CRS310-1G-5S-4S+OUT: 4 x SFP+ cages, 5 x SFP cages, 1 x 1G copper ethernet port 
for OOB management, can be mounted outdoors. 
https://mikrotik.com/product/netfiber_9

MSRP on all three are at or below $249.00 so are priced quite reasonably. If 
you only need SFP+ cages I'd opt for the CRS305-1G-4S+IN.

Regards,
Christopher Hawker



From: NANOG  on behalf of Ross 
Tajvar 
Sent: Thursday, November 23, 2023 3:41 PM
To: North American Network Operators' Group 
Subject: CPE/NID options

I'm evaluating CPEs for one of my clients, a regional ISP. Currently, we're 
terminating the customer's service (L3) on our upstream equipment and extending 
it over our own fiber to the customer's premise, where it lands in a Juniper 
EX2200 or EX2300.

At a previous job, I used Accedian's ANTs on the customer prem side. I like the 
ANT because it has a small footprint with only 2 ports, it's passively cooled, 
it's very simple to operate, it's controlled centrally, etc. Unfortunately, 
when I reached out to Accedian, they insisted that the controller (which is 
required) started at $30k, which is a non-starter for us.

I'm not aware of any other products like this. Does anyone have a 
recommendation for a simple L2* device to deploy to customer premises? Not 
necessarily the exact same thing, but something similarly-featured would be 
ideal.

*I'm not sure if the ANT is exactly "layer 2", but I don't know what else to 
call it.

Re: Outside plant - prewire customer demarc preference

[Christopher Hawker]

I can't speak for US standards, however, in Australia on the National Broadband 
Network the standard for lead-in conduit is P20 conduit (23mm inner diameter 
with 26.6mm to 26.8mm outer diameter). I imagine in the US it may be something 
similar.

Page 17 of 
https://www.nbnco.com.au/content/dam/nbn/documents/developers/newdevs/NBN-DES-STD-0011-Residential-Preparation-and-Installation-Single-Dwelling-Units-and-Multi-Dwelling-Units-13.0.pdf.coredownload.pdf.

Regards,
Christopher Hawker

From: NANOG  on behalf of Sean 
Donelan 
Sent: Thursday, November 23, 2023 4:35 AM
To: nanog@nanog.org 
Subject: Re: Outside plant - prewire customer demarc preference


For *only* $1,000, the builder is willing to pre-install a smurf tube from
the demarc to the central distribution point.  But such a deal for 5G

Since most fiber installs seem to use pre-connectorized cable, without
affecting building structure integrity (i.e. 2-inch is too big according
to builder), how small is too small?  Trade size 1/2-inch, 3/4-inch,
1-inch?

Does the FTTH industry have any published standards?


This is why I don't help friends troubleshoot PC printer problems :-)

Re: ipv6 address management - documentation

[Christopher Hawker]

One of the first things that comes to mind, is that if you were to breakout a 
/64 v6 subnet (a standard-issue subnet to a residential customer) in an Excel 
spreadsheet, the number of columns you would need is 14 digits long. You could 
breakout the equivalent of a /12 v4 in just one column. Understandably in the 
real world no one (in their right mind) would do this, this is just for 
comparison.

Regards,
Christopher H.

From: NANOG  on behalf of Owen 
DeLong via NANOG 
Sent: Friday, November 17, 2023 10:39 AM
To: Aaron Gould 
Cc: nanog@nanog.org 
Subject: Re: ipv6 address management - documentation

Spreadsheets are terrible for IPAM regardless of address length, but I am 
curious to know why you think IPv6 would be particularly worse than IPv4 in 
such a scenario?

Owen


> On Nov 16, 2023, at 10:02, Aaron Gould  wrote:
>
> For years I've used an MS Excel spreadsheet to manage my IPv4 addresses.  
> IPv6 is going to be maddening to manage in a spreadsheet.  What does everyone 
> use for their IPv6 address prefix management and documentation?  Are there 
> open source tools/apps for this?
>
> --
> -Aaron

Re: Your Input Needed: Can ROA Replace LOA? – Short Survey (7 mins)

[Christopher Hawker]

Hi Christopher and Tom,

I'll reply to you together, as they seem to be along the same lines.

For the purposes of this survey/research, a reference to an LOA is a reference 
to an LOA for the advertisement/filtering of IP space. I agree, the acronym LOA 
has multiple uses in the world of IT for things such as datacentre 
cross-connects, however given what we are looking into, I believe its quite 
clear that any references to an LOA is a reference to a Letter of Authorisation 
for the advertisement/filtering of IP space.

Other facility providers (such as Equinix, see 
https://docs.equinix.com/en-us/Content/Interconnection/DiLOA/xc-Loa.htm) have 
already started looking into the realm of digital LOAs for services such as 
cross-connects. While they are not the same as traditional LOAs, in my belief 
they are designed to reduce the timeframes in issuing them, having them sent 
across and completed.

Regards,
Christopher Hawker


From: Christopher Morrow 
Sent: Friday, November 17, 2023 3:18 AM
To: Tom Beecher 
Cc: Christopher Hawker ; nanog@nanog.org 
Subject: Re: Your Input Needed: Can ROA Replace LOA? – Short Survey (7 mins)

On Thu, Nov 16, 2023 at 10:22 AM Tom Beecher  wrote:
>>
>> In the service provider industry, its primary use is for advertising address 
>> resources (IPv4/v6 and ASN)
>
>
> Not really.



I would think there are a few uses of LOA in the telco/SP world, at least:

  1) 'can I make this cross-connect happen?'
  2) 'can I do some work on this link/path/fiber/conduit on behalf of
 where the entity to be worked on is 
infrastructure'
  3) 'Please accept this internet number resource from 
when the number resource is authorized for use by '

I would love to see ROA take over the 3rd of those, since it's a clear
indicator that:
  "RIR authorizes LIR to use , LIR authorizes
AS-OWNER to originate "

and by 'clear indicator' I mean: "has some cryptographic/PKI backing
you can follow to the RIR in an automated fashion"
Where 'LOA' generally is a xerox of a photocopy of a fax of a
dot-matrix printed MS-Word templated document which perhaps has an X
on the 'signature' line...

-chris

Your Input Needed: Can ROA Replace LOA? – Short Survey (7 mins)

[Christopher Hawker]

Hello everyone,

Aftab Siddiqui is currently exploring the possibility of using Route Object 
Authorisations (ROAs) as a potential replacement to LOAs. Separate to this (and 
unknowing of Aftab's research), I had started a discussion on the RPKI 
Community guild on Discord (https://discord.gg/9jYcqpbdRE) discussing the usage 
of ROAs instead of LOAs.

An LOA, or "Letter of Authority" / "Letter of Authorization," is a formal 
document granting permission for third parties to take specific actions 
regarding network resources or services. In the service provider industry, its 
primary use is for advertising address resources (IPv4/v6 and ASN). When an 
organization intends to announce its IP prefixes through its own or a transit 
provider's ASN to the global internet, it typically needs to provide an LOA to 
their transit provider, confirming their custodianship or ownership of the 
resources.

RPKI ROA, stands for "Resource Public Key Infrastructure Route Origin 
Authorization," is part of a security framework designed to validate the 
authenticity of internet routing information. It involves a digitally signed 
object that specifies which Autonomous Systems (ASes) are permitted to announce 
specific IP address prefixes.

Could you please take a moment to fill out our brief survey? Your feedback will 
play a crucial role in our understanding of this topic.

Survey Link: https://www.surveymonkey.com/r/JCHLWBB

Thanks,
Christopher Hawker