Mailing List Archive

Hey there Jay,

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

Regards,
Christopher Hawker
________________________________
From: NANOG <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of Jay R. Ashworth <jra@baylink.com>
Sent: Tuesday, February 13, 2024 5:19 PM
To: North American Operators' Group <nanog@nanog.org>
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 jra@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

The angst around ipv6 on hackernews that this triggered was pretty
revealing and worth thinking about independently.
https://news.ycombinator.com/item?id=39316266

In the tik world, people are struggling to deploy ipv6 as even linux
kernel 5.7 in routerOS 7.XX still has some needed missing features. It
also appears 240 ain´t working there, either. And routerOS is one of
the more up to date platforms.

if I could use the controversy to talk to why it has been so hard to
deploy ipv6 to the edge and how to fix that problem instead rather
than triggering people, it would be helpful.

...

I was inspired to try a couple traceroutes. It used to be 240 escaped
my prior comcast router and wandered around a while; it does not do
that anymore. I would be dryly amused if that box was actually running
my old OpenWrt bcp38 stuff which blocked 240 for a couple years. My
cloud works, my aws stack works, openwrt works.

My comcast ipv6 connection is LOVELY - ssh stays nailed up for days. I
still reflexively use mosh because it survives me moving from AP to
AP.

I do wish there was some way I could escape the painful policy debate
and just focus on the code-related problems. (my position is basically
that all new devices not waste cycles blocking the 240 and 0/8 ranges,
and merely it move it from reserved for bezos^H^H^H^H^Hfuture use to
unicast and recognize deployed reality).

Peering into a murky crystal ball, say, 5 years in the future:

Another thing that I worry about is port space exhaustion, which is
increasingly a thing on firewalls and CGNs. If I can distract you - in
this blog cloudflare attempted to cut the number of ipv4 addresses
they use from 2 to 1, after observing some major retry issues. With a
nice patch, reducing the problem.

https://blog.cloudflare.com/linux-transport-protocol-port-selection-performance/

Their problems remain the same if they also just use one ipv6 address
(which would be silly, of course). QUIC is going to make this worse.

In there, they mention udp-lite, but don´t mention that this protocol
has worked for over a decade, and has all this unallocated port space.
Firewalling and natting it is easy.

Peering further into the soi-distant decades ahead, perhaps we should
just allocate all the remaining protocol space in the IP header to a
quic native protocol, and start retiring the old ones.

/me hides

On Tue, Feb 13, 2024 at 1:21?AM Jay R. Ashworth <jra@baylink.com> wrote:
>
> 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 jra@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



--
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

----- Original Message -----
> From: "Dave Taht" <dave.taht@gmail.com>

> The angst around ipv6 on hackernews that this triggered was pretty
> revealing and worth thinking about independently.
> https://news.ycombinator.com/item?id=39316266

Thanks; the source where I got the other link mentioned that, and I meant
to include it...

> I was inspired to try a couple traceroutes. It used to be 240 escaped
> my prior comcast router and wandered around a while; it does not do
> that anymore. I would be dryly amused if that box was actually running
> my old OpenWrt bcp38 stuff which blocked 240 for a couple years. My
> cloud works, my aws stack works, openwrt works.

Damn; I haven't touched the bcp38 wiki in some time. Thanks for the reminder.

> Peering into a murky crystal ball, say, 5 years in the future:
>
> Another thing that I worry about is port space exhaustion, which is
> increasingly a thing on firewalls and CGNs. If I can distract you - in
> this blog cloudflare attempted to cut the number of ipv4 addresses
> they use from 2 to 1, after observing some major retry issues. With a
> nice patch, reducing the problem.
>
> https://blog.cloudflare.com/linux-transport-protocol-port-selection-performance/

Interesting. Isn't that something CGNAT implementers would have had to deal with
already?

> Peering further into the soi-distant decades ahead, perhaps we should
> just allocate all the remaining protocol space in the IP header to a
> quic native protocol, and start retiring the old ones.

Well, I've been able to avoid thinking about it for some time, but ISTR my
reaction to QUIC as violating a number of organized religions' blasphemy
rules...

> /me hides

Indeed.

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@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

On Tue, Feb 13, 2024 at 2:18?AM Jay R. Ashworth <jra@baylink.com> wrote:
>
> ----- Original Message -----
> > From: "Dave Taht" <dave.taht@gmail.com>
>
> > The angst around ipv6 on hackernews that this triggered was pretty
> > revealing and worth thinking about independently.
> > https://news.ycombinator.com/item?id=39316266
>
> Thanks; the source where I got the other link mentioned that, and I meant
> to include it...
>
> > I was inspired to try a couple traceroutes. It used to be 240 escaped
> > my prior comcast router and wandered around a while; it does not do
> > that anymore. I would be dryly amused if that box was actually running
> > my old OpenWrt bcp38 stuff which blocked 240 for a couple years. My
> > cloud works, my aws stack works, openwrt works.
>
> Damn; I haven't touched the bcp38 wiki in some time.

In what way do you plan to touch it?

> Thanks for the reminder.

The bcp38 code for OpenWrt was not updated in light of the nftables
switch, as of a few years ago, but I have not looked at it in a long
time. Maybe someone else fixed it. I have not been doing much
development.

As it is bcp38 needs to be applied carefully by an ISP given the
sordid mess of other rfc1918 addresses along the path nowadays.

I doubt it is a good idea for consumer devices anymore. I liked the
side-effects of running it then tho, stopping random worms for chewing
up my external bandwidth. (the code was not just bcp38 related)

A plug - that I have NO IDEA made it into other ipv6 implementations -
is that we put ipv6 source specific routing into the OpenWrt stack to
elegantly make bcp38-like behavior the default there, back in 2013.

ip route add :: from my:ipv6:address:ranges/mask dest:addr:of:your:choice.

And also made the idea work in babel and ISIS to help with poor man´s
multihoming.

Most distro kernels I have seen lately do not seem to support "from" anymore.

>
> > Peering into a murky crystal ball, say, 5 years in the future:
> >
> > Another thing that I worry about is port space exhaustion, which is
> > increasingly a thing on firewalls and CGNs. If I can distract you - in
> > this blog cloudflare attempted to cut the number of ipv4 addresses
> > they use from 2 to 1, after observing some major retry issues. With a
> > nice patch, reducing the problem.
> >
> > https://blog.cloudflare.com/linux-transport-protocol-port-selection-performance/
>
> Interesting. Isn't that something CGNAT implementers would have had to deal with
> already?

I do not know of a single CGNAT that gives an operator a report on syn
retries, and thus exhaustion is hidden by the native retry behaviors
of the host stacks. Is there one?

The cloudflare work seems helpful here.

>
> > Peering further into the soi-distant decades ahead, perhaps we should
> > just allocate all the remaining protocol space in the IP header to a
> > quic native protocol, and start retiring the old ones.
>
> Well, I've been able to avoid thinking about it for some time, but ISTR my
> reaction to QUIC as violating a number of organized religions' blasphemy
> rules...
>
> > /me hides
>
> Indeed.

I enjoy being offline ever the more, these days. The internet
addiction level out there has become rather depressing.

https://www.linkedin.com/feed/update/urn:li:activity:7162457657210044416/


>
> Cheers,
> -- jra
> --
> Jay R. Ashworth Baylink jra@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



--
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

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 <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of Jay R. Ashworth <jra@baylink.com>
Sent: Tuesday, February 13, 2024 5:19 PM
To: North American Operators' Group <nanog@nanog.org>
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 jra@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

>
> 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 <chris@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 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 <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of
> Jay R. Ashworth <jra@baylink.com>
> *Sent:* Tuesday, February 13, 2024 5:19 PM
> *To:* North American Operators' Group <nanog@nanog.org>
> *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
> jra@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
>

On 2/12/24 11:07 PM, Dave Taht wrote:
> if I could use the controversy to talk to why it has been so hard to
> deploy ipv6 to the edge and how to fix that problem instead rather
> than triggering people, it would be helpful.

1. My provider, AT&T, keeps saying "we don't support IPv6." I've
written about my years-long effort to get my web server to speak IPv6
over AT&T fiber. I finally broke through when I was forced to upgrade
to business service, and started receiving a better grade of technical
support.

2. I have a DNS AAAA record for my web server. Looking at yesterday's
access log for SSL, I've had exactly five (5) accesses from two IPv6
addresses. Earlier in the month, I found a couple of search engines
found the IPv6 side of the web server.

3. I cannot obtain a PTR record for IPv6, so the mail server is a no-go
because I won't be able to accomplish the minimum effort required for
major players to recognize my mail server as valid. My mail server is,
except for port 25, LAN only. Haven't run into any IPv6-only mail
servers, based on the logs.

4. My new IPv6-aware edge router firewall is in development. This
firewall, using NFT, will still NAT uplink IPv4 connections. It will not
forward new connections from WAN to LAN over a defined subnet of IPv6;
equipment on the LAN will be assigned IPv6 addresses from that subnet.
Frankly, I'm not fast-tracking this work because I don't feel blocked by
not having IPv6 connectivity.

It feels like IPv6 has Second Product Syndrome, where everything but the
kitchen sink was thrown into it.

Let me know when they support /31s.


On 2/13/24 08:07, Dave Taht wrote:
> And routerOS is one of
> the more up to date platforms.

On Tue, Feb 13, 2024 at 2:03?AM Christopher Hawker <chris@thesysadmin.au> 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
bill@herrin.us
https://bill.herrin.us/

That's very disappointing.

I acquired a Mikrotik L009 router to play with recently, and it's been one
let-down after another; now this.

--TimH

On Tue, 13 Feb 2024 17:04:45 +0100
Bryan Holloway <bryan@shout.net> wrote:

> Let me know when they support /31s.
>
>
> On 2/13/24 08:07, Dave Taht wrote:
> > And routerOS is one of
> > the more up to date platforms.

Tim,

How is that Mikrotik a let down?

Ryan

________________________________
From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Tim Howe <tim.h@bendtel.com>
Sent: Tuesday, February 13, 2024 12:04:50 PM
To: nanog@nanog.org <nanog@nanog.org>
Subject: Re: The Reg does 240/4

Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.


That's very disappointing.

I acquired a Mikrotik L009 router to play with recently, and it's been one
let-down after another; now this.

--TimH

On Tue, 13 Feb 2024 17:04:45 +0100
Bryan Holloway <bryan@shout.net> wrote:

> Let me know when they support /31s.
>
>
> On 2/13/24 08:07, Dave Taht wrote:
> > And routerOS is one of
> > the more up to date platforms.

On Tue, Feb 13, 2024 at 10:05?AM Bryan Holloway <bryan@shout.net> wrote:
> Let me know when they support /31s.

A /31 is configured in RouterOS as a point-to-point interface. You put
your IP in the "address" field and their IP in the "network" field.

That's how I've been doing it since I started using RouterOS in 2014.
I can't speak to versions that predate that.

HTH

So, just FYI, we just tested a /31 on Eth1 of the L009 and it
seems to work fine(?)

--TimH

On Tue, 13 Feb 2024 09:04:50 -0800
Tim Howe <tim.h@bendtel.com> wrote:

> That's very disappointing.
>
> I acquired a Mikrotik L009 router to play with recently, and it's been one
> let-down after another; now this.
>
> --TimH
>
> On Tue, 13 Feb 2024 17:04:45 +0100
> Bryan Holloway <bryan@shout.net> wrote:
>
> > Let me know when they support /31s.
> >
> >
> > On 2/13/24 08:07, Dave Taht wrote:
> > > And routerOS is one of
> > > the more up to date platforms.

Folks have been known to kludge around it, but it is not officially
supported by ROS, not even in v7. To wit:

https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview

Ping across? Sure. Ok. But I wouldn't rely on it for anything critical.

Caveat emptor.


On 2/13/24 18:43, Tim Howe wrote:
> So, just FYI, we just tested a /31 on Eth1 of the L009 and it
> seems to work fine(?)
>
> --TimH
>
> On Tue, 13 Feb 2024 09:04:50 -0800
> Tim Howe <tim.h@bendtel.com> wrote:
>
>> That's very disappointing.
>>
>> I acquired a Mikrotik L009 router to play with recently, and it's been one
>> let-down after another; now this.
>>
>> --TimH
>>
>> On Tue, 13 Feb 2024 17:04:45 +0100
>> Bryan Holloway <bryan@shout.net> wrote:
>>
>>> Let me know when they support /31s.
>>>
>>>
>>> On 2/13/24 08:07, Dave Taht wrote:
>>>> And routerOS is one of
>>>> the more up to date platforms.
>

That's disappointing.

Thanks for the info. What a strange thing to not support.

--TimH

On Tue, 13 Feb 2024 19:17:03 +0100
Bryan Holloway <bryan@shout.net> wrote:

> Folks have been known to kludge around it, but it is not officially
> supported by ROS, not even in v7. To wit:
>
> https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview
>
> Ping across? Sure. Ok. But I wouldn't rely on it for anything critical.
>
> Caveat emptor.
>
>
> On 2/13/24 18:43, Tim Howe wrote:
> > So, just FYI, we just tested a /31 on Eth1 of the L009 and it
> > seems to work fine(?)
> >
> > --TimH
> >
> > On Tue, 13 Feb 2024 09:04:50 -0800
> > Tim Howe <tim.h@bendtel.com> wrote:
> >
> >> That's very disappointing.
> >>
> >> I acquired a Mikrotik L009 router to play with recently, and it's been one
> >> let-down after another; now this.
> >>
> >> --TimH
> >>
> >> On Tue, 13 Feb 2024 17:04:45 +0100
> >> Bryan Holloway <bryan@shout.net> wrote:
> >>
> >>> Let me know when they support /31s.
> >>>
> >>>
> >>> On 2/13/24 08:07, Dave Taht wrote:
> >>>> And routerOS is one of
> >>>> the more up to date platforms.
> >

I use a CCR2004 at home as it's one of the only devices that could handle
the 4Gb/s XGS-PON on pppoe. I've got an IPoE GPON (1000/500) failover, v4/v6
dual stack everywhere, incoming vpn and ipsec tunnels to other MT's and it
run's great. The only problem I have run into is if you run the 10G ports at
2.5G the buffering is a complete bust, so I have had to put cheap
10G/2.5G/1G switches in between the MT and 2.5G clients to achieve proper
performance. Oh, and some custom cooling fans as it gets a bit noisy once
the 10GBASET SFP's heat things up.

-----Original Message-----
From: NANOG <nanog-bounces+tony=wicks.co.nz@nanog.org> On Behalf Of Tim Howe
Sent: Wednesday, February 14, 2024 6:05 AM
To: nanog@nanog.org
Subject: Re: The Reg does 240/4

That's very disappointing.

I acquired a Mikrotik L009 router to play with recently, and it's been one
let-down after another; now this.

--TimH

They support /31s and have for some time. The trick we found is that the Mikrotik has to be the higher numbered IP and network address has to be the lower

add address=x.x.x.61/31 interface=ether1-<ISPNAME>-dia network=x.x.x.60

Then point your default route at the lower numbered IP in the /31.


-richey


From: NANOG <nanog-bounces+richey.goldberg=gmail.com@nanog.org> on behalf of Bryan Holloway <bryan@shout.net>
Date: Tuesday, February 13, 2024 at 11:05 AM
To: NANOG list <nanog@nanog.org>
Subject: Re: The Reg does 240/4
Let me know when they support /31s.


On 2/13/24 08:07, Dave Taht wrote:
> And routerOS is one of
> the more up to date platforms.

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

Once upon a time, richey goldberg <richey.goldberg@gmail.com> said:
> They support /31s and have for some time. The trick we found is that the Mikrotik has to be the higher numbered IP and network address has to be the lower

I would not classify that as "support /31s" - that's "there's a
work-around that handles 50% of cases". Can you have two Mikrotiks
connected to each other with a /31? If not, they don't support using
/31s.

--
Chris Adams <cma@cmadams.net>

On Tue, Feb 13, 2024 at 12:17?PM Bryan Holloway <bryan@shout.net> wrote:
> https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview
>
> Ping across? Sure. Ok. But I wouldn't rely on it for anything critical.

Well that's certainly interesting.
You will not see me sticking up for MikroTik's documentation, ever. I
don't think the table reflects the reality of ROS 7, there's even a
note that "Routed traffic does not work to odd address" in one
version. I know that to be false, because, well, I do this in
production, and I suspect I would have noticed if the niche
functionality of "routing" suddenly stopped working.

Maybe this document refers to the literal configuration of a /31. But
I always configure them as point to points, as I mentioned before. But
there again, in the documentation, that ability is totally missing...
great.

--
Hunter Fuller (they)
Router Jockey
VBH M-1C
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

On 2/13/24 21:47, Hunter Fuller wrote:
> On Tue, Feb 13, 2024 at 12:17?PM Bryan Holloway <bryan@shout.net> wrote:
>> https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview
>>
>> Ping across? Sure. Ok. But I wouldn't rely on it for anything critical.
>
> Well that's certainly interesting.
> You will not see me sticking up for MikroTik's documentation, ever. I
> don't think the table reflects the reality of ROS 7, there's even a
> note that "Routed traffic does not work to odd address" in one
> version. I know that to be false, because, well, I do this in
> production, and I suspect I would have noticed if the niche
> functionality of "routing" suddenly stopped working.
>
> Maybe this document refers to the literal configuration of a /31. But
> I always configure them as point to points, as I mentioned before. But
> there again, in the documentation, that ability is totally missing...
> great.

I would 100% concur that Mikrotik documentation can be spotty.

That said, what you choose to do on your network is of course totally up
to you.

Personally, I would not use MikroTik's /31 implementation in mine.

It appears that Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> 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.

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

Intense optimism detected!

On Tue, Feb 13, 2024 at 4:27?PM John Levine <johnl@iecc.com> wrote:

> It appears that Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> 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.
>
>
>
>

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 <beecher@beecher.cc>
Sent: Wednesday, February 14, 2024 1:23 AM
To: Christopher Hawker <chris@thesysadmin.au>
Cc: North American Operators' Group <nanog@nanog.org>; ausnog@lists.ausnog.net <ausnog@lists.ausnog.net>; Christopher Hawker via sanog <sanog@sanog.org>; apnic-talk@lists.apnic.net <apnic-talk@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 <chris@thesysadmin.au<mailto:chris@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 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 <nanog-bounces+chris=thesysadmin.au@nanog.org<mailto:thesysadmin.au@nanog.org>> on behalf of Jay R. Ashworth <jra@baylink.com<mailto:jra@baylink.com>>
Sent: Tuesday, February 13, 2024 5:19 PM
To: North American Operators' Group <nanog@nanog.org<mailto:nanog@nanog.org>>
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 jra@baylink.com<mailto:jra@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