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
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-performa... 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-performa...
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-performa...
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
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.
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.
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.
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.
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
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
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.
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>
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
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
Christopher, On Feb 13, 2024, at 2:15 PM, Christopher Hawker <chris@thesysadmin.au> 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.
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 <drc@virtualized.org> Sent: Wednesday, February 14, 2024 10:24 AM To: Christopher Hawker <chris@thesysadmin.au> Cc: North American Operators' Group <nanog@nanog.org> Subject: Re: The Reg does 240/4 Christopher, On Feb 13, 2024, at 2:15 PM, Christopher Hawker <chris@thesysadmin.au> 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.
Christopher, On Feb 13, 2024, at 4:14 PM, Christopher Hawker <chris@thesysadmin.au> 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
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 <drc@virtualized.org> Sent: Wednesday, February 14, 2024 1:03 PM To: Christopher Hawker <chris@thesysadmin.au> Cc: North American Operators' Group <nanog@nanog.org> Subject: Re: The Reg does 240/4 Christopher, On Feb 13, 2024, at 4:14 PM, Christopher Hawker <chris@thesysadmin.au> 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
Allocating 240/4 only temporarily drives down pricing until it's all assigned, then we're all back at square one. Ya know what does not put us back square one, nor waste our time? Implementing IPv6. Ryan Hamel ________________________________ From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Christopher Hawker <chris@thesysadmin.au> Sent: Wednesday, February 14, 2024 4:49 AM To: David Conrad <drc@virtualized.org> Cc: North American Operators' Group <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. 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 <drc@virtualized.org> Sent: Wednesday, February 14, 2024 1:03 PM To: Christopher Hawker <chris@thesysadmin.au> Cc: North American Operators' Group <nanog@nanog.org> Subject: Re: The Reg does 240/4 Christopher, On Feb 13, 2024, at 4:14 PM, Christopher Hawker <chris@thesysadmin.au> 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
Christopher, On Feb 14, 2024, at 4:49 AM, Christopher Hawker <chris@thesysadmin.au> wrote:
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.
You’re mixing agendas. In earlier messages, you had argued the address space should be provided to "new entrants.” However, if IP resource were intended to be a tool that allows people to globally connect, then the age/size/previous holdings of the organization obtaining the address space shouldn’t matter: what matters is whether it is used for connectivity. Indeed, if you want to facilitate the greatest amount of connectivity, it can be (and has been) argued the allocations should be made to the larger players since they have more resources to put the address space into use, greater reach, larger marketing departments, etc. (These are the same arguments made at various RIR policy meetings prior to runout any time anyone suggested limitations on IPv4 address allocations. The nice thing about history repeating itself is that you know when to go out and get popcorn.)
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.
I suspect any limited resource with unlimited demand is going to end up here. You’re arguing against markets. Good luck with that. Regards, -drc
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
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 <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of Denis Fondras via NANOG <nanog@nanog.org> Sent: Wednesday, February 14, 2024 11:10 PM To: nanog@nanog.org <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
1. RIRs, following https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en, would request new /8s, and receive those allocations.
I don’t think this applies any more. I could be wrong, but I think based on current practice, IANA would simply distribute 3 of the 16 /8s to each of the RIRs. That’s been the process for recovered blocks since the last 5 /8s from the free pool were distributed.
2. Entities[*] with pent up demand would submit requests and have those requests filled by the RIRs
Which would rapidly deplete that space in most RIRs and leave an abundance of wasted space sitting on the shelf in a couple of RIRs with policies that prolong the shortage on the pretense that it enhances the useful life of IPv4.
3. While more /8s in 240/4 remain, go to step 1
Or not. (See my comment on step 1)
4. Return to status quo ante.
Which happens almost immediately for IANA and soon thereafter in most RIRs.
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?
Here, I 100% agree with David. (Which is quite rare) Owen
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.
Respectfully, if you're just putting your case out there and hoping that people come around to your position, it's never going to happen. On Tue, Feb 13, 2024 at 5:15 PM Christopher Hawker <chris@thesysadmin.au> 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 <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> 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
It appears that Tom Beecher <beecher@beecher.cc> said:
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.
Respectfully, if you're just putting your case out there and hoping that people come around to your position, it's never going to happen.
I think we have once again established that repeating a bad idea over and over and over does not make it any less bad. Let's argue about something else, OK? R's, John
On Wed, Feb 14, 2024 at 9:23 AM Owen DeLong via NANOG <nanog@nanog.org> 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; it is people's tendency to intuitively judge that a situation is zero-sum, even when this is not the case. This bias promotes zero-sum fallacies, false beliefs that situations are zero-sum. Such fallacies can cause other false judgements and poor decisions." https://en.wikipedia.org/wiki/Zero-sum_thinking Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
It appears that William Herrin <bill@herrin.us> said:
On Wed, Feb 14, 2024 at 9:23 AM Owen DeLong via NANOG <nanog@nanog.org> 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
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 <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of John Levine <johnl@iecc.com> Sent: Thursday, February 15, 2024 10:11 AM To: nanog@nanog.org <nanog@nanog.org> Subject: Re: The Reg does 240/4 It appears that William Herrin <bill@herrin.us> said:
On Wed, Feb 14, 2024 at 9:23 AM Owen DeLong via NANOG <nanog@nanog.org> 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
… 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. This is a false dichotomy: those aren’t the only two options, nor the best two options. The best option is what is happening right now: you can’t get new IPv4 addresses, so you have to either buy them, or use IPv6. The free market is solving the problem right now. Another solution isn’t needed. For example, Amazon is charging $0.005 per IPv4 per hour, which is a perfect. AWS users can either choose to use IPv4 at that rate, or choose to use IPv6 at $0.000 per hour. And Azure is basically doing the same thing. See https://azure.microsoft.com/en-us/pricing/details/ip-addresses/ and https://azure.microsoft.com/en-ca/updates/azure-public-ipv6-offerings-are-fr... So just sit back and watch the world re-address to IPv6. It’s not a race. Tom
On 2/14/24 4:23 PM, Tom Samplonius wrote:
The best option is what is happening right now: you can’t get new IPv4 addresses, so you have to either buy them, or use IPv6. The free market is solving the problem right now. Another solution isn’t needed.
Really? How many mail servers are up on IPv6? How many legacy mail clients can handle IPv6? How many MTA software packages can handle IPv6 today "right out of the box" without specific configuration? Does any IPv6 enabled ISP provide PTR records for mail servers? How does Google handle mail from an IPv6 server? The Internet is not just the Web.
It appears that Stephen Satchell <list@satchell.net> said:
On 2/14/24 4:23 PM, Tom Samplonius wrote:
The best option is what is happening right now: you can’t get new IPv4 addresses, so you have to either buy them, or use IPv6. The free market is solving the problem right now. Another solution isn’t needed.
Really? How many mail servers are up on IPv6? How many legacy mail clients can handle IPv6? How many MTA software packages can handle IPv6 today "right out of the box" without specific configuration?
These days most of them. The popular open source sendmail, postfix, and exim all do. The mail programs on my Android phone and iPad do. Thunderbird does.
Does any IPv6 enabled ISP provide PTR records for mail servers?
I'm not sure what you're asking. Every IPv6 mail server has rDNS since otherwise nobody would accept its mail, same as IPv4.
How does Google handle mail from an IPv6 server?
Assuming it's authenticated with SPF or DKIM, better than IPv4. All the mail between Gmail and my system runs over IPv6. A fair amount of mail from Hotmail/Outlook arrives over IPv6 as well which is surprising since they don't publish AAAA records for their inbound mail. R's, John
On 15 Feb 2024, at 13:25, Stephen Satchell <list@satchell.net> wrote:
On 2/14/24 4:23 PM, Tom Samplonius wrote:
The best option is what is happening right now: you can’t get new IPv4 addresses, so you have to either buy them, or use IPv6. The free market is solving the problem right now. Another solution isn’t needed.
Really? How many mail servers are up on IPv6?
Lots.
How many legacy mail clients can handle IPv6?
Most. If you are using mbox format there is no change. The only ones that don’t handle it are ones that don’t have support for creating IPv6 connections.
How many MTA software packages can handle IPv6 today "right out of the box" without specific configuration?
Most. Really its been 20+ years since IPv6 was added to most of the mail products that actually use TCP to connect to a mail store or to send email. Just about the only thing that was needed to be done was to look for AAAA records in addition to A records after looking up the MX records or to replace gethostbyname with getnodebyname and then getaddrinfo. This was a 10 minute job for most developers. If you publish AAAA records for a service they will be used.
Does any IPv6 enabled ISP provide PTR records for mail servers?
If they want to send email from those addresses they do.
How does Google handle mail from an IPv6 server?
Mostly the same as from IPv4.
The Internet is not just the Web.
It isn’t. But you could answer most of these by just looking at the email headers in your own incoming mail. Email has been delivered over IPv6 for over 2 decades now. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
How many legacy mail clients can handle IPv6?
I would suspect all of them, since MUAs, by definition, are not involved in any mail transport operations. But if you're thinking of MUAs that use Submission, they are unlikely to care one whit what the underlying transport is. You configure a submission hostname, and the client just hands that off to the underlying OS to deal with. It doesn't care what parameters are passed to the connect() call under the hood. As for mail servers handling v6 out of the box, I am not familiar with *any* currently shipping MTA that does NOT do v6 with no configuration required. --lyndon
On Feb 14, 2024, at 18:25, Stephen Satchell <list@satchell.net> wrote:
On 2/14/24 4:23 PM, Tom Samplonius wrote:
The best option is what is happening right now: you can’t get new IPv4 addresses, so you have to either buy them, or use IPv6. The free market is solving the problem right now. Another solution isn’t needed.
Really? How many mail servers are up on IPv6? How many legacy mail clients can handle IPv6? How many MTA software packages can handle IPv6 today "right out of the box" without specific configuration?
Quite a few, actually. About 40% of my email comes and goes via IPv6. Sendai, postfix, outlook, and several others all handle IPv6 without need for any more IPv6 specific configuration than is required for IPv4.
Does any IPv6 enabled ISP provide PTR records for mail servers?
Yes. Most of the transit providers I deal with offer ip6.arpa delegation at least. You can either stand up your own NS or use any of a variety of free DNS providers to host that delegation.
How does Google handle mail from an IPv6 server?
So far I’ve had no issues exchanging mail with Google, Yahoo, or MSN (former Hotmail) on IPv6.
The Internet is not just the Web.
True. Guess what… SSH, VNC, SMTP, IMAP, and many other things are working just fine on IPv6. IPv6 isn’t just the web either. IPv6 is the modern internet. Owen
On Wed, 14 Feb 2024 18:25:03 -0800 Stephen Satchell <list@satchell.net> wrote:
On 2/14/24 4:23 PM, Tom Samplonius wrote:
The best option is what is happening right now: you can’t get new IPv4 addresses, so you have to either buy them, or use IPv6. The free market is solving the problem right now. Another solution isn’t needed.
Really? How many mail servers are up on IPv6? How many legacy mail clients can handle IPv6? How many MTA software packages can handle IPv6 today "right out of the box" without specific configuration?
Mine have been dual stack for a while (6 years? 8 years? don't exactly recall). However, I remember being enough of an early v6 adopter that it was a bit of a challenge to get IPv6 glue records set up for our DNS servers (that was long before I was brave enough to have my email servers on v6, though).
Does any IPv6 enabled ISP provide PTR records for mail servers?
We do, of course, I can't speak for others. We also sub-delegate on request. However, we are small/local and cater to small businesses.
How does Google handle mail from an IPv6 server?
I remember Google being where some of my first v6 email was coming from and going to. I would advise that if you allow your MTA to attach to all IPv6 addresses that you make sure all of them have REV PTR. Google, at least last time I looked, would deny email via IPv6 based solely on REV PTR errors. They are more forgiving over v4, but I suspect that has/had to do with more mature spam filtering considerations on v4 than v6. I once made the mistake of not having one of my secondary addresses set up with a REV PTR and Google rejected any email that came from that IP. --TimH
" Does any IPv6 enabled ISP provide PTR records for mail servers?" I think people will conflate doing so at ISP-scale and doing so at residential hobbiyst scale (and everything in between). One would expect differences in outcomes of attempting PTR records in DIA vs. broadband. "How does Google handle mail from an IPv6 server?" A few people have posted that it works for them, but unless it has changed recently, per conversations on the mailop mailing list, Google does not treat IPv6 and IPv4 mail the same and that causes non-null issues. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Stephen Satchell" <list@satchell.net> To: nanog@nanog.org Sent: Wednesday, February 14, 2024 8:25:03 PM Subject: Re: The Reg does 240/4 On 2/14/24 4:23 PM, Tom Samplonius wrote:
The best option is what is happening right now: you can’t get new IPv4 addresses, so you have to either buy them, or use IPv6. The free market is solving the problem right now. Another solution isn’t needed.
Really? How many mail servers are up on IPv6? How many legacy mail clients can handle IPv6? How many MTA software packages can handle IPv6 today "right out of the box" without specific configuration? Does any IPv6 enabled ISP provide PTR records for mail servers? How does Google handle mail from an IPv6 server? The Internet is not just the Web.
We (comcast.net) have been sending/receiving via IPv6 since 2012 or so. We do have PTR records for our outbound IPv6 addresses, and expect them for inbound IPv6 as well. Keeping in mind that a huge portion of inbound mail is bulk/commercial and they have thus far largely avoided IPv6, Inbound IPv6 is about 5% of traffic. Outbound IPv6 is about 40% of traffic. I’m not sharing mail submissions from users as many (nearly all?) of our users have IPv6 and that would skew the numbers, and may not be relevant to this discussion. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: NANOG <nanog-bounces+alex_brotman=comcast.com@nanog.org> On Behalf Of Mike Hammett Sent: Friday, February 16, 2024 10:20 AM To: list@satchell.net Cc: nanog@nanog.org Subject: Re: The Reg does 240/4 "Does any IPv6 enabled ISP provide PTR records for mail servers?" I think people will conflate doing so at ISP-scale and doing so at residential hobbiyst scale (and everything in between). One would expect differences in outcomes of attempting PTR records in DIA vs. broadband. "How does Google handle mail from an IPv6 server?" A few people have posted that it works for them, but unless it has changed recently, per conversations on the mailop mailing list, Google does not treat IPv6 and IPv4 mail the same and that causes non-null issues. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com<https://urldefense.com/v3/__http:/www.ics-il.com__;!!CQl3mcHX2A!Adj7UyXOfg2bkj9fl_CbY2Z7kBhqQzqvduQFbfMITlcG2Om1zcWSj6zljATvnM2kFdxDQer3FJBfv7AFbA$> Midwest-IX http://www.midwest-ix.com<https://urldefense.com/v3/__http:/www.midwest-ix.com__;!!CQl3mcHX2A!Adj7UyXOfg2bkj9fl_CbY2Z7kBhqQzqvduQFbfMITlcG2Om1zcWSj6zljATvnM2kFdxDQer3FJCDd4cxfw$> ________________________________ From: "Stephen Satchell" <list@satchell.net<mailto:list@satchell.net>> To: nanog@nanog.org<mailto:nanog@nanog.org> Sent: Wednesday, February 14, 2024 8:25:03 PM Subject: Re: The Reg does 240/4 On 2/14/24 4:23 PM, Tom Samplonius wrote:
The best option is what is happening right now: you can’t get new IPv4 addresses, so you have to either buy them, or use IPv6. The free market is solving the problem right now. Another solution isn’t needed.
Really? How many mail servers are up on IPv6? How many legacy mail clients can handle IPv6? How many MTA software packages can handle IPv6 today "right out of the box" without specific configuration? Does any IPv6 enabled ISP provide PTR records for mail servers? How does Google handle mail from an IPv6 server? The Internet is not just the Web.
It appears that Mike Hammett <nanog@ics-il.net> said:
-=-=-=-=-=-
" Does any IPv6 enabled ISP provide PTR records for mail servers?"
I think people will conflate doing so at ISP-scale and doing so at residential hobbiyst scale (and everything in between). One would expect differences in outcomes of attempting PTR records in DIA vs. broadband.
Most consumer ISPs block port 25 so rDNS would be the least of your problems trying to run a home mail server.
"How does Google handle mail from an IPv6 server?"
A few people have posted that it works for them, but unless it has changed recently, per conversations on the mailop mailing list, Google does not treat IPv6 and IPv4 mail the same and that causes non-null issues.
As has been widely reported, Google has recently tightened up authentication requirements so v4 and v6 are now pretty similar. They won't accept v6 mail that isn't authenticated with SPF or DKIM but honestly, if you can't figure out how to publish an SPF record you shouldn't try to run a mail server. R's, John
Mike, it’s true that Google used to be a lot less strict on IPv4 email than IPv6, but they want SPF and /or DKIM on everything now, so it’s mostly the same. There is less reputation data available for IPv6 and server reputation is a harder problem in IPv6, but reputation systems are becoming less relevant. YMMV, but if your mail server is properly configured for SPF and DKIM, you shouldn’t have any difference in SMTP experience with Google for either protocol. Owen
On Feb 16, 2024, at 07:20, Mike Hammett <nanog@ics-il.net> wrote:
"Does any IPv6 enabled ISP provide PTR records for mail servers?"
I think people will conflate doing so at ISP-scale and doing so at residential hobbiyst scale (and everything in between). One would expect differences in outcomes of attempting PTR records in DIA vs. broadband.
"How does Google handle mail from an IPv6 server?"
A few people have posted that it works for them, but unless it has changed recently, per conversations on the mailop mailing list, Google does not treat IPv6 and IPv4 mail the same and that causes non-null issues.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
From: "Stephen Satchell" <list@satchell.net> To: nanog@nanog.org Sent: Wednesday, February 14, 2024 8:25:03 PM Subject: Re: The Reg does 240/4
On 2/14/24 4:23 PM, Tom Samplonius wrote:
The best option is what is happening right now: you can’t get new IPv4 addresses, so you have to either buy them, or use IPv6. The free market is solving the problem right now. Another solution isn’t needed.
Really? How many mail servers are up on IPv6? How many legacy mail clients can handle IPv6? How many MTA software packages can handle IPv6 today "right out of the box" without specific configuration?
Does any IPv6 enabled ISP provide PTR records for mail servers?
How does Google handle mail from an IPv6 server?
The Internet is not just the Web.
On 2/17/24 10:19 AM, Owen DeLong via NANOG wrote:
Mike, it’s true that Google used to be a lot less strict on IPv4 email than IPv6, but they want SPF and /or DKIM on everything now, so it’s mostly the same. There is less reputation data available for IPv6 and server reputation is a harder problem in IPv6, but reputation systems are becoming less relevant.
I kind of get the impression that once you get to aggregates at the domain level like DKIM or SPF, addresses as a reputation vehicle don't much figure into decision making. But what happens under the hood at major mailbox providers is maddeningly opaque so who really knows? It would be nice if MAAWG published a best practices or something like that to outline what is actually happening in live deployments. Mike
It appears that Michael Thomas <mike@mtcc.com> said:
I kind of get the impression that once you get to aggregates at the domain level like DKIM or SPF, addresses as a reputation vehicle don't much figure into decision making.
It definitely does, since there are plenty of IPs that send only malicious mail, or that shouldn't be sending mail at all. Every large mail system uses Spamhaus' IP lists as part of their filtering process. I hear that SPF is largely useless these days because most SPF records include IP ranges for many mail providers, and a lot of those providers do a poor job of keeping one customer from spoofing mail from another. DKIM is still quite useful. K. But what happens under the hood at
major mailbox providers is maddeningly opaque so who really knows? It would be nice if MAAWG published a best practices or something like that to outline what is actually happening in live deployments.
Unfortunately, spammers can read just as well as we can so it's not going to happen. R's, John
On 2/17/24 2:21 PM, John Levine wrote:
But what happens under the hood at
major mailbox providers is maddeningly opaque so who really knows? It would be nice if MAAWG published a best practices or something like that to outline what is actually happening in live deployments. Unfortunately, spammers can read just as well as we can so it's not going to happen.
They already have the recon so they don't need any help. The rest of us could be helped by what the current art is. Mike
All we can do is educate people on the importance of IPv6 uptake, we can not force people to adopt it.
At this stage of the game, networks and products that don't support V6 aren't likely to do so unless there is a forcing function to make them do it. Meaning money. On Wed, Feb 14, 2024 at 6:35 PM Christopher Hawker <chris@thesysadmin.au> wrote:
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 <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of John Levine <johnl@iecc.com> *Sent:* Thursday, February 15, 2024 10:11 AM *To:* nanog@nanog.org <nanog@nanog.org> *Subject:* Re: The Reg does 240/4
It appears that William Herrin <bill@herrin.us> said:
On Wed, Feb 14, 2024 at 9:23 AM Owen DeLong via NANOG <nanog@nanog.org> 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
There is one other mechanism available that has not yet come into play. One which this proposal seeks to further delay. In fact IMHO, the one that is most likely to ultimately succeed… At some point new entrants will be unable to obtain IPv4. When there is a sufficient critical mass of those that IPv4 only sites cannot reach, those sites will be faced with an ROI on IPv6 deployment they can no longer ignore. Hence, not only is this bad idea a waste of effort, but it’s actually harmful in the short, medium, and long terms. Owen
On Feb 14, 2024, at 15:35, Christopher Hawker <chris@thesysadmin.au> wrote:
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 <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of John Levine <johnl@iecc.com> Sent: Thursday, February 15, 2024 10:11 AM To: nanog@nanog.org <nanog@nanog.org> Subject: Re: The Reg does 240/4
It appears that William Herrin <bill@herrin.us> said:
On Wed, Feb 14, 2024 at 9:23 AM Owen DeLong via NANOG <nanog@nanog.org> 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
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 <owen@delong.com> Sent: Thursday, February 15, 2024 4:23 AM To: Christopher Hawker <chris@thesysadmin.au> Cc: Tom Beecher <beecher@beecher.cc>; North American Operators' Group <nanog@nanog.org> 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 <chris@thesysadmin.au> 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 <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
On Feb 15, 2024, at 03:29, Christopher Hawker <chris@thesysadmin.au> wrote:
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".
It may be your first time at bat, but this proposal has been rejected in the IETF many times before over at least 2 decades.
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.
Actually, no, no we should not continue to support IPv4. The sooner there are real world consequences to those networks that have failed to implement IPv6, the sooner they will finally do so. Unfortunately, yes, this will be temporarily painful to new entrants that are IPv6 only until there is a sufficient critical mass of them to drive the remaining (and ever decreasing) IPv4 only networks to finally act. Delaying that inevitability only prolongs this pain and does not improve or promote any common good. Owen
I've said it before, and I'll say it again: The only thing stopping global IPv6 deployment is Netflix continuing to offer services over IPv4. If Netflix dropped IPv4, you would see IPv6 available *everywhere* within a month. --lyndon
On Thu, Feb 15, 2024 at 11:10 AM Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote:
I've said it before, and I'll say it again:
The only thing stopping global IPv6 deployment is Netflix continuing to offer services over IPv4.
If Netflix dropped IPv4, you would see IPv6 available *everywhere* within a month.
If only a couple of large businesses would slit their throats by refusing to service a large swath of their paying customers, IPv6 deployment would surely accelerate. -- William Herrin bill@herrin.us https://bill.herrin.us/
For everyone’s amusement: [root@owen log]# grep 'IPv6' maillog | wc -l 2648 [root@owen log]# grep 'IPv4' maillog | wc -l 0 Now admittedly, this isn’t really a fair report because sendmail doesn’t tag IPv4 address as “IPv4” like it does IPv6 addresses. e.g.: Feb 15 19:22:59 owen sendmail[1545111]: STARTTLS=server, relay=localhost [IPv6:0:0:0:0:0:0:0:1], version=TLSv1.3, verify=NOT, cipher=TLS_AES_256_GCM_SHA384, bits=256/256 A slightly more fair version: [root@owen log]# grep 'connect from' maillog | wc -l 14547 [root@owen log]# grep 'connect from' maillog | grep IPv6 | wc -l 431 Which shows that 431 of 14547 total connections came via IPv6 during the log period (which begins 00:00:39 UTC Feb. 11) and continues to the time of this writing. However, that is overly generous to IPv4 because a much higher percentage of the connections on IPv6 result in actual mail transfer while many of the IPv4 connections are various failed authentication attempts, attempts to deliver rejected (SPAM, other) messages, and other various failures to complete the delivery process (disconnects after EHLO, etc.). As stated earlier, approximately 40% of all mail received by my MTA arrives over IPv6. FWIW, most of my netflix viewing is done via IPv6 as well. turning off IPv4 is a tall order and a huge risk for Netflix to take, so I don’t see that happening. You’re not wrong about the likely impact, but it would be a rough contest between ISPs telling their customers “Netflix turned us off, blame them” and Netflix telling its customers “We’re no longer supporting the legacy internet protocol and your ISP needs to modernize.”. In the end it likely turns into a pox on both their houses and the ISPs in question and Netflix both lose a bunch of customers in the process. OTOH, as new products come out that are unable to get IPv4 and are delivered over IPv6 only, this will eventually have roughly the same effect without the avoidable business risk involved in Netflix leading the way. this is my primary argument against the proposal, it will further delay this inevitability which, in turn, prolongs the pain period of this transition. While a handful of new entrants might benefit in some way in the short term from such a thing, in the long term, it’s actually harmful to everyone overall. Owen
On Feb 15, 2024, at 11:10, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote:
I've said it before, and I'll say it again:
The only thing stopping global IPv6 deployment is Netflix continuing to offer services over IPv4.
If Netflix dropped IPv4, you would see IPv6 available *everywhere* within a month.
--lyndon
On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
I've said it before, and I'll say it again:
The only thing stopping global IPv6 deployment is Netflix continuing to offer services over IPv4.
If Netflix dropped IPv4, you would see IPv6 available *everywhere* within a month.
As others have noted, and to paraphrase a long-ago quote from this mailing list, I'm sure all of Netflix's competitors hope Netflix does that. I remain hopeful that the climbing price of unique, available IPv4 addresses eventually forces migration to v6. From my armchair, only through economics will this situation will be resolved.
--lyndon
-Brian
$/IPv4 address peaked in 2021, and has been declining since. On Thu, Feb 15, 2024 at 16:05 Brian Knight via NANOG <nanog@nanog.org> wrote:
On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
I've said it before, and I'll say it again:
The only thing stopping global IPv6 deployment is Netflix continuing to offer services over IPv4.
If Netflix dropped IPv4, you would see IPv6 available *everywhere* within a month.
As others have noted, and to paraphrase a long-ago quote from this mailing list, I'm sure all of Netflix's competitors hope Netflix does that.
I remain hopeful that the climbing price of unique, available IPv4 addresses eventually forces migration to v6. From my armchair, only through economics will this situation will be resolved.
--lyndon
-Brian
Evidence to support Tom's statement: https://auctions.ipv4.global/prior-sales ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "Brian Knight" <ml@knight-networks.com> Cc: nanog@nanog.org Sent: Thursday, February 15, 2024 5:31:42 PM Subject: Re: The Reg does 240/4 $/IPv4 address peaked in 2021, and has been declining since. On Thu, Feb 15, 2024 at 16:05 Brian Knight via NANOG < nanog@nanog.org > wrote: On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
I've said it before, and I'll say it again:
The only thing stopping global IPv6 deployment is Netflix continuing to offer services over IPv4.
If Netflix dropped IPv4, you would see IPv6 available *everywhere* within a month.
As others have noted, and to paraphrase a long-ago quote from this mailing list, I'm sure all of Netflix's competitors hope Netflix does that. I remain hopeful that the climbing price of unique, available IPv4 addresses eventually forces migration to v6. From my armchair, only through economics will this situation will be resolved.
--lyndon
-Brian
It seems we’re the marketplace of record. We do have some private transactions, that is, sales that take place outside of our marketplace and therefore don’t appear on the prior-sales page. That’s generally for /16 or larger, where one or both parties want custom terms that differ from our standard Terms of Use. It’s true that prices for /16 and larger have held steadier than smaller blocks. My guess is that there has been a lot more supply of smaller blocks than /16+, driving prices down for the smaller blocks. Supply for /16s and larger is fine, but not enormous. I don’t assume that prices will remain the same. So, what about 240/4? The IPv4 market moves about 40 million addresses per year. A /4 is 268 million addresses, so if that supply became available (IETF telling IANA to distribute it to the RIRs, I assume) it would definitely affect the market for a long time. The RIRs would have to look at their post-exhaustion policies and figure out whether they still applied, or if pre-exhaustion policies should be used. I don’t have a strong opinion on this, and give credit to the authors of the proposal for working to identify any places where 240/4 would not work. I still think the Internet works better when everyone uses the same protocol, so everyone should deploy IPv6. At this point, the consumer electronics and corporate IT sectors are the major holdouts. There are still ISPs and web sites that don’t have IPv6, but it’s no longer reasonable to assert that those are failures as a group, IMHO. Lee Howard | Senior Vice President, IPv4.Global [Inline image] t: 646.651.1950 email: LeeHoward@HilcoStreambank.com<mailto:LeeHoward@HilcoStreambank.com> web: www.ipv4.global<http://www.ipv4.global/> twitter: twitter.com/ipv4g<https://twitter.com/ipv4g/> From: NANOG <nanog-bounces+leehoward=hilcostreambank.com@nanog.org> On Behalf Of Mike Hammett Sent: Friday, February 16, 2024 10:28 AM To: Tom Beecher <beecher@beecher.cc> Cc: nanog@nanog.org Subject: Re: The Reg does 240/4 This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments. Evidence to support Tom's statement: https://auctions.ipv4.global/prior-sales ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ________________________________ From: "Tom Beecher" <beecher@beecher.cc<mailto:beecher@beecher.cc>> To: "Brian Knight" <ml@knight-networks.com<mailto:ml@knight-networks.com>> Cc: nanog@nanog.org<mailto:nanog@nanog.org> Sent: Thursday, February 15, 2024 5:31:42 PM Subject: Re: The Reg does 240/4 $/IPv4 address peaked in 2021, and has been declining since. On Thu, Feb 15, 2024 at 16:05 Brian Knight via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote: On 2024-02-15 13:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
I've said it before, and I'll say it again:
The only thing stopping global IPv6 deployment is Netflix continuing to offer services over IPv4.
If Netflix dropped IPv4, you would see IPv6 available *everywhere* within a month.
As others have noted, and to paraphrase a long-ago quote from this mailing list, I'm sure all of Netflix's competitors hope Netflix does that. I remain hopeful that the climbing price of unique, available IPv4 addresses eventually forces migration to v6. From my armchair, only through economics will this situation will be resolved.
--lyndon
-Brian
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".
This may be the first time your group has presented your opinions on 240/4, but you are not the first. It's been brought up at IETF multiple times, multiple drafts submitted, multiple debates / convos / arguments had. At the end of the day, the following is still true. 1. Per RFC2860, IANA maintains the registry of IPv4 allocations to RIRs, and the IPv4 Special Address Space Registry. 2. The IPv4 Special Address Space Registry records 240.0.0.0/4 as Reserved , per RFC1112, Section 4. 3. Any changes to the IPv4 Special Address Space Registry require IETF Review , RFC7249, Section 2.2. 4. IETF Review is defined in RFC5226. In summation, the status of 240/4 CAN ONLY be changed IF the IETF process results in an RFC that DIRECTS IANA to update the IPv4 Special Address Space Registry. To date, the IETF process has not done so. Making the case on mailing lists , forums, or media outlets may try to win hearts and minds, but unless the IETF process is engaged with, nothing will change. Of course, some will want to reply that 'the IETF are meanies and don't want to do what we want'. All I'd say to that is , welcome to the process of making / changing internet standards. :) On Thu, Feb 15, 2024 at 6:29 AM Christopher Hawker <chris@thesysadmin.au> wrote:
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 <owen@delong.com> *Sent:* Thursday, February 15, 2024 4:23 AM *To:* Christopher Hawker <chris@thesysadmin.au> *Cc:* Tom Beecher <beecher@beecher.cc>; North American Operators' Group < nanog@nanog.org> *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 <chris@thesysadmin.au> 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 <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> 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
Several people in NANOG have opined that there are a number of mail servers on the Internet operating with IPv6 addresses. OK. I have a mail server, which has been on the Internet for decades. On IPv4. For the last four years, every attempt to get a PTR record in ip6.arpa from my ISP has been rejected, usually with a nasty dismissive. Today, I'm trying again to get that all-important PTR record. If I'm successful, then I expect to have my mail server fully up and running in the IPv6 space within 72 hours, or when the DNS changes propagate, whichever is longer.
Well all that shows is that your ISP is obstructionist. If they can can enter a PTR record or delegate the reverse range to you for your IPv4 server they can do it for your IPv6 addresses. In most cases it is actually easier as address space is assigned on nibble boundaries (/48, /52, /56, /60, :64) so there isn’t a need to do multiple delegations and RFC2317 style “delegations” aren’t needed in IPv6. If there is a non nibble assignment just do multiple sequential delegations (2, 4 or 8). It isn’t hard to type the reverse prefix into a zone then ns then the name of a server, bump the serial and reload it. e.g. e.b.c.2.6.0.7.d.0.2.2.2.ip6.arpa. ns ns1.example.com. Good luck. -- Mark Andrews
On 16 Feb 2024, at 04:48, Stephen Satchell <list@satchell.net> wrote:
Several people in NANOG have opined that there are a number of mail servers on the Internet operating with IPv6 addresses. OK. I have a mail server, which has been on the Internet for decades. On IPv4.
For the last four years, every attempt to get a PTR record in ip6.arpa from my ISP has been rejected, usually with a nasty dismissive.
Today, I'm trying again to get that all-important PTR record. If I'm successful, then I expect to have my mail server fully up and running in the IPv6 space within 72 hours, or when the DNS changes propagate, whichever is longer.
It appears that Stephen Satchell <list@satchell.net> said:
Several people in NANOG have opined that there are a number of mail servers on the Internet operating with IPv6 addresses. OK. I have a mail server, which has been on the Internet for decades. On IPv4.
For the last four years, every attempt to get a PTR record in ip6.arpa from my ISP has been rejected, usually with a nasty dismissive.
I don't think you'll get much disagreement that AT&T is not a great ISP. One straightforward workaround is to get an IPv6 tunnel from Hurricane. It's free, it works, and they will delegate the rDNS anywhere you want. My local ISP doesn't do IPv6 at all (they're a rural phone company who of course say you are the only person who's ever asked) so until they do, HE is a quite adequate option. R's, John
The Internet edge and core portion of deploying IPv6 - dual-stack or otherwise - is fairly easy. I led efforts to do this at a large .edu starting in 2010/11. The biggest hurdles are/were/might still be: 1. Coming up with a good address plan that will do what you want and scale as needed. It should also be flexible enough to accommodate re-writes if you think of something that needs to be added/changed down the road :) 2. For providers who run older kit, v6 support might still be a bit dodgy. You might also run into things like TCAM exhaustion, neighbor table exhaustion, etc. The point at which box X tips over is often not well defined and depends on your use case and configuration. 3. The last time I checked, v6 support in firewalls and other middle-mile devices was still poor. Hopefully that has gotten better in the last 6-7 years. My current day job doesn't have me touching firewalls, so I haven't kept up on developments here. I recall coming up with a base firewall ruleset for Cisco ASAs to balance security with the functionality v6 needs to work correctly. Hopefully firewall vendors have gotten better about building templates to handle some of the heavy lifting. 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world. Thank you jms On Thu, Feb 15, 2024 at 8:43 PM John Levine <johnl@iecc.com> wrote:
It appears that Stephen Satchell <list@satchell.net> said:
Several people in NANOG have opined that there are a number of mail servers on the Internet operating with IPv6 addresses. OK. I have a mail server, which has been on the Internet for decades. On IPv4.
For the last four years, every attempt to get a PTR record in ip6.arpa from my ISP has been rejected, usually with a nasty dismissive.
I don't think you'll get much disagreement that AT&T is not a great ISP.
One straightforward workaround is to get an IPv6 tunnel from Hurricane. It's free, it works, and they will delegate the rDNS anywhere you want. My local ISP doesn't do IPv6 at all (they're a rural phone company who of course say you are the only person who's ever asked) so until they do, HE is a quite adequate option.
R's, John
On 2/15/24 9:40 PM, Justin Streiner wrote:
The Internet edge and core portion of deploying IPv6 - dual-stack or otherwise - is fairly easy. I led efforts to do this at a large .edu starting in 2010/11. The biggest hurdles are/were/might still be: 1. Coming up with a good address plan that will do what you want and scale as needed. It should also be flexible enough to accommodate re-writes if you think of something that needs to be added/changed down the road 🙂
Several of the resources and books I picked up over the past five years discuss this. At the leaf level, coming up with a address plan is easy. For example, I define two subnets: one for public access, one for LAN use. Each subnet has 64K addresses, far more than I need. The firewall protects the LANnet
2. For providers who run older kit, v6 support might still be a bit dodgy. You might also run into things like TCAM exhaustion, neighbor table exhaustion, etc. The point at which box X tips over is often not well defined and depends on your use case and configuration.
Above my use level as a leaf node. It may explain part of the situation I have with my upstream ISP...but I think the problem is more related to account management and not a technical one.
3. The last time I checked, v6 support in firewalls and other middle-mile devices was still poor. Hopefully that has gotten better in the last 6-7 years. My current day job doesn't have me touching firewalls, so I haven't kept up on developments here. I recall coming up with a base firewall ruleset for Cisco ASAs to balance security with the functionality v6 needs to work correctly. Hopefully firewall vendors have gotten better about building templates to handle some of the heavy lifting.
In Linux, there have been significant advances in firewall support. Part of that support was in the kernel, part was in the tools. The advent of NFT (NFTABLES) further improves things. My replacement firewall design is to use YAML to define the rules; a Python driver converts the data into rules to implement the policy. Can't speak for others. By the way, instead of improving IPTABLES to handle IPv6, the community build IP6TABLES to support IPv6. I was told that all I needed to do with my BASH-implemented firewall driver was to add IP6TABLE commands to the existing IPTABLES rules. I would have done that if my upstream provider wasn't so IPv6-hostile. I think that would have been a mistake.
4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world.
That was EASY for me to unlearn. With IPv4, I never had the luxury of subnetting large swaths of addresses. With IPv6, that's easy, even in home networks. .................... That said, I'm thinking about giving up completely on IPv6 -- too many hurdles put in the way by my 800-pound-gorilla ISP. I'm too old to fight the battle any more; the ROI isn't worth the effort. I'll be dead before the lack of IPv6 connectivity becomes a personal problem.
----- Original Message -----
From: "Justin Streiner" <streinerj@gmail.com>
4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world.
NAT doesn't "equal" security. But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside. 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 Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth <jra@baylink.com> wrote:
From: "Justin Streiner" <streinerj@gmail.com> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world.
NAT doesn't "equal" security.
But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside.
Hi Jay, Every firewall does that. What NAT does above and beyond is place control of what internal nodes are -addressable- from the outside in the hands of the people inside -- so that most of the common mistakes with firewall configuration don't cause the internal hosts to -become- accessible. The distinction doesn't seem that subtle to me, but a lot of folks making statements about network security on this list don't appear to grasp it. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 2/16/24 3:01 PM, William Herrin wrote:
On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth <jra@baylink.com> wrote:
From: "Justin Streiner" <streinerj@gmail.com> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world. NAT doesn't "equal" security.
But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside. Hi Jay,
Every firewall does that. What NAT does above and beyond is place control of what internal nodes are -addressable- from the outside in the hands of the people inside -- so that most of the common mistakes with firewall configuration don't cause the internal hosts to -become- accessible.
If you know which subnets need to be NAT'd don't you also know which ones shouldn't exposed to incoming connections (or conversely, which should be permitted)? It seems to me that all you're doing is moving around where that knowledge is stored? Ie, DHCP so it can give it private address rather than at the firewall knowing which subnets not to allow access? Yes, DHCP can be easily configured to make everything private, but DHCP for static reachable addresses is pretty handy too. Mike
On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas <mike@mtcc.com> wrote:
If you know which subnets need to be NAT'd don't you also know which ones shouldn't exposed to incoming connections (or conversely, which should be permitted)? It seems to me that all you're doing is moving around where that knowledge is stored? Ie, DHCP so it can give it private address rather than at the firewall knowing which subnets not to allow access? Yes, DHCP can be easily configured to make everything private, but DHCP for static reachable addresses is pretty handy too.
Hi Mike, Suppose I have a firewall at 2602:815:6000::1 with an internal network of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to disallow all Internet packets to 2602:815:6001::/64 that are not part of an established connection. Someone tries to telnet to 2602:815:6001::4. What happens? Blocked. Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked. Now suppose I have a firewall at 199.33.225.1 with an internal network of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to do NAT translation from 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which also has the effect of disallowing inbound packets to 192.168.55.0/24 which are not part of an established connection. Someone tries to telnet to 192.168.55.4. What happens? The packet never even reaches my firewall because that IP address doesn't go anywhere on the Internet. Now I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 192.168.55.4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 192.168.55.4. What happens? The packet STILL doesn't reach my firewall because that IP address doesn't go anywhere on the Internet. See the difference? Accessible versus accessible and addressable. Not addressable enhances security. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 2/16/24 5:05 PM, William Herrin wrote:
On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas <mike@mtcc.com> wrote:
If you know which subnets need to be NAT'd don't you also know which ones shouldn't exposed to incoming connections (or conversely, which should be permitted)? It seems to me that all you're doing is moving around where that knowledge is stored? Ie, DHCP so it can give it private address rather than at the firewall knowing which subnets not to allow access? Yes, DHCP can be easily configured to make everything private, but DHCP for static reachable addresses is pretty handy too. Hi Mike,
Suppose I have a firewall at 2602:815:6000::1 with an internal network of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to disallow all Internet packets to 2602:815:6001::/64 that are not part of an established connection.
Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked.
Yes, but if the DHCP database has a mistake it's pretty much the same situation since it could be numbered with a public address. For both you can have the default as "reject" or "accept" -- that's just a default and depends on how you want to manage your network. NAT is not without its own set of problems, so if this boils down to a subnet management issue there are obviously ways to deal with that to avoid NAT's problems. Both DHCP and firewall configs don't have to be the ultimate source of truth about any of this. And that's likely a Good Thing since you want them to be pretty much as fungible and replaceable as possible. If you're exposed to fat fingers for either, you're probably already in trouble. Something in the management plain is far more likely to care about this kind of thing than hardware vendors who see that as a cost center with predictably shitty implementations. Mike
On Fri, Feb 16, 2024 at 5:22 PM Michael Thomas <mike@mtcc.com> wrote:
On 2/16/24 5:05 PM, William Herrin wrote:
Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked.
Yes, but if the DHCP database has a mistake it's pretty much the same situation since it could be numbered with a public address.
Um. No. You'd have to make multiple mistakes cross-contaminating your public and private ethernet segments yet somehow without completely breaking your network rendering it inoperable.
NAT is not without its own set of problems,
NAT's problems are legion. But the question was whether and how NAT improves the security of a network employing it. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 2/16/24 5:30 PM, William Herrin wrote:
On 2/16/24 5:05 PM, William Herrin wrote:
Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked. Yes, but if the DHCP database has a mistake it's pretty much the same situation since it could be numbered with a public address. Um. No. You'd have to make multiple mistakes cross-contaminating your
On Fri, Feb 16, 2024 at 5:22 PM Michael Thomas <mike@mtcc.com> wrote: public and private ethernet segments yet somehow without completely breaking your network rendering it inoperable.
So you're not going to address that this is a management plain problem. ok. Mike
On Fri, Feb 16, 2024 at 5:33 PM Michael Thomas <mike@mtcc.com> wrote:
So you're not going to address that this is a management plain problem.
Hi Mike, What is there to address? I already said that NAT's security enhancement comes into play when a -mistake- is made with the network configuration. You want me to say it again? Okay, I've said it again. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 2/16/24 5:37 PM, William Herrin wrote:
On Fri, Feb 16, 2024 at 5:33 PM Michael Thomas <mike@mtcc.com> wrote:
So you're not going to address that this is a management plain problem. Hi Mike,
What is there to address? I already said that NAT's security enhancement comes into play when a -mistake- is made with the network configuration. You want me to say it again? Okay, I've said it again.
The implication being that we should keep NAT'ing ipv6 for... a thin veil of security. That all of the other things that NAT breaks is worth the trouble because we can't trust our fat fingers on firewall configs. Mike
On Sat, Feb 17, 2024 at 10:03 AM Michael Thomas <mike@mtcc.com> wrote:
On 2/16/24 5:37 PM, William Herrin wrote:
What is there to address? I already said that NAT's security enhancement comes into play when a -mistake- is made with the network configuration. You want me to say it again? Okay, I've said it again.
The implication being that we should keep NAT'ing ipv6 for... a thin veil of security. That all of the other things that NAT breaks is worth the trouble because we can't trust our fat fingers on firewall configs.
Hi Mike, There's no "we" here, no one-size-fits-all answer. Some folks evaluating their scenario with their details will conclude that NAT's security benefit outweighs its performance and functionality implications. Others evaluating other scenarios will reach different answers. For enterprise customers, you're talking about folks who've been doing NAT for two decades and have more recently implemented HTTPS capture and re-encryption in order to scan for malware in transit. Will many of them insist on NAT and its security enhancement when they get around to deploying IPv6? Bet on it. So, what happens when you try to tell such folks that they don't need NAT for security in IPv6? It contradicts their -correct- intuition that NAT has a security benefit, but because they can't quite nail down what's wrong with your claim, it leaves them unsure. And what do people who are unsure about an IPv6 deployment do? Nothing! They put it back on the shelf and return to it in a couple of years. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Why is your Internal v6 subnet advertised to the Internet?
On Feb 16, 2024, at 8:08 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas <mike@mtcc.com> wrote:
If you know which subnets need to be NAT'd don't you also know which ones shouldn't exposed to incoming connections (or conversely, which should be permitted)? It seems to me that all you're doing is moving around where that knowledge is stored? Ie, DHCP so it can give it private address rather than at the firewall knowing which subnets not to allow access? Yes, DHCP can be easily configured to make everything private, but DHCP for static reachable addresses is pretty handy too.
Hi Mike,
Suppose I have a firewall at 2602:815:6000::1 with an internal network of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to disallow all Internet packets to 2602:815:6001::/64 that are not part of an established connection.
Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked.
Now suppose I have a firewall at 199.33.225.1 with an internal network of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to do NAT translation from 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which also has the effect of disallowing inbound packets to 192.168.55.0/24 which are not part of an established connection.
Someone tries to telnet to 192.168.55.4. What happens? The packet never even reaches my firewall because that IP address doesn't go anywhere on the Internet.
Now I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 192.168.55.4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 192.168.55.4. What happens? The packet STILL doesn't reach my firewall because that IP address doesn't go anywhere on the Internet.
See the difference? Accessible versus accessible and addressable. Not addressable enhances security.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, Feb 16, 2024 at 5:45 PM <sronan@ronan-online.com> wrote:
Why is your Internal v6 subnet advertised to the Internet?
Because that was the example network -without- NAT. If I made two networks -with- NAT, there would be no difference to show. I make 2602:815:6000::/44 be 199.33.224.0/23, make 2602:815:6001::/64 be 199.33.224.0/24, make 2602:815:600::1 be 199.33.225.1 and make 2602:815:6001::4 be 199.33.224.4, it would be the exact same example with the exact same network security impact. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
sronan, A subnet can come from the ISP (residential/small business), or business is utilizing BGP with their upstream. When V6 is in use, a firewall does not need to perform NAT, just stateful flow inspection and applying the applicable rules based on the zone and/or interface. Bill, Depending on where that rule is placed within your ACL, yes that can happen with *ANY* address family. --- All things aside, I agree with Dan that NAT was never ever designed to be a security tool. It is used because of the scarcity of public address space, and it provides a "defense" depending on how it is implemented, with minimal effort. This video tells the story of NAT and the Cisco PIX, straight from the creators https://youtu.be/GLrfqtf4txw Ryan Hamel ________________________________ From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of sronan@ronan-online.com <sronan@ronan-online.com> Sent: Friday, February 16, 2024 5:44 PM To: William Herrin <bill@herrin.us> Cc: nanog@nanog.org <nanog@nanog.org> Subject: Re: IPv6 uptake (was: The Reg does 240/4) Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Why is your Internal v6 subnet advertised to the Internet?
On Feb 16, 2024, at 8:08 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas <mike@mtcc.com> wrote:
If you know which subnets need to be NAT'd don't you also know which ones shouldn't exposed to incoming connections (or conversely, which should be permitted)? It seems to me that all you're doing is moving around where that knowledge is stored? Ie, DHCP so it can give it private address rather than at the firewall knowing which subnets not to allow access? Yes, DHCP can be easily configured to make everything private, but DHCP for static reachable addresses is pretty handy too.
Hi Mike,
Suppose I have a firewall at 2602:815:6000::1 with an internal network of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to disallow all Internet packets to 2602:815:6001::/64 that are not part of an established connection.
Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked.
Now suppose I have a firewall at 199.33.225.1 with an internal network of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to do NAT translation from 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which also has the effect of disallowing inbound packets to 192.168.55.0/24 which are not part of an established connection.
Someone tries to telnet to 192.168.55.4. What happens? The packet never even reaches my firewall because that IP address doesn't go anywhere on the Internet.
Now I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 192.168.55.4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 192.168.55.4. What happens? The packet STILL doesn't reach my firewall because that IP address doesn't go anywhere on the Internet.
See the difference? Accessible versus accessible and addressable. Not addressable enhances security.
Regards, Bill Herrin
On Fri, Feb 16, 2024 at 6:10 PM Ryan Hamel <ryan@rkhtech.org> wrote:
Depending on where that rule is placed within your ACL, yes that can happen with *ANY* address family.
Hi Ryan, Correct. The examples illustrated a difference between a firewall implementing address-overloaded NAT and a firewall implementing everything except the address translation. Either example could be converted to the other address family and it would work the same way.
All things aside, I agree with Dan that NAT was never ever designed to be a security tool. It is used because of the scarcity of public address space, and it provides a "defense" depending on how it is implemented, with minimal effort. This video tells the story of NAT and the Cisco PIX, straight from the creators https://youtu.be/GLrfqtf4txw
NAT's story, the modern version of NAT when we talk about IPv4 firewalls, started in the early '90s with the Gauntlet firewall. It was described as a transparent application layer gateway. Gauntlet focused on solving enterprise security issues. Gauntlet's technology converged with what was then 1:1 NAT to produce the address-overloaded NAT like what later appeared in the Cisco PIX (also first and foremost a security product) and is present in all our DSL and cable modems today. Security came first, then someone noticed it'd be useful for address conservation too. Gauntlet's customers generally had or could readily get a supply of public IP addresses. Indeed, when Gauntlet was released, IP addresses were still available from hostmaster@internic.net at zero cost and without any significant documentation. And Gauntlet was expensive: folks who couldn't easily obtain public IP addresses also couldn't afford it. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 2/16/24 6:33 PM, William Herrin wrote:
On Fri, Feb 16, 2024 at 6:10 PM Ryan Hamel <ryan@rkhtech.org> wrote:
Depending on where that rule is placed within your ACL, yes that can happen with *ANY* address family. Hi Ryan,
Correct. The examples illustrated a difference between a firewall implementing address-overloaded NAT and a firewall implementing everything except the address translation. Either example could be converted to the other address family and it would work the same way.
All things aside, I agree with Dan that NAT was never ever designed to be a security tool. It is used because of the scarcity of public address space, and it provides a "defense" depending on how it is implemented, with minimal effort. This video tells the story of NAT and the Cisco PIX, straight from the creators https://youtu.be/GLrfqtf4txw NAT's story, the modern version of NAT when we talk about IPv4 firewalls, started in the early '90s with the Gauntlet firewall. It was described as a transparent application layer gateway. Gauntlet focused on solving enterprise security issues. Gauntlet's technology converged with what was then 1:1 NAT to produce the address-overloaded NAT like what later appeared in the Cisco PIX (also first and foremost a security product) and is present in all our DSL and cable modems today.
Security came first, then someone noticed it'd be useful for address conservation too. Gauntlet's customers generally had or could readily get a supply of public IP addresses. Indeed, when Gauntlet was released, IP addresses were still available from hostmaster@internic.net at zero cost and without any significant documentation. And Gauntlet was expensive: folks who couldn't easily obtain public IP addresses also couldn't afford it.
Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT. That was sort of the go-to book for hard-on-the-outside soft-on-the-inside defense. Maybe they were unaware of this, or maybe they didn't agree with the premise. I didn't hear about NAT until the late 90's, iirc. I've definitely not heard of Gauntlet. As I recall, it was very much an afterthought with cable/DOCSIS to use NAT to conserve addresses. The headend DHCP server just gave public addresses to whoever asked. DOCSIS CPE at that time was just an L2 modem. NAT traversal absolutely was not on the table with Packetcable back in the late 90's, and believe me we were very concerned about the security of MGCP since it was UDP based. Which is to say that NAT came around to preserve address space. Any security properties were sort of a post-hoc rationalization and hotly debated given all the things NAT broke. Mike
On Sat, Feb 17, 2024 at 10:34 AM Michael Thomas <mike@mtcc.com> wrote:
I didn't hear about NAT until the late 90's, iirc. I've definitely not heard of Gauntlet.
Then there are gaps in your knowledge.
Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT.
And mine too, since I hadn't heard of "Firewalls and Internet Security: Repelling the Wily Hacker" and have not read it. I see that the book was published in 1994. In 1994 Gauntlet was calling their process "transparent application layer gateways," not NAT. What was called NAT in 1994 was stateless 1:1 NAT, where one IP mapped to exactly one IP in both directions. Stateless 1:1 NAT had no impact on security. But that's not the technology we're talking about in 2024. Stateless 1:1 NAT is so obsolete that support was dropped from the Linux kernel a long time ago. That actually caused a problem for me in 2017. I had a use where I wanted 1:1 NAT and wanted to turn off connection tracking so that I could do asymmetric routing through the stateless translators. No go. So it does not surprise me that a 1994 book on network security would not have discussed NAT. They'd have referred to the comparable contemporary technology, which was "transparent application layer gateways." Those behaved like what we now call NAT but did the job a different way: instead of modifying packets, they terminated the connection and proxied it. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 17/02/2024, 19:27:20, "William Herrin" <bill@herrin.us> wrote:
So it does not surprise me that a 1994 book on network security would not have discussed NAT. They'd have referred to the comparable contemporary technology, which was "transparent application layer gateways." Those behaved like what we now call NAT but did the job a different way: instead of modifying packets, they terminated the connection and proxied it.
And that was a very desired feature plus the address isolation, then and for decades since. The clients IP stack was not trusted to interact directly with external hosts. See socks proxy too (and later Squid). It is still in use today in some places. There were stateful firewalls but trust was reduced when the Firewall 1 undocumented and not unconfigurable default DNS UDP inbound rule was discovered, it let anyone on the Internets "DNS" packets reach any host on the inside they could guess the address of. The "what if the product does allow packets in it is expected not to" consideration drove having unreachable internal addressing. Clicking on rules and assuming it is all good forever more through product revisions was not sufficient. Every version would need a significant re audit and probably miss any real problem. How are people validating their firewall does what they think it does? brandon
On Feb 17, 2024, at 11:27 AM, William Herrin <bill@herrin.us> wrote:
On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas <mike at mtcc.com> wrote:
Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT.
And mine too, since I hadn't heard of "Firewalls and Internet Security: Repelling the Wily Hacker" and have not read it.
For what it's worth, both editions of Bellovin and Cheswick's Firewalls book are online. [1] Also, there are discussions about NAT and how it influenced IPng (eventually IPv6) on the big-internet list. [2] —gregbo [1] https://www.wilyhacker.com [2] https://mailarchive.ietf.org/arch/browse/big-internet/
On 2/18/24 8:47 AM, Greg Skinner via NANOG wrote:
On Feb 17, 2024, at 11:27 AM, William Herrin <bill@herrin.us> wrote:
On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas <mike at mtcc.com> wrote:
Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT. And mine too, since I hadn't heard of "Firewalls and Internet Security: Repelling the Wily Hacker" and have not read it. For what it's worth, both editions of Bellovin and Cheswick's Firewalls book are online. [1] Also, there are discussions about NAT and how it influenced IPng (eventually IPv6) on the big-internet list. [2]
FWIW, while at Cisco I started to get wind of some NAT-like proposal being floated by 3COM at Packetcable back in the late 90's, early 2000's (sorry, I have no memory of the specifics now). That was pretty horrifying to me and others as the implication was that we'd have to implement it in our routers, which I'm sure 3COM viewed as a feature, not a bug. We pushed back that implementing IPv6 was a far better option if it came down to that. That sent me and Steve Deering off on an adventure to figure out how we might actually make good on that alternative in the various service provider BU's. Unsurprisingly the BU's were not very receptive not just because of the problems with v6 vs hardware forwarding, but mostly because providers weren't asking for it. They weren't asking for CGNAT like things either though so it was mostly the status quo. IOS on the other hand was taking IPv6 much more seriously so that providers could at least deploy it in the small for testing, pilots, etc even if it was a patchwork in the various platforms. The problem with v6 uptake has always been on the provider side. BU's wouldn't have wanted to respin silicon but if providers were asking for it and it gave them a competitive advantage, they'd have done it in a heartbeat. It's heartening to hear that a lot of big providers and orgs are using IPv6 internally to simplify management along with LTE's use of v6. I don't know what's happening in MSO land these days, but it would be good to hear if they too are pushing a LTE-like solution. I do know that Cablelabs pretty early on -- around the time I mentioned above -- has been pushing for v6. Maybe Jason Livingood can clue us in. Getting cable operators onboard too would certainly be a good thing, though LTE doesn't have to deal with things like brain dead v4-only wireless routers on their network. Mike
Michael Thomas wrote on 18/02/2024 20:28:
I do know that Cablelabs pretty early on -- around the time I mentioned above -- has been pushing for v6. Maybe Jason Livingood can clue us in. Getting cable operators onboard too would certainly be a good thing,
availability of provider-side ipv6 support is generally excellent on docsis networks. This includes end-user device support, management, client and server side provisioning, the works. This is one of the real ipv6 success stories in the service provider arena. Nick
On 2/18/24 12:50 PM, Nick Hilliard wrote:
Michael Thomas wrote on 18/02/2024 20:28:
I do know that Cablelabs pretty early on -- around the time I mentioned above -- has been pushing for v6. Maybe Jason Livingood can clue us in. Getting cable operators onboard too would certainly be a good thing,
availability of provider-side ipv6 support is generally excellent on docsis networks. This includes end-user device support, management, client and server side provisioning, the works. This is one of the real ipv6 success stories in the service provider arena.
That's really great to hear. Of course there is still the problem with CPE that doesn't speak v6, but that's not their fault and gives some reason to use their CPE. Mike
Michael Thomas wrote on 18/02/2024 20:56:
That's really great to hear. Of course there is still the problem with CPE that doesn't speak v6, but that's not their fault and gives some reason to use their CPE.
Already solved: cable modem ipv6 support is usually also excellent, both in terms of subscriber services handoff and management. The requirements for ipv6 support are very clearly defined in the cablelabs docsis 3.0 specification. Nick
On 2/18/24 1:10 PM, Nick Hilliard wrote:
Michael Thomas wrote on 18/02/2024 20:56:
That's really great to hear. Of course there is still the problem with CPE that doesn't speak v6, but that's not their fault and gives some reason to use their CPE.
Already solved: cable modem ipv6 support is usually also excellent, both in terms of subscriber services handoff and management. The requirements for ipv6 support are very clearly defined in the cablelabs docsis 3.0 specification.
So it has its own wireless? I seem to recall that there were some economic reasons to use their CPE as little as possible to avoid rent. Has that changed? Or can I run down and just buy a Cablelabs certified router/modem these days? Mike
Michael Thomas wrote on 18/02/2024 21:18:
So it has its own wireless? I seem to recall that there were some economic reasons to use their CPE as little as possible to avoid rent. Has that changed? Or can I run down and just buy a Cablelabs certified router/modem these days?
There's no short answer to this question. A third party cable modem will work with a basic CM config file if you can convince the cable operator to provision the device, but cable operators don't like running third party kit on their network for a lot of reasons. One of these reasons is bandwidth channel utilisation. Another is support. Another would be software upgrades, which can lead to issues with security. Also, if you use a vanilla cable modem config, you miss out on many of the more interesting configurable bits on cable modems. The root issue here is that cable networks are shared resources, and the cable modem polices the customers' bandwidth utilisation on instruction from the CMTS (head-end cable router) and the provisioning system. The system works well from a technical perspective when the operator has full control of all modems and they're all relatively recent, properly supported units, fully managed by the cable operator. If you start adding poor quality cheap units into the mix, it can cause service problems. For example, some cable modems provide basic spectrum analysers on the provider interface (yes, cable operators can remotely log in to cable modems) and good quality reporting about RF noise. If you get some hobbyist demanding to use their own modem, and then you run into an RF problem at their premises which could normally be diagnosed remotely using the internal cable modem diagnostics, but you can't do this because the customer has used their own kit which doesn't support this, then you've instantly driven up your cost of service because now you need to schedule a call-out for something which could previously have been diagnosed remotely. So you can see why this might be frustrating for the cable modem operator. Cable modem rent is a political issue. Nick
It appears that Nick Hilliard <nick@foobar.org> said:
full control of all modems and they're all relatively recent, properly supported units, fully managed by the cable operator. If you start adding poor quality cheap units into the mix, it can cause service problems.
The cablecos I've dealt with have a list of modems they let you use. Since you have to give them the modem's serial number so they can provision it from the head end, they can enforce it. Here's Spectrum's and Comcast's list: https://www.spectrum.net/support/internet/compliant-modems-charter-network https://www.xfinity.com/support/devices/
Cable modem rent is a political issue.
That too, but if you're somewhat technically competent, your own modem and router is generally a better deal even if you have to replace the modem every few years. You can get reasonable modems for $100 on eBay or at big box closeouts, $150 to $200 otherwise.
If you ever want to know which providers in a country are lagging, Geoff Huston is here to help: https://stats.labs.apnic.net/ipv6/US In the U.S., the largest operators without IPv6 are (in order by size): Verizon FiOS (they deployed to 50%, discovered a bug, and rolled back) Frontier Lumen (CenturyLink) CableVision CableOne Suddenlink Windstream US Cellular Brightspeed Comcast, Charter, and Cox each have fully deployed IPv6, along with AT&T and all of the mobile carriers. Lee -----Original Message----- From: NANOG <nanog-bounces+leehoward=hilcostreambank.com@nanog.org> On Behalf Of Michael Thomas Sent: Sunday, February 18, 2024 3:29 PM To: nanog@nanog.org Subject: Re: IPv6 uptake (was: The Reg does 240/4) [You don't often get email from mike@mtcc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments. On 2/18/24 8:47 AM, Greg Skinner via NANOG wrote:
On Feb 17, 2024, at 11:27 AM, William Herrin <bill@herrin.us> wrote:
On Sat, Feb 17, 2024 at 10:34?AM Michael Thomas <mike at mtcc.com> wrote:
Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT. And mine too, since I hadn't heard of "Firewalls and Internet Security: Repelling the Wily Hacker" and have not read it. For what it's worth, both editions of Bellovin and Cheswick's Firewalls book are online. [1] Also, there are discussions about NAT and how it influenced IPng (eventually IPv6) on the big-internet list. [2]
FWIW, while at Cisco I started to get wind of some NAT-like proposal being floated by 3COM at Packetcable back in the late 90's, early 2000's (sorry, I have no memory of the specifics now). That was pretty horrifying to me and others as the implication was that we'd have to implement it in our routers, which I'm sure 3COM viewed as a feature, not a bug. We pushed back that implementing IPv6 was a far better option if it came down to that. That sent me and Steve Deering off on an adventure to figure out how we might actually make good on that alternative in the various service provider BU's. Unsurprisingly the BU's were not very receptive not just because of the problems with v6 vs hardware forwarding, but mostly because providers weren't asking for it. They weren't asking for CGNAT like things either though so it was mostly the status quo. IOS on the other hand was taking IPv6 much more seriously so that providers could at least deploy it in the small for testing, pilots, etc even if it was a patchwork in the various platforms. The problem with v6 uptake has always been on the provider side. BU's wouldn't have wanted to respin silicon but if providers were asking for it and it gave them a competitive advantage, they'd have done it in a heartbeat. It's heartening to hear that a lot of big providers and orgs are using IPv6 internally to simplify management along with LTE's use of v6. I don't know what's happening in MSO land these days, but it would be good to hear if they too are pushing a LTE-like solution. I do know that Cablelabs pretty early on -- around the time I mentioned above -- has been pushing for v6. Maybe Jason Livingood can clue us in. Getting cable operators onboard too would certainly be a good thing, though LTE doesn't have to deal with things like brain dead v4-only wireless routers on their network. Mike
On Mon, Feb 19, 2024 at 5:29 AM Howard, Lee via NANOG <nanog@nanog.org> wrote:
In the U.S., the largest operators without IPv6 are (in order by size): Lumen (CenturyLink)
CenturyLink has IPv6 using 6rd. It works fine. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 2/17/24 11:27 AM, William Herrin wrote:
On Sat, Feb 17, 2024 at 10:34 AM Michael Thomas <mike@mtcc.com> wrote:
I didn't hear about NAT until the late 90's, iirc. I've definitely not heard of Gauntlet. Then there are gaps in your knowledge.
Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT. And mine too, since I hadn't heard of "Firewalls and Internet Security: Repelling the Wily Hacker" and have not read it.
I see that the book was published in 1994. In 1994 Gauntlet was calling their process "transparent application layer gateways," not NAT.
What was called NAT in 1994 was stateless 1:1 NAT, where one IP mapped to exactly one IP in both directions. Stateless 1:1 NAT had no impact on security. But that's not the technology we're talking about in 2024. Stateless 1:1 NAT is so obsolete that support was dropped from the Linux kernel a long time ago. That actually caused a problem for me in 2017. I had a use where I wanted 1:1 NAT and wanted to turn off connection tracking so that I could do asymmetric routing through the stateless translators. No go.
So it does not surprise me that a 1994 book on network security would not have discussed NAT. They'd have referred to the comparable contemporary technology, which was "transparent application layer gateways." Those behaved like what we now call NAT but did the job a different way: instead of modifying packets, they terminated the connection and proxied it.
I don't recall the book talking about proxies, but it's been a long time. It was mostly about (stateful) firewalls, iirc. The rapid expansion of the internet caused a huge need for a big band-aid, especially with shitty windows boxes emerging on the net shortly after. A stateful firewall walled off for incoming on client subnets was perfectly sufficient though, and need to provision clients with proxies and the necessary software. The book is not very long and honestly that's a feature as it seemed to mostly be trying to get the word out that we should be protecting ourselves at the borders until better security could get deployed. If NAT's supposed belt and suspenders security was such a big feature, I don't recall anybody talking about it that way back then. That's why it's always seemed like a post-hoc rationalization. When I was at Cisco, all of the internal networks were numbered in public address space and I never once heard any clamor for the client space to be renumbered into RFC 1918 space for security reasons. Admittedly anybody doing so would have faced fierce resistance, but if there were any debate at all it was that adding state to network flows was a Bad Thing. NAT has always been about overloading public IP addresses first and foremost. The supposed security gains are vastly dwarfed by the decrease in functionality that NAT brings with it. One only has to look at the mental gymnastics that goes into filling out SDP announcements for VoIP to know that any supposed security benefits are not worth the trouble that it brings. If it were only security, nobody would have done it. It was always about address conservation first and foremost. Mike
It appears that William Herrin <bill@herrin.us> said:
Now suppose I have a firewall at 199.33.225.1 with an internal network of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to do NAT translation from 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which also has the effect of disallowing inbound packets to 192.168.55.0/24 which are not part of an established connection.
Or you set up port forwarding for some other device but you mistype the internal address an forward it to the switch. Or the switch helpfully uses UPNP to do its own port forwarding and you forget to turn it off. If you configure your firewall wrong, bad things will happen. I have both IPv6 and NAT IPv4 on my network here and I haven't found it particularly hard to get the config correct for IPv6. Normally the ISP will give you an IPv6 /56 or larger so you can have multiple segments behind the router each with a /64 and different policies for each segment.
On Fri, Feb 16, 2024 at 7:10 PM John Levine <johnl@iecc.com> wrote:
If you configure your firewall wrong, bad things will happen. I have both IPv6 and NAT IPv4 on my network here and I haven't found it particularly hard to get the config correct for IPv6.
Hi John, That it's possible to implement network security well without using NAT does not contradict the claim that NAT enhances network security. That it's possible to breach the layer of security added by NAT does not contradict the claim that NAT enhances network security. Any given layer of security can be breached with expense and effort. Breaching every layer of security at the same time is more challenging than breaching any particular one of them. The use of NAT adds a layer of security to the system that is not otherwise there. Think of it like this: you have a guard, you have a fence and you have barbed wire on top of the fence. Can you secure the place without the barbed wire? Of course. Can an intruder defeat the barbed wire? Of course. Is it more secure -with- the barbed wire? Obviously. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
That it's possible to implement network security well without using NAT does not contradict the claim that NAT enhances network security.
I think we're each overgeneralizing from our individual expeience. You can configure a V6 firewall to be default closed as easily as you can configure a NAT. Once you start making exceptions, it depends on the nature of the exceptions, the way you tell the router about them (CLI, web crudware, whatever) and doubtless other stuff too. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On Fri, Feb 16, 2024 at 7:41 PM John R. Levine <johnl@iecc.com> wrote:
That it's possible to implement network security well without using NAT does not contradict the claim that NAT enhances network security.
I think we're each overgeneralizing from our individual expeience.
You can configure a V6 firewall to be default closed as easily as you can configure a NAT.
Hi John, We're probably not speaking the same language. You're talking about configuring the function of one layer in a security stack. I'm talking about adding or removing a layer in a security stack. Address overloaded NAT in conjunction with private internal addresses is an additional layer in a security stack. It has security-relevant properties that the other layers don't duplicate. Regardless of how you configure it. Also, you can't "configure" a layer to be default closed. That's a property of the security layer. It either is or it is not. You can configure a layer to be "default deny," which I assume is what you meant. The issue is that anything that can be configured can be accidentally unconfigured. When default-deny is accidentally unconfigured, the network becomes wide open. When NAT is accidentally unconfigured, the network stops functioning entirely. The gate is closed. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Again Bill, the NAT process layer is not involved in dropping unwanted traffic until the packet is at least four/five levels deep. On ingress, a firewall will check if there is any flow/stream associated to it, ensure the packet follows the applicable protocol state machine, process it against the inbound interface rules, do any DPI rule processing, THEN NAT lookup, and egress routing + ACLs on the outbound ACL. https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-g... On a standard LAN -> WAN firewall configured with a single public IPv4 IP; your protection comes from the connect state/flow tables primarily. No one would be touching NAT configurations at the same rate as zone and policy configurations, unless it's for complex VPN setups. Using NAT as a defense in depth strategy against deploying v6 is only hurting yourself. I have yet to come across an enterprise that uses it between internal VLANs or policies/zones, where the same threat potential can be, especially in a DMZ. Ryan Hamel ________________________________ From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of William Herrin <bill@herrin.us> Sent: Friday, February 16, 2024 8:03 PM To: John R. Levine <johnl@iecc.com> Cc: nanog@nanog.org <nanog@nanog.org> Subject: Re: IPv6 uptake (was: The Reg does 240/4) Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On Fri, Feb 16, 2024 at 7:41 PM John R. Levine <johnl@iecc.com> wrote:
That it's possible to implement network security well without using NAT does not contradict the claim that NAT enhances network security.
I think we're each overgeneralizing from our individual expeience.
You can configure a V6 firewall to be default closed as easily as you can configure a NAT.
Hi John, We're probably not speaking the same language. You're talking about configuring the function of one layer in a security stack. I'm talking about adding or removing a layer in a security stack. Address overloaded NAT in conjunction with private internal addresses is an additional layer in a security stack. It has security-relevant properties that the other layers don't duplicate. Regardless of how you configure it. Also, you can't "configure" a layer to be default closed. That's a property of the security layer. It either is or it is not. You can configure a layer to be "default deny," which I assume is what you meant. The issue is that anything that can be configured can be accidentally unconfigured. When default-deny is accidentally unconfigured, the network becomes wide open. When NAT is accidentally unconfigured, the network stops functioning entirely. The gate is closed. Regards, Bill Herrin -- William Herrin bill@herrin.us https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbill.herrin.us%2F&data=05%7C02%7Cryan%40rkhtech.org%7C0de6c54d274c4b231dc608dc2f6dc319%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638437395698409506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k19sefOjlCNOBGbiAmhzcFszrOEhf8SQQfs0MQThyaU%3D&reserved=0<https://bill.herrin.us/>
We went pretty deep into the weeds on NAT in this thread - far deeper than I expected ;) Getting back to the recently revised topic of this thread - IPv6 uptake - what have peoples' experiences been related to crafting sane v6 firewall rulesets in recent products from the major firewall players (Palo Alto, Cisco, Fortinet, etc)? On the last major v6 deployment I did, working with the firewalls was definitely one of the major pain points because the support / stability was really lacking, or there wasn't full feature parity between their v4 and v6 capabilities. Thank you jms On Fri, Feb 16, 2024 at 11:04 PM William Herrin <bill@herrin.us> wrote:
On Fri, Feb 16, 2024 at 7:41 PM John R. Levine <johnl@iecc.com> wrote:
That it's possible to implement network security well without using NAT does not contradict the claim that NAT enhances network security.
I think we're each overgeneralizing from our individual expeience.
You can configure a V6 firewall to be default closed as easily as you can configure a NAT.
Hi John,
We're probably not speaking the same language. You're talking about configuring the function of one layer in a security stack. I'm talking about adding or removing a layer in a security stack. Address overloaded NAT in conjunction with private internal addresses is an additional layer in a security stack. It has security-relevant properties that the other layers don't duplicate. Regardless of how you configure it.
Also, you can't "configure" a layer to be default closed. That's a property of the security layer. It either is or it is not.
You can configure a layer to be "default deny," which I assume is what you meant. The issue is that anything that can be configured can be accidentally unconfigured. When default-deny is accidentally unconfigured, the network becomes wide open. When NAT is accidentally unconfigured, the network stops functioning entirely. The gate is closed.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sat, Feb 17, 2024 at 10:22 AM Justin Streiner <streinerj@gmail.com> wrote:
Getting back to the recently revised topic of this thread - IPv6 uptake - what have peoples' experiences been related to crafting sane v6 firewall rulesets in recent products from the major firewall players (Palo Alto, Cisco, Fortinet, etc)?
Hi Justin, It's been years since I used anything other than Linux to build someone a firewall. It has such a superior toolset, not just for setting rules but for diagnosing things that don't work as expected. The COTS products aren't just painful for IPv6, they're painful for IPv4. I especially despised the Cisco PIX/ASA line. I did use Fortinet's WAF product for a while and it was okay. I only used it as a reverse proxy to a web server, and then only because it was a security compliance requirement for that project. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Concerning the firewall book. Firewalls and Internet Security, Second Edition PDF online at https://www.wilyhacker.com/fw2e.pdf "Some people think that NAT boxes are a form of firewall. In some sense, they are, but they're low-end ones."
On 2/17/24 10:22 AM, Justin Streiner wrote:
Getting back to the recently revised topic of this thread - IPv6 uptake - what have peoples' experiences been related to crafting sane v6 firewall rulesets in recent products from the major firewall players (Palo Alto, Cisco, Fortinet, etc)? On the last major v6 deployment I did, working with the firewalls was definitely one of the major pain points because the support / stability was really lacking, or there wasn't full feature parity between their v4 and v6 capabilities.
Depends on how complex you want to be with firewall rules. My web server is on Ubuntu 20.04. During the IPv4-only days, I used UFW (uncomplicated firewall) to implement a mostly-closed firewall, punching pin-holes for 80 and 443, and disable any interface forwarding. When I upgraded to IPv4 and IPv6, the process of duplicating the policy in IPv6 was easy. The UFW package is built on top of IPTABLES and IP6TABLES. Now, my edge router is going to be a different story. As the number of rules goes up, UFW becomes tedious and finicky. Manually crafting rules in NFT is tedious and error-prone. Getting all the rules right the first time is, um, hard. Automation is absolutely required. So I'm writing the automation in Python, and driving the rules generator from a YAML database. Expect this to be published on Github. When? Depends on when I find the time. This is not a priority project -- I'm so mad at my upstream that I find playing Mahjongg is necessary to settle my nerves. I've said this earlier: by the time the NEED for IPv6 arises, I expect to be dead.
Any given layer of security can be breached with expense and effort. Breaching every layer of security at the same time is more challenging than breaching any particular one of them. The use of NAT adds a layer of security to the system that is not otherwise there.
Think of it like this: you have a guard, you have a fence and you have barbed wire on top of the fence. Can you secure the place without the barbed wire? Of course. Can an intruder defeat the barbed wire? Of course. Is it more secure -with- the barbed wire? Obviously.
Bill- In a security context, NAT/PAT only provides *obfuscation* of the internal numbering and source ports of the networks on the inside of the NAT/PAT device. "Security by obscurity" is a well debunked maxim by now. Any perceived benefits that obscurity provides are gone as soon as the information attempting to be hidden can be discovered, or the methods by which it functions are known. It may slightly deter the lazy, but techniques to discover the otherwise 'hidden' numbering and port usage have existed for decades. On Fri, Feb 16, 2024 at 10:28 PM William Herrin <bill@herrin.us> wrote:
On Fri, Feb 16, 2024 at 7:10 PM John Levine <johnl@iecc.com> wrote:
If you configure your firewall wrong, bad things will happen. I have both IPv6 and NAT IPv4 on my network here and I haven't found it particularly hard to get the config correct for IPv6.
Hi John,
That it's possible to implement network security well without using NAT does not contradict the claim that NAT enhances network security.
That it's possible to breach the layer of security added by NAT does not contradict the claim that NAT enhances network security.
Any given layer of security can be breached with expense and effort. Breaching every layer of security at the same time is more challenging than breaching any particular one of them. The use of NAT adds a layer of security to the system that is not otherwise there.
Think of it like this: you have a guard, you have a fence and you have barbed wire on top of the fence. Can you secure the place without the barbed wire? Of course. Can an intruder defeat the barbed wire? Of course. Is it more secure -with- the barbed wire? Obviously.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
Think of it like this: you have a guard, you have a fence and you have barbed wire on top of the fence. Can you secure the place without the barbed wire? Of course. Can an intruder defeat the barbed wire? Of course. Is it more secure -with- the barbed wire? Obviously.
NAT is like the barbed wire. Anyone with a pair of wire cutters doesn’t need to defeat the barbed wire, they just cut the fence instead. But I understand how the barbed wire makes you and management feel warm and fuzzy. The problem here is that NAT is also like a big blind spot in the video cameras that should be helping you spot the guy cutting the fence. Owen
Bill, same scenario, but instead of fat fingering an outbound rule, you fat finger a port map for inbound connections to a different host and get the destination address wrong. Still hacked. NAT doesn’t prevent fat fingers from getting you hacked, it just changes the nature of the required fat fingering. Care to talk about trying to track down a compromised host through the audit trail given an abuse report that doesn’t include the source port number? (Oracle even one that happens to include it)? Owen
On Feb 16, 2024, at 17:05, William Herrin <bill@herrin.us> wrote:
On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas <mike@mtcc.com> wrote:
If you know which subnets need to be NAT'd don't you also know which ones shouldn't exposed to incoming connections (or conversely, which should be permitted)? It seems to me that all you're doing is moving around where that knowledge is stored? Ie, DHCP so it can give it private address rather than at the firewall knowing which subnets not to allow access? Yes, DHCP can be easily configured to make everything private, but DHCP for static reachable addresses is pretty handy too.
Hi Mike,
Suppose I have a firewall at 2602:815:6000::1 with an internal network of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to disallow all Internet packets to 2602:815:6001::/64 that are not part of an established connection.
Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
Now, I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 2602:815:6001::4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 2602:815:6001::4. What happens? Hacked.
Now suppose I have a firewall at 199.33.225.1 with an internal network of 192.168.55.0/24. Inside the network on 192.168.55.4 I have a switch that accepts telnet connections with a user/password of admin/admin. On the firewall, I program it to do NAT translation from 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which also has the effect of disallowing inbound packets to 192.168.55.0/24 which are not part of an established connection.
Someone tries to telnet to 192.168.55.4. What happens? The packet never even reaches my firewall because that IP address doesn't go anywhere on the Internet.
Now I make a mistake on my firewall. I insert a rule intended to allow packets outbound from 192.168.55.4 but I fat-finger it and so it allows them inbound to that address instead. Someone tries to telnet to 192.168.55.4. What happens? The packet STILL doesn't reach my firewall because that IP address doesn't go anywhere on the Internet.
See the difference? Accessible versus accessible and addressable. Not addressable enhances security.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
Bottom-posted with old school formatting by hand. -----Original Message----- From: NANOG <nanog-bounces+leehoward=hilcostreambank.com@nanog.org> On Behalf Of William Herrin Sent: Friday, February 16, 2024 8:05 PM To: Michael Thomas <mike@mtcc.com> Cc: nanog@nanog.org Subject: Re: IPv6 uptake (was: The Reg does 240/4)
On the firewall, I program it to do NAT translation from 192.168.55.0/24 to 199.33.225.1 when sending packets outbound, which also has the effect of disallowing inbound packets to 192.168.55.0/24 which are not part of an established connection.
Someone tries to telnet to 192.168.55.4. What happens? The packet never even reaches my firewall because that IP address doesn't go anywhere on the Internet.
Most NATs I've seen in the last 10-15 years are "full cone" NATs: they are configured so that once there is an outbound flow, and inbound datagram to that address+port will be forwarded to the inside address, regardless of source. Most devices now have a more or less constant flow of heartbeats or updates to somewhere on the Internet. In practice, NAPT just increases the size of the space to scan: just dump your crafted packets to every address + every port at your target. If that increased scanning target is your security, you're better off with the increased target of IPv6. IT administrators don't usually know what kind of NAT they have deployed. FWIW, the other enterprise IT security hole I often see: if your VPN is IPv6-unaware, but your users have IPv6 at home (like most in the U.S.), your VPN is now split-tunnel, regardless of policy. You may think all your packets are going through the VPN to be inspected by the corporate firewall, but any web site with IPv6 (about half) will use the local residential route, not the VPN. Lee
On Mon, Feb 19, 2024 at 6:02 AM Howard, Lee <LeeHoward@hilcostreambank.com> wrote:
Most NATs I've seen in the last 10-15 years are "full cone" NATs: they are configured so that once there is an outbound flow, and inbound datagram to that address+port will be forwarded to the inside address, regardless of source.
Hi Lee, Yes, they do that to help with NAT traversal. This allows two hosts behind separate NATs to establish direct communication with the help of an external server in the establishment phase. The flip side is that your internal hosts are limited to 65k established connections between them or the firewall exhausts its available ports. Without full cone, the number of translations that NAT can do is bounded only by its available RAM.
NAPT just increases the size of the space to scan: just dump your crafted packets to every address + every port at your target.
Not quite. Full cone slightly reduces NAT's positive security impact. But only slightly. An external source can poke at an internal host on the specific port where the internal host has established an outbound connection, but it can't poke the internal host on any other ports where services might actually be running and waiting for connections.
FWIW, the other enterprise IT security hole I often see: if your VPN is IPv6-unaware, but your users have IPv6 at home (like most in the U.S.), your VPN is now split-tunnel, regardless of policy. You may think all your packets are going through the VPN to be inspected by the corporate firewall, but any web site with IPv6 (about half) will use the local residential route, not the VPN.
Yep. Folks who built their security for remote users around the idea of preventing split-tunnels have done the job so very wrong. Another fun thing you can do in Linux is run the VPN software inside a network namespace. The VPN happily takes over the namespace and any software you run inside the namespace, but the rest of the host remains on the public Internet. You can also run the VPN in a VM that shares mounts and clipboard with the host. Regards, Bill Herrin
Lee
-- William Herrin bill@herrin.us https://bill.herrin.us/
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth <jra@baylink.com> wrote:
From: "Justin Streiner" <streinerj@gmail.com> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world.
NAT doesn't "equal" security.
But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside.
Every firewall does that. What NAT does above and beyond is place control of what internal nodes are -addressable- from the outside in the hands of the people inside -- so that most of the common mistakes with firewall configuration don't cause the internal hosts to -become- accessible.
The distinction doesn't seem that subtle to me, but a lot of folks making statements about network security on this list don't appear to grasp it.
You bet. I knew someone would chime in, but whether they'd be agreeing with me -- as you are -- or yelling at me, wasn't clear. It's a default deny (NAT) vs default allow (firewall) question, and I prefer default deny -- at least inbound. You *can* run NAT as default deny outbound, too, but it's much less tolerable for general internet connectivity -- in some dedicated circumstances, it can be workable. 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
Most firewalls are default deny. Routers are default allow unless you put a filter on the interface. NAT adds nothing to security (Bill and I agree to disagree on this), but at best, it complicates the audit trail. Owen
On Feb 16, 2024, at 15:19, Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth <jra@baylink.com> wrote:
From: "Justin Streiner" <streinerj@gmail.com> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world.
NAT doesn't "equal" security.
But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside.
Every firewall does that. What NAT does above and beyond is place control of what internal nodes are -addressable- from the outside in the hands of the people inside -- so that most of the common mistakes with firewall configuration don't cause the internal hosts to -become- accessible.
The distinction doesn't seem that subtle to me, but a lot of folks making statements about network security on this list don't appear to grasp it.
You bet. I knew someone would chime in, but whether they'd be agreeing with me -- as you are -- or yelling at me, wasn't clear.
It's a default deny (NAT) vs default allow (firewall) question, and I prefer default deny -- at least inbound. You *can* run NAT as default deny outbound, too, but it's much less tolerable for general internet connectivity -- in some dedicated circumstances, it can be workable.
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 Sun, 18 Feb 2024, 05:29 Owen DeLong via NANOG, <nanog@nanog.org> wrote:
Most firewalls are default deny. Routers are default allow unless you put a filter on the interface.
This is not relevant though. NAT when doing port overloading, as is the case for most CPE, is not default-deny or default-allow. The OS processes the packet just like normal and sends an ICMP back unless there is another firewall that says drop. NAPT adds temporary rewrite rules for each flow that goes outbound. NAT adds nothing to security (Bill and I agree to disagree on this), but at
best, it complicates the audit trail.
It absolutely does add something. Whether that something is valuable or not depends on your vantage point, and I'd say it's better than nothing, but there are better solutions available. M
a lot of folks making statements about network security on this list don't appear to grasp it.
If your network is secure, it isn’t even possible to “accidentally” open inbound ports in the first place. You either allow it to happen or you don’t via security policy, anything else means your “security” relies on humans not making a mistake, and that’s not security. Using NAT as a “line of defense” means you implicitly don’t trust your authorization system, which means you don't actually have a security posture to begin with. Using the same logic, you might as well go buy another firewall to put in front of your actual Firewall just in case you accidentally misconfigure it. Notice how you’re not actually securing anything, you’re putting a band aid on your insecure process. -Dan
On Feb 16, 2024, at 18:04, William Herrin <bill@herrin.us> wrote:
On Fri, Feb 16, 2024 at 2:19 PM Jay R. Ashworth <jra@baylink.com> wrote:
From: "Justin Streiner" <streinerj@gmail.com> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world.
NAT doesn't "equal" security.
But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside.
Hi Jay,
Every firewall does that. What NAT does above and beyond is place control of what internal nodes are -addressable- from the outside in the hands of the people inside -- so that most of the common mistakes with firewall configuration don't cause the internal hosts to -become- accessible.
The distinction doesn't seem that subtle to me, but a lot of folks making statements about network security on this list don't appear to grasp it.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Feb 16, 2024, at 14:20, Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Justin Streiner" <streinerj@gmail.com>
4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world.
NAT doesn't "equal" security.
But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside.
Uh, no… no it is not. Stateful inspection (which the kind of NAT (actually NAPT) you are assuming here depends on) is a component of security. You can do stateful inspection without mutilating the header and have all the same security benefits without losing or complicating the audit trail. Owen
On 2/17/24 10:26 AM, Owen DeLong via NANOG wrote:
On Feb 16, 2024, at 14:20, Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Justin Streiner" <streinerj@gmail.com> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world. NAT doesn't "equal" security.
But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside. Uh, no… no it is not. Stateful inspection (which the kind of NAT (actually NAPT) you are assuming here depends on) is a component of security. You can do stateful inspection without mutilating the header and have all the same security benefits without losing or complicating the audit trail.
Exactly. As I said elsewhere, the security properties of NAT were a post-hoc rationalization. In the mean time, it has taken on its own life as if not NAT'ing (but still having stateful firewalls) would end the known security universe. We can seriously lose NAT for v6 and not lose anything of worth. Mike
" We can seriously lose NAT for v6 and not lose anything of worth." I'm not going to participate in the security conversation, but we do absolutely need something to fill the role of NAT in v6. If it's already there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a down Internet connection to prevent transactions from completing, so he purchases two diverse broadband connections, say a cable connection and a DSL connection. When ISP fails, traffic will have to exit ISP B. He's not getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do simple NAT. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Michael Thomas" <mike@mtcc.com> To: nanog@nanog.org Sent: Saturday, February 17, 2024 12:50:46 PM Subject: Re: IPv6 uptake On 2/17/24 10:26 AM, Owen DeLong via NANOG wrote:
On Feb 16, 2024, at 14:20, Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Justin Streiner" <streinerj@gmail.com> 4. Getting people to unlearn the "NAT=Security" mindset that we were forced to accept in the v4 world. NAT doesn't "equal" security.
But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside. Uh, no… no it is not. Stateful inspection (which the kind of NAT (actually NAPT) you are assuming here depends on) is a component of security. You can do stateful inspection without mutilating the header and have all the same security benefits without losing or complicating the audit trail.
Exactly. As I said elsewhere, the security properties of NAT were a post-hoc rationalization. In the mean time, it has taken on its own life as if not NAT'ing (but still having stateful firewalls) would end the known security universe. We can seriously lose NAT for v6 and not lose anything of worth. Mike
On Mon, Feb 19, 2024 at 6:52 AM Mike Hammett <nanog@ics-il.net> wrote:
"We can seriously lose NAT for v6 and not lose anything of worth."
I'm not going to participate in the security conversation, but we do absolutely need something to fill the role of NAT in v6. If it's already there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a down Internet connection to prevent transactions from completing, so he purchases two diverse broadband connections, say a cable connection and a DSL connection.
Hi Mike, In IPv6's default operation, if Joe has two connections then each of his computers has two IPv6 addresses and two default routes. If one connection goes down, one of the routes and sets of IP addresses goes away. Network security for that scenario is, of course, challenging. There's a longer list of security-impacting things that can go wrong than with the IPv4 NAT + dual ISP scenario. There's also the double-ISP loss scenario that causes Joe to lose all global-scope IP addresses. He can overcome that by deploying ULA addresses (a third set of IPv6 addresses) on the internal hosts, but convincing the internal network protocols to stay on the ULA addresses is wonky too. There's also 1:1 NAT where Joe can just use ULA addresses internally and have the firewall translate into the address block of the active ISP. However, because this provides a full map between every internal address, protocol and port to external addresses and ports (the entire internal network is addressible from outside), it has no positive impact on security the way IPv4's address-overloaded NAT does. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
" In IPv6's default operation, if Joe has two connections then each of his computers has two IPv6 addresses and two default routes. If one connection goes down, one of the routes and sets of IP addresses goes away." This sounds like a disaster. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "William Herrin" <bill@herrin.us> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Monday, February 19, 2024 9:16:52 AM Subject: Re: IPv6 uptake On Mon, Feb 19, 2024 at 6:52 AM Mike Hammett <nanog@ics-il.net> wrote:
"We can seriously lose NAT for v6 and not lose anything of worth."
I'm not going to participate in the security conversation, but we do absolutely need something to fill the role of NAT in v6. If it's already there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a down Internet connection to prevent transactions from completing, so he purchases two diverse broadband connections, say a cable connection and a DSL connection.
Hi Mike, In IPv6's default operation, if Joe has two connections then each of his computers has two IPv6 addresses and two default routes. If one connection goes down, one of the routes and sets of IP addresses goes away. Network security for that scenario is, of course, challenging. There's a longer list of security-impacting things that can go wrong than with the IPv4 NAT + dual ISP scenario. There's also the double-ISP loss scenario that causes Joe to lose all global-scope IP addresses. He can overcome that by deploying ULA addresses (a third set of IPv6 addresses) on the internal hosts, but convincing the internal network protocols to stay on the ULA addresses is wonky too. There's also 1:1 NAT where Joe can just use ULA addresses internally and have the firewall translate into the address block of the active ISP. However, because this provides a full map between every internal address, protocol and port to external addresses and ports (the entire internal network is addressible from outside), it has no positive impact on security the way IPv4's address-overloaded NAT does. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Mon, Feb 19, 2024 at 9:29 AM Mike Hammett <nanog@ics-il.net> wrote:
"In IPv6's default operation, if Joe has two connections then each of his computers has two IPv6 addresses and two default routes. If one connection goes down, one of the routes and sets of IP addresses goes away."
This sounds like a disaster.
You know, I thought so too, until I deployed it and it worked fine. I have done it twice now, once on MikroTik RouterOS and once on Ubiquiti EdgeOS. You just have to make sure the timers are pretty short, and that the router will stop sending RAs for the route if it's not working. This is definitely something that a COTS SOHO dual WAN router, that Joe would buy, could and should do by default (hopefully they do; I just haven't checked). -- 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 Mon, Feb 19, 2024 at 11:13 AM Hunter Fuller via NANOG <nanog@nanog.org> wrote:
On Mon, Feb 19, 2024 at 9:29 AM Mike Hammett <nanog@ics-il.net> wrote:
"In IPv6's default operation, if Joe has two connections then each of his computers has two IPv6 addresses and two default routes. If one connection goes down, one of the routes and sets of IP addresses goes away."
This sounds like a disaster.
You know, I thought so too, until I deployed it and it worked fine.
Years ago we made "source specific routing" the default in openwrt. This means all hosts get both sets of prefixes, and naturally retry other src addresses. To what extent anyone else has adopted this is unknown. The popular mwan3 code is kind of hairy vs a vs ipv6 here.
I have done it twice now, once on MikroTik RouterOS and once on Ubiquiti EdgeOS. You just have to make sure the timers are pretty short, and that the router will stop sending RAs for the route if it's not working. This is definitely something that a COTS SOHO dual WAN router, that Joe would buy, could and should do by default (hopefully they do; I just haven't checked).
-- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331
Office of Information Technology The University of Alabama in Huntsville Network Engineering
-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos
On Mon, Feb 19, 2024 at 9:17 AM William Herrin <bill@herrin.us> wrote:
There's also the double-ISP loss scenario that causes Joe to lose all global-scope IP addresses. He can overcome that by deploying ULA addresses (a third set of IPv6 addresses) on the internal hosts, but convincing the internal network protocols to stay on the ULA addresses is wonky too.
In the real world today, most applications seem to use mDNS and link-local addresses to keep this connectivity working. (I am guessing Joe's Taco Shop uses something like Square, and just needs his register to talk to his printer. This already works with mDNS and link-locals today.) -- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering
mdns can still be "fun" in a wide variety of situations. https://www.reddit.com/r/k12sysadmin/comments/9yghdx/chromebooks_and_peer_to... I do not know to what extent the upgrade to unicast feature long gestating in the IETF has been adopted. On Mon, Feb 19, 2024 at 11:10 AM Hunter Fuller via NANOG <nanog@nanog.org> wrote:
On Mon, Feb 19, 2024 at 9:17 AM William Herrin <bill@herrin.us> wrote:
There's also the double-ISP loss scenario that causes Joe to lose all global-scope IP addresses. He can overcome that by deploying ULA addresses (a third set of IPv6 addresses) on the internal hosts, but convincing the internal network protocols to stay on the ULA addresses is wonky too.
In the real world today, most applications seem to use mDNS and link-local addresses to keep this connectivity working. (I am guessing Joe's Taco Shop uses something like Square, and just needs his register to talk to his printer. This already works with mDNS and link-locals today.)
-- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331
Office of Information Technology The University of Alabama in Huntsville Network Engineering
-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos
On Mon, Feb 19, 2024 at 8:08 AM Hunter Fuller <hf0002+nanog@uah.edu> wrote:
On Mon, Feb 19, 2024 at 9:17 AM William Herrin <bill@herrin.us> wrote:
There's also the double-ISP loss scenario that causes Joe to lose all global-scope IP addresses. He can overcome that by deploying ULA addresses (a third set of IPv6 addresses) on the internal hosts, but convincing the internal network protocols to stay on the ULA addresses is wonky too.
In the real world today, most applications seem to use mDNS and link-local addresses to keep this connectivity working. (I am guessing Joe's Taco Shop uses something like Square, and just needs his register to talk to his printer. This already works with mDNS and link-locals today.)
Hi Hunter, Yes and no. The client application has to be programmed to understand link-local addresses or it can't use them at all. You can't just say "connect to fe80::1." Even if there's an fe80::1 on your network, it doesn't work. The client app has to also carry the interface identity into the stack (e.g. fe80::1%eth0) in order to use it. IPv6 link local addresses can't be expressed as a regular DNS target the way ULA and RFC1918 addresses can. No way to add that "%eth0" to the AAAA record. They only work with multicast DNS because the matching interface is known based on which interface was used to send the multicast query. And of course link local is -strictly- link local. If you want one subnet to communicate with another, you have to do it with global scope or ULA addresses. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Mon, Feb 19, 2024 at 10:22 AM William Herrin <bill@herrin.us> wrote:
Yes and no. The client application has to be programmed to understand link-local addresses or it can't use them at all. You can't just say "connect to fe80::1." Even if there's an fe80::1 on your network, it doesn't work. The client app has to also carry the interface identity into the stack (e.g. fe80::1%eth0) in order to use it.
Sure, you and I know this, as a network engineering fact. But, all over the US, thousands of taco trucks (Joe's or otherwise) are using Square and similar solutions, and I happen to know from pcaps that they are (at least some of the time) using the method I described. So everything else we discuss is kind of academic; Joe will continue printing receipts for taco orders over link local addresses just fine, since it works in production today. We can talk all day about how it's not optimal, has limitations if you have 4000 Chromebooks, etc., but Joe won't care, because he is selling tacos. Businesses (not enterprises) that need dual WAN will fall into this category 99.9% of the time. I guess the point I'm making is, the methods we are using today for v6 dual WAN, work fine for most people. There isn't really an advantage to using v4 NAT. That was the original topic I was responding to... as it is visible fuzzily in the rearview mirror currently.
On Mon, Feb 19, 2024 at 9:00 AM Hunter Fuller <hf0002+nanog@uah.edu> wrote:
I guess the point I'm making is, the methods we are using today for v6 dual WAN, work fine for most people.
Hi Hunter, I accept that point. It's wobbly on some of the details, but you're talking "most" people, not everyone.
There isn't really an advantage to using v4 NAT.
I disagree with that one. Limiting discussion to the original security context (rather than the wider world of how useful IPv6 is without IPv4), IPv6 is typically delivered to "most people" without border security, while IPv4 is delivered with a stateful NAT firewall. If ISPs got diligent about providing an IPv6 firewall to customers even though they don't need to do so for the customer to use more than one computer, there'd still be a security difference between internal hosts that are externally addressable (a stateful firewall without NAT) and internal hosts which are not. Security doesn't deal with "most people," it deals with people savvy enough to find and exploit the openings and errors in the software most people use. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Mon, Feb 19, 2024 at 11:16 AM William Herrin <bill@herrin.us> wrote:
There isn't really an advantage to using v4 NAT. I disagree with that one. Limiting discussion to the original security context (rather than the wider world of how useful IPv6 is without IPv4), IPv6 is typically delivered to "most people" without border security, while IPv4 is delivered with a stateful NAT firewall.
Maybe this is the disconnect. Who delivers v6 without a firewall? I've done a lot of T-Mobile and Comcast business connections lately, and those certainly both provide a firewall on v4 and v6. I'll admit I'm not currently well-versed in other providers (except ones that don't provide v6 at all...). It is possible to order Comcast without a firewall for v6, in which case you receive a public v4 address without protection too. What common scenario leads to your average person being unprotected on the v6 Internet?
On Mon, Feb 19, 2024 at 9:23 AM Hunter Fuller <hf0002+nanog@uah.edu> wrote:
On Mon, Feb 19, 2024 at 11:16 AM William Herrin <bill@herrin.us> wrote:
There isn't really an advantage to using v4 NAT. I disagree with that one. Limiting discussion to the original security context (rather than the wider world of how useful IPv6 is without IPv4), IPv6 is typically delivered to "most people" without border security, while IPv4 is delivered with a stateful NAT firewall.
Maybe this is the disconnect. Who delivers v6 without a firewall?
I've done a lot of T-Mobile and Comcast business connections lately, and those certainly both provide a firewall on v4 and v6. I'll admit I'm not currently well-versed in other providers (except ones that don't provide v6 at all...).
Hi Hunter, You may be right. I haven't ordered SOHO service in a long time and in fairness you were talking about Joe's Taco Shop not Joe's home network. I -suspect- that the wifi router provided for Joe's home network doesn't do much more than plain routing on the IPv6 side but I do not know that for a truth. I ordered my wave and comcast services without a router and I didn't keep the centurylink router long enough to test whether it did any filtering on IPv6. I noticed no knobs for IPv6 filtering or port forwarding, so I suspect it did not. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
OpenWrt, from which much is derived, is default deny on ipv4 and ipv6. The ipv6 firewall on most cable devices prior to the XB6 is very, very limited. On Mon, Feb 19, 2024 at 12:44 PM William Herrin <bill@herrin.us> wrote:
On Mon, Feb 19, 2024 at 9:23 AM Hunter Fuller <hf0002+nanog@uah.edu> wrote:
On Mon, Feb 19, 2024 at 11:16 AM William Herrin <bill@herrin.us> wrote:
There isn't really an advantage to using v4 NAT. I disagree with that one. Limiting discussion to the original security context (rather than the wider world of how useful IPv6 is without IPv4), IPv6 is typically delivered to "most people" without border security, while IPv4 is delivered with a stateful NAT firewall.
Maybe this is the disconnect. Who delivers v6 without a firewall?
I've done a lot of T-Mobile and Comcast business connections lately, and those certainly both provide a firewall on v4 and v6. I'll admit I'm not currently well-versed in other providers (except ones that don't provide v6 at all...).
Hi Hunter,
You may be right. I haven't ordered SOHO service in a long time and in fairness you were talking about Joe's Taco Shop not Joe's home network.
I -suspect- that the wifi router provided for Joe's home network doesn't do much more than plain routing on the IPv6 side but I do not know that for a truth. I ordered my wave and comcast services without a router and I didn't keep the centurylink router long enough to test whether it did any filtering on IPv6. I noticed no knobs for IPv6 filtering or port forwarding, so I suspect it did not.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos
On Mon, 19 Feb 2024 09:16:00 -0800 William Herrin <bill@herrin.us> wrote:
I disagree with that one. Limiting discussion to the original security context (rather than the wider world of how useful IPv6 is without IPv4), IPv6 is typically delivered to "most people" without border security, while IPv4 is delivered with a stateful NAT firewall.
How is v6 being delivered without a stateful firewall while v4 is secured with one? FWIW, in the decade we have been providing dual-stack by default, I have made a bit of a hobby out of testing every CPE and SOHO router that I get may hands on in my PON lab. I've never once seen a device that has v6 support and didn't have a stateful v6 firewall on by default (if v6 was "on"). By whom and how is this being delivered? --TimH
On Mon, Feb 19, 2024 at 9:44 AM Tim Howe <tim.h@bendtel.com> wrote:
FWIW, in the decade we have been providing dual-stack by default, I have made a bit of a hobby out of testing every CPE and SOHO router that I get may hands on in my PON lab.
Hi Tim, I have not, so I'll defer to your experience.
I've never once seen a device that has v6 support and didn't have a stateful v6 firewall on by default (if v6 was "on").
Acknowledged. So when the user wants to run a home server, their IPv4 options are to create a TCP or UDP port forward for a single service port or perhaps create a generic port forward for every port to a single internal machine. Protocols other than TCP and UDP not supported. They might also have the option of a "bridge" mode in which only one internal host is usable and the IPv4 functions of the device are disabled. The bridge mode is the only "off" setting for the IPv4 firewall. Correct? Their IPv6 options *might* include these but also include the option to turn the IPv6 firewall off. At which point IPv4 is still firewalled but IPv6 is not and allows all L4 protocols, not just TCP and UDP. Also correct? Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Some responses below. On Mon, 19 Feb 2024 10:01:06 -0800 William Herrin <bill@herrin.us> wrote:
I've never once seen a device that has v6 support and didn't have a stateful v6 firewall on by default (if v6 was "on").
Acknowledged.
So when the user wants to run a home server, their IPv4 options are to create a TCP or UDP port forward for a single service port or perhaps create a generic port forward for every port to a single internal machine. Protocols other than TCP and UDP not supported.
OK, but I'm not sure what you are getting at by saying this is TCP and UDP exclusive... I don't know why it would be; what's the example you think is typically being denied?
They might also have the option of a "bridge" mode in which only one internal host is usable and the IPv4 functions of the device are disabled. The bridge mode is the only "off" setting for the IPv4 firewall.
Correct?
Their IPv6 options *might* include these but also include the option to turn the IPv6 firewall off. At which point IPv4 is still firewalled but IPv6 is not and allows all L4 protocols, not just TCP and UDP.
Also correct?
This isn't how I would characterize any of this, to be honest. I think what you are trying to say is that a v6 firewall can be "off" while IPv6 connectivity remains unhindered, but turning "off" an IPv4 firewall means no hosts behind NAT will continue to have connectivity. The assumption being that a guardrail for someone being really self-destructive is removed. OK. So someone really wanted connectivity and really wanted to disable security. Maybe. I still believe that the statement "IPv6 is typically delivered to "most people" without border security" to be demonstrably false. -- TimH
On Mon, Feb 19, 2024 at 10:31 AM Tim Howe <tim.h@bendtel.com> wrote:
On Mon, 19 Feb 2024 10:01:06 -0800 William Herrin <bill@herrin.us> wrote:
So when the user wants to run a home server, their IPv4 options are to create a TCP or UDP port forward for a single service port or perhaps create a generic port forward for every port to a single internal machine. Protocols other than TCP and UDP not supported.
OK, but I'm not sure what you are getting at by saying this is TCP and UDP exclusive... I don't know why it would be; what's the example you think is typically being denied?
Hi Tim, NATs don't generally process protocols like GRE, ESP (IPSEC), SCTP and most of the hundred fifty or so other protocols that sit atop IPv4. They don't have code that would make it possible to process those packets. They're generally TCP, UDP, and ICMP. Anything else is necessarily dropped.
The assumption being that a guardrail for someone being really self-destructive is removed.
In more sophisticated scenarios where subtler errors are possible, I described it as a "security layer" rather than a "guardrail." But yes: we're talking about the same thing.
I still believe that the statement "IPv6 is typically delivered to "most people" without border security" to be demonstrably false.
I concede the claim. I am satisfied with your evidence that I was in error. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
I'm not going to participate in the security conversation, but we do absolutely need something to fill the role of NAT in v6. If it's already there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a down Internet connection to prevent transactions from completing, so he purchases two diverse broadband connections, say a cable connection and a DSL connection. When ISP fails, traffic will have to exit ISP B. He's not getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do simple NAT.
If you are asserting that the business is just taking the dynamic allocations from ISP A and ISP B, and NAT'ing internal stuff to those , then sure, that works, until ISP A goes down, and the NAT device must detect that so it no longer uses those addresses until it comes back up. Which is of course doable, but is no longer 'simple' NAT. On Mon, Feb 19, 2024 at 9:53 AM Mike Hammett <nanog@ics-il.net> wrote:
"We can seriously lose NAT for v6 and not lose anything of worth."
I'm not going to participate in the security conversation, but we do absolutely need something to fill the role of NAT in v6. If it's already there or not, I don't know. Use case: Joe's Taco Shop. Joe doesn't want a down Internet connection to prevent transactions from completing, so he purchases two diverse broadband connections, say a cable connection and a DSL connection. When ISP fails, traffic will have to exit ISP B. He's not getting a /48, LOA, BGP, etc. to do it on his own, he's just going to do simple NAT.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Michael Thomas" <mike@mtcc.com> *To: *nanog@nanog.org *Sent: *Saturday, February 17, 2024 12:50:46 PM *Subject: *Re: IPv6 uptake
On 2/17/24 10:26 AM, Owen DeLong via NANOG wrote:
On Feb 16, 2024, at 14:20, Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Justin Streiner" <streinerj@gmail.com> 4. Getting people to unlearn the "NAT=Security" mindset that we were
forced
to accept in the v4 world. NAT doesn't "equal" security.
But it is certainly a *component* of security, placing control of what internal nodes are accessible from the outside in the hands of the people inside. Uh, no… no it is not. Stateful inspection (which the kind of NAT (actually NAPT) you are assuming here depends on) is a component of security. You can do stateful inspection without mutilating the header and have all the same security benefits without losing or complicating the audit trail.
Exactly. As I said elsewhere, the security properties of NAT were a post-hoc rationalization. In the mean time, it has taken on its own life as if not NAT'ing (but still having stateful firewalls) would end the known security universe. We can seriously lose NAT for v6 and not lose anything of worth.
Mike
" Think how many more sites could have IPv6 capability already if this wasted effort had been put into that, instead. " My assumption is not many because the people talking about this likely either already have or will not deploy IPv6. Those that are willing to deploy IPv6, but have not are too busy to be engaging in the conversation. Well, mostly. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Owen DeLong via NANOG" <nanog@nanog.org> To: "Christopher Hawker" <chris@thesysadmin.au> Cc: "North American Operators' Group" <nanog@nanog.org> Sent: Wednesday, February 14, 2024 11:23:35 AM 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 <chris@thesysadmin.au> wrote: <blockquote> 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 <blockquote> 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. </blockquote> 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: <blockquote> 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 </blockquote> </blockquote>
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/
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 <bill@herrin.us> Sent: Wednesday, February 14, 2024 3:43 AM To: Christopher Hawker <chris@thesysadmin.au> Cc: North American Operators' Group <nanog@nanog.org> Subject: Re: The Reg does 240/4 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/
On Tue, Feb 13, 2024 at 2:34 PM Christopher Hawker <chris@thesysadmin.au> 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 bill@herrin.us https://bill.herrin.us/
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 <bill@herrin.us> Sent: Wednesday, February 14, 2024 10:06 AM To: Christopher Hawker <chris@thesysadmin.au> Cc: North American Operators' Group <nanog@nanog.org> Subject: Re: The Reg does 240/4 On Tue, Feb 13, 2024 at 2:34 PM Christopher Hawker <chris@thesysadmin.au> 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 bill@herrin.us https://bill.herrin.us/
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.
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 <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of John Levine <johnl@iecc.com> Sent: Wednesday, February 14, 2024 8:26 AM To: nanog@nanog.org <nanog@nanog.org> Subject: Re: The Reg does 240/4 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.
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 <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> Sent: Wednesday, February 14, 2024 7:42 AM To: North American Operators' Group <nanog@nanog.org> Subject: Re: The Reg does 240/4 And what are they going to do when 240/4 runs out?
That experiment already failed with the original v6 adoption process. It’s been more than 20 years and all we have proven is that as long as people can have an excuse to avoid v6 deployment, they will continue to do so. Giving them another 20 years of excuses is a step against the collective good IMHO. Owen
On Feb 13, 2024, at 14:43, Christopher Hawker <chris@thesysadmin.au> wrote:
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 <nanog-bounces+chris=thesysadmin.au@nanog.org> on behalf of Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> Sent: Wednesday, February 14, 2024 7:42 AM To: North American Operators' Group <nanog@nanog.org> Subject: Re: The Reg does 240/4
And what are they going to do when 240/4 runs out?
On 2/14/24 9:30 AM, Owen DeLong via NANOG wrote:
That experiment already failed with the original v6 adoption process. It’s been more than 20 years and all we have proven is that as long as people can have an excuse to avoid v6 deployment, they will continue to do so.
Giving them another 20 years of excuses is a step against the collective good IMHO.
I agree with you, based on my experience with several Internet providers. One of the biggest issues I have seen is a lack of a case to adopt IPv6 widely and completely. The management of the upper level providers ask this question: what is the return on the investment? Until that is convincingly answered, the foot-dragging of IPv6 adoption will continue. In my particular case, it's the complete lack of support by my upstream provider. Yes, they offer IPv6 connectivity. No, they don't offer guaranteed public IPv6 address space. No, they don't provide the same support for IPv6 that they do for IPv4. I had to pull toenails to get enough information to bring up a Web server in IPv6. It took getting a business fiber account to even get the bare minimum -- and I had to get a little creative to get the rest of the details that my ISP didn't provide. What is the big thing missing, beside public IPv6 space?
$ dig -x 2600:1700:79b0:ddc0::3
; <<>> DiG 9.16.1-Ubuntu <<>> -x 2600:1700:79b0:ddc0::3 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44020 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. IN PTR
Now, this is my web server's address. My mail server's proposed IPv6 address, is only one digit away. Can I get a PTR record for it? No. Can I get a delegation for my IPv6 address range? No. "We don't support IPv6." That has been the refrain since 2018. It's 2024 -- you do the math. We are talking about a fairly large many-customer three-letter company, not some hole in the wall back-room operation. Could I handle a delegation? Yes. Putting up a DNS server is child's play. On a box with a public IP address. That is not the barrier. Now, I can't speak for all companies. For example, I have no clue what support and services Hurricane Electric provides to its customers with regard to IPv6, even though I've seen many mentions of HE over the decades. When the community wants to get serious about advancing the deployment of IPv6, the community itself needs to buy into IPv6. At least one big player isn't interested.
participants (34)
-
Brandon Butterworth
-
Brian Knight
-
Brotman, Alex
-
Bryan Holloway
-
Chris Adams
-
Christopher Hawker
-
Daniel Marks
-
Dave Taht
-
David Conrad
-
Denis Fondras
-
Greg Skinner
-
Howard, Lee
-
Hunter Fuller
-
Jay R. Ashworth
-
John Levine
-
John R. Levine
-
Justin Streiner
-
Lyndon Nerenberg (VE7TFX/VE6BBM)
-
Mark Andrews
-
Matthew Walster
-
Michael Thomas
-
Mike Hammett
-
Nick Hilliard
-
Owen DeLong
-
richey goldberg
-
Ryan Hamel
-
sronan@ronan-online.com
-
Stephen Satchell
-
Steven Sommars
-
Tim Howe
-
Tom Beecher
-
Tom Samplonius
-
Tony Wicks
-
William Herrin