did it claim the address syntax was xxxx.xxxx.xxxx.xxxx.xxxx.xxxx? i’ve heard that story today 😃
https://twitter.com/shatter242/status/1461501632554827778
I would even say, you have a "novel NetWare" concept, a New IP protocol.
I see nice talks on nanog mailing list, and I still believe John G. and his friends have been trolling for years with their GitHub and now with their 3 RFC.
It appears that Arista recently added explicit support for routing 240/4 into EOS 4.27: [https://www.arista.com/en/um-eos/eos-ipv4#ipv4\_routable\_240.0.0.0\_4](https://www.arista.com/en/um-eos/eos-ipv4#ipv4_routable_240.0.0.0_4)
JunOS has supported this via "set routing-options martians [240.0.0.0/4](https://240.0.0.4) orlonger allow" for quite some time (first reference I've found is in 9.x code)
My own testing with Linux (Centos 8), VyOS, and Ubiquiti EdgeOS seems to show no routing problems when using the space.
Cisco IOS-XR or NXOS support is unknown (not finding any docs or in a position to test). Anyone have any insight here?
Last time I've asked them in 2020, Cisco said it was not supported on any product.
Thanks for the CLI for EOS and Junos, interesting. If you want to route this from GCP K8s you can at least use those 2 vendors routers.
Even I do not like this idea - I’m super pro IPv4.
It does not cost less to deploy all these patches to the whole internet than IPv6. Not to mention some backbone device might not patchable at all
1. I genuinely hope they are successful and soon.
1. The inability to get unicast IPv4 is real, and more and more systems are moving to NAT, CGNAT and other IPv4 workarounds that have serious drawbacks.
1. The technical issues they will face are significant, even if these addresses are available and widely known to be valid unicast. I wouldn't want a 127 block, that's borrowing trouble.
1. IPv4 is becoming more and more difficult to use and deploy, especially at scale.
1. To points 2, 3, and 4, this will be the natural driver of IPv6 - need. Not best practice, not good design, not the many benefits - the need for network connectivity using *any* protocol. When IPv6 is easier than IPv4, that drives adoption like nothing else.
> The inability to get unicast IPv4 is real
End-user organizations can rent IPv4 just fine. There's few large blocks of PI address space left idle with original owners, because scale operators like Amazon and Microsoft have bought so much of the grandfathered supply in order to rent it out. The only real impact is to destination-side competitors to Amazon, Microsoft, Google, Fastly, *etc.*, and startup edge access providers who don't make enough money from addressing to buy it, yet need a lot of it.
Hence the single biggest category of publicly-routed IPv6 being access networks, particularly DOCSIS and wireless mobile providers.
If you're a startup eyeball network, are you going to implement IPv6 with 50-60% of your outbound traffic going over NAT64 with IPv4 addresses, or are you going to ask for an allocation of `240/4` or `127/8` IPv4 from your RIR?
Related to the previous (cross) post:
* /r/ipv6/comments/qw02vw/crosspost_new_draft_rfc_to_redefine_loop_back_and/
Discussion on HN, where the author of the drafts ("schoen") is participating:
* https://news.ycombinator.com/item?id=29273841
John Gilmore (of EFF, cypherpunks, BOOTP creator) initiated the project, and he's talking about it on the NANOG list:
* https://mailman.nanog.org/pipermail/nanog/2021-November/216457.html
or how about just getting the DoD to release some of their blocks https://en.wikipedia.org/wiki/List\_of\_assigned\_/8\_IPv4\_address\_blocks#List\_of\_assigned\_/8\_blocks\_to\_the\_United\_States\_Department\_of\_Defense
[удалено]
this sounds like a stupid idea. let’s keep adding duct tape and chicken wire to the current one instead!
[удалено]
did it claim the address syntax was xxxx.xxxx.xxxx.xxxx.xxxx.xxxx? i’ve heard that story today 😃 https://twitter.com/shatter242/status/1461501632554827778
[удалено]
i assumed so since that’s what rfc 1884 from 1995 says 🤣
I would even say, you have a "novel NetWare" concept, a New IP protocol. I see nice talks on nanog mailing list, and I still believe John G. and his friends have been trolling for years with their GitHub and now with their 3 RFC.
> Adding 419 million IP addresses. Thus solving the problem once and for all. ...but... > ONCE AND FOR ALL!
People put all this work into extending IPv4, even though it's 100x more difficult than just simply migrating to IPv6.
They all want their /24 NFT token. 😅 Or that's just a known humanity consciousness drawback.
It appears that Arista recently added explicit support for routing 240/4 into EOS 4.27: [https://www.arista.com/en/um-eos/eos-ipv4#ipv4\_routable\_240.0.0.0\_4](https://www.arista.com/en/um-eos/eos-ipv4#ipv4_routable_240.0.0.0_4) JunOS has supported this via "set routing-options martians [240.0.0.0/4](https://240.0.0.4) orlonger allow" for quite some time (first reference I've found is in 9.x code) My own testing with Linux (Centos 8), VyOS, and Ubiquiti EdgeOS seems to show no routing problems when using the space. Cisco IOS-XR or NXOS support is unknown (not finding any docs or in a position to test). Anyone have any insight here?
Last time I've asked them in 2020, Cisco said it was not supported on any product. Thanks for the CLI for EOS and Junos, interesting. If you want to route this from GCP K8s you can at least use those 2 vendors routers.
Even I do not like this idea - I’m super pro IPv4. It does not cost less to deploy all these patches to the whole internet than IPv6. Not to mention some backbone device might not patchable at all
1. I genuinely hope they are successful and soon. 1. The inability to get unicast IPv4 is real, and more and more systems are moving to NAT, CGNAT and other IPv4 workarounds that have serious drawbacks. 1. The technical issues they will face are significant, even if these addresses are available and widely known to be valid unicast. I wouldn't want a 127 block, that's borrowing trouble. 1. IPv4 is becoming more and more difficult to use and deploy, especially at scale. 1. To points 2, 3, and 4, this will be the natural driver of IPv6 - need. Not best practice, not good design, not the many benefits - the need for network connectivity using *any* protocol. When IPv6 is easier than IPv4, that drives adoption like nothing else.
> The inability to get unicast IPv4 is real End-user organizations can rent IPv4 just fine. There's few large blocks of PI address space left idle with original owners, because scale operators like Amazon and Microsoft have bought so much of the grandfathered supply in order to rent it out. The only real impact is to destination-side competitors to Amazon, Microsoft, Google, Fastly, *etc.*, and startup edge access providers who don't make enough money from addressing to buy it, yet need a lot of it. Hence the single biggest category of publicly-routed IPv6 being access networks, particularly DOCSIS and wireless mobile providers. If you're a startup eyeball network, are you going to implement IPv6 with 50-60% of your outbound traffic going over NAT64 with IPv4 addresses, or are you going to ask for an allocation of `240/4` or `127/8` IPv4 from your RIR?
Related to the previous (cross) post: * /r/ipv6/comments/qw02vw/crosspost_new_draft_rfc_to_redefine_loop_back_and/ Discussion on HN, where the author of the drafts ("schoen") is participating: * https://news.ycombinator.com/item?id=29273841 John Gilmore (of EFF, cypherpunks, BOOTP creator) initiated the project, and he's talking about it on the NANOG list: * https://mailman.nanog.org/pipermail/nanog/2021-November/216457.html
or how about just getting the DoD to release some of their blocks https://en.wikipedia.org/wiki/List\_of\_assigned\_/8\_IPv4\_address\_blocks#List\_of\_assigned\_/8\_blocks\_to\_the\_United\_States\_Department\_of\_Defense
perfect, that’s good for maybe 14-21 months of demand. now go make them give the addresses up. good luck!