Is it safe to use 240.0.0.0/4
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen <lnguyen@opsource.net> wrote:
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
most things, including most cisco gear, will not forward those Class E packets or accept Class E as a valid address If you have success, please report it to the list.
Cisco IOS-XE Fails ip add 241.1.1.1 255.255.255.0 Not a valid host address - 241.1.1.1 ip route 241.0.0.0 255.0.0.0 10.10.10.1 %Invalid destination prefix XR-OS : fails Can take the IP on a interface, but cant route it IOS fails we used up all the reserved ip blocks including the 169.254 and the benchmark, and the 100.64/10 and ofcourse the RFC1918. Lots of apps don't do ipv6 so we are finding interim solution...i guess that's karma since doing so sort of anti-facilitating the use of ipv6 :) On Wed, Jun 17, 2015 at 5:12 PM, Ca By <cb.list6@gmail.com> wrote:
On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen <lnguyen@opsource.net> wrote:
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
most things, including most cisco gear, will not forward those Class E packets or accept Class E as a valid address
If you have success, please report it to the list.
And what about 0.0.0.0/8? -- Eduardo Schoedler 2015-06-17 18:21 GMT-03:00 Luan Nguyen <luan.nguyen@dimensiondata.com>:
Cisco IOS-XE Fails ip add 241.1.1.1 255.255.255.0 Not a valid host address - 241.1.1.1 ip route 241.0.0.0 255.0.0.0 10.10.10.1 %Invalid destination prefix XR-OS : fails Can take the IP on a interface, but cant route it IOS fails
we used up all the reserved ip blocks including the 169.254 and the benchmark, and the 100.64/10 and ofcourse the RFC1918. Lots of apps don't do ipv6 so we are finding interim solution...i guess that's karma since doing so sort of anti-facilitating the use of ipv6 :)
On Wed, Jun 17, 2015 at 5:12 PM, Ca By <cb.list6@gmail.com> wrote:
On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen <lnguyen@opsource.net> wrote:
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
most things, including most cisco gear, will not forward those Class E packets or accept Class E as a valid address
If you have success, please report it to the list.
-- Eduardo Schoedler
On Wed, Jun 17, 2015 at 05:07:25PM -0400, Luan Nguyen wrote:
Is that safe to use [240.0.0.0/4] internally? Anyone using it? Just for NATTING on Cisco gears...
On Wed, Jun 17, 2015 at 06:30:04PM -0300, Eduardo Schoedler wrote:
And what about 0.0.0.0/8?
On both counts: NO. I always assume parties strive to deliver the best service to their respective customers, IMHO this means avoiding IP space which was not designated for a global purpose (yet). Kind regards, Job
Use 100.64.0.0/10, this is the CGNAT reserved range.I would most definitely not recommend 240.0.0.0 -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Luan Nguyen Sent: Thursday, 18 June 2015 9:07 a.m. To: nanog@nanog.org Subject: Is it safe to use 240.0.0.0/4 Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
Using CGNAT doesn't sound right either, although I haven't read the whole thing, but it seems reasonable to use that block for CGNAT only. https://tools.ietf.org/html/rfc1918 On Wed, Jun 17, 2015 at 4:13 PM, Tony Wicks <tony@wicks.co.nz> wrote:
Use 100.64.0.0/10, this is the CGNAT reserved range.I would most definitely not recommend 240.0.0.0
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Luan Nguyen Sent: Thursday, 18 June 2015 9:07 a.m. To: nanog@nanog.org Subject: Is it safe to use 240.0.0.0/4
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
Probably fine to NAT it yourself until it is allocated and someone starts using it. Why not just use RFC1918 space? https://www.google.com/fusiontables/DataSource?docid=1JEgabzMOJx1l25zHZK5wv4... Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen <lnguyen@opsource.net> wrote:
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
On Wed, 17 Jun 2015 17:07:25 -0400, Luan Nguyen <lnguyen@opsource.net> wrote:
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
As you've already figured out, Class E space is still restricted on Cisco gear. I'll wait for Curran to pop up with various links to reasons why Class E was "abandoned" by ARIN. (short answer: too much broken crap thinks it's multicast!)
On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam <jfbeam@gmail.com> wrote:
I'll wait for Curran to pop up with various links to reasons why Class E was "abandoned" by ARIN. (short answer: too much broken crap thinks it's multicast!)
Hi Ricky, You may be confused. ARIN never possessed class E; it's held in reserve by IETF. As much as I enjoy a good ARIN bashing, they and John Curran are quite faultless here. IIRC, the short answer why it wasn't repurposed as additional unicast addresses was that too much deployed gear has it hardcoded as "reserved, future functionality unknown, do not use." Following an instruction to repurpose 240/4 as unicast addresses, such gear would not receive new firmware or obsolete out of use quickly enough to be worth the effort. Given how slowly IPv6 is deploying, this choice may prove to have been shortsighted. Had IETF designated class-E as "reserved, future unicast" in 2008 when the issue was debated and asked vendors to update their software to expect 240/4 to be used as unicast addresses, half the problem equipment would already have aged out and we could all be debating whether to make them more RFC-1918 or hand them off to the RIRs. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On Wednesday, June 17, 2015, William Herrin <bill@herrin.us> wrote:
On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam <jfbeam@gmail.com <javascript:;>> wrote:
I'll wait for Curran to pop up with various links to reasons why Class E was "abandoned" by ARIN. (short answer: too much broken crap thinks it's multicast!)
Hi Ricky,
You may be confused. ARIN never possessed class E; it's held in reserve by IETF. As much as I enjoy a good ARIN bashing, they and John Curran are quite faultless here.
IIRC, the short answer why it wasn't repurposed as additional unicast addresses was that too much deployed gear has it hardcoded as "reserved, future functionality unknown, do not use." Following an instruction to repurpose 240/4 as unicast addresses, such gear would not receive new firmware or obsolete out of use quickly enough to be worth the effort.
Given how slowly IPv6 is deploying, this
Pardon me. But Apple has at least suggested y'all should be ready for ipv6-only networks, not class E http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-servic... http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv... And the source video which is worth watching from start to finish https://developer.apple.com/videos/wwdc/2015/?id=719 choice may prove to have been
shortsighted. Had IETF designated class-E as "reserved, future unicast" in 2008 when the issue was debated and asked vendors to update their software to expect 240/4 to be used as unicast addresses, half the problem equipment would already have aged out and we could all be debating whether to make them more RFC-1918 or hand them off to the RIRs.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com <javascript:;> bill@herrin.us <javascript:;> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
In message <CAD6AjGSBfy_RH9J_T2yY32=vqH=19JBeL+gSNB4nN_piJv+16A@mail.gmail.com>, Ca By writes:
On Wednesday, June 17, 2015, William Herrin <bill@herrin.us> wrote:
On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam <jfbeam@gmail.com <javascript:;>> wrote:
I'll wait for Curran to pop up with various links to reasons why Class E was "abandoned" by ARIN. (short answer: too much broken crap thinks it's multicast!)
Hi Ricky,
You may be confused. ARIN never possessed class E; it's held in reserve by IETF. As much as I enjoy a good ARIN bashing, they and John Curran are quite faultless here.
IIRC, the short answer why it wasn't repurposed as additional unicast addresses was that too much deployed gear has it hardcoded as "reserved, future functionality unknown, do not use." Following an instruction to repurpose 240/4 as unicast addresses, such gear would not receive new firmware or obsolete out of use quickly enough to be worth the effort.
Given how slowly IPv6 is deploying, this
Pardon me. But Apple has at least suggested y'all should be ready for ipv6-only networks, not class E
http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-servic...
http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv...
And the source video which is worth watching from start to finish
Well the cell carriers are kind of forcing the issue here for iOS. They want to go IPv6-only and Apple doesn't want to do 464XLAT last I heard (haven't watched the video yet). If all the apps can run in a IPv6 only environment then there is only IPv4 literals in web pages and tethered equipement to worry about so there is less presure to implement 464XLAT. Breaking pages with IPv4 literals may actually be a good thing at this stage. We are 20 years into the migration to IPv6. 15 years of production IPv6 behind us. Most tethered equipment can do IPv6. The only hold outs there are servers that they want to connect to are IPv6 only. Forcing the issue here would also be a good thing. Additionally lots of big companies (FaceBook, Microsoft) are trying to go IPv6 only internally as are data centers. A number of wireline ISP are IPv6 only using DS-Lite to transport IPv4. MAP is a future IPv4 as a service on IPv6 contender.
choice may prove to have been
shortsighted. Had IETF designated class-E as "reserved, future unicast" in 2008 when the issue was debated and asked vendors to update their software to expect 240/4 to be used as unicast addresses, half the problem equipment would already have aged out and we could all be debating whether to make them more RFC-1918 or hand them off to the RIRs.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com <javascript:;> bill@herrin.us <javascript:;> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, 17 Jun 2015 18:38:32 -0400, William Herrin <bill@herrin.us> wrote:
You may be confused. ARIN never possessed class E; it's held in reserve by IETF. As much as I enjoy a good ARIN bashing, they and John Curran are quite faultless here.
Quote-unquote, as in they didn't even bother *even proposing* to use Class E space. The reasons were numerous, btw. (hardcoded restrictions, erroneous classification as multicast, not worth the effort, etc.)
Given how slowly IPv6 is deploying, this choice may prove to have been shortsighted.
I doubt it. As you said, there is A LOT of crap out there that would have to be updated. Pulling a number out of the air, I'd guess *most* in-use devices would NEVER see such an update. Even from companies that do still exist. (Sadly, those are also devices that aren't going to see IPv6, either.)
On Wednesday, June 17, 2015, Ricky Beam <jfbeam@gmail.com> wrote:
On Wed, 17 Jun 2015 18:38:32 -0400, William Herrin <bill@herrin.us> wrote:
You may be confused. ARIN never possessed class E; it's held in reserve by IETF. As much as I enjoy a good ARIN bashing, they and John Curran are quite faultless here.
Quote-unquote, as in they didn't even bother *even proposing* to use Class E space. The reasons were numerous, btw. (hardcoded restrictions, erroneous classification as multicast, not worth the effort, etc.)
https://tools.ietf.org/html/draft-wilson-class-e-02 Proposed and denied. Please stop this line and spend your efforts on ipv6
Given how slowly IPv6 is deploying, this choice may prove to have been
shortsighted.
I doubt it. As you said, there is A LOT of crap out there that would have to be updated. Pulling a number out of the air, I'd guess *most* in-use devices would NEVER see such an update. Even from companies that do still exist. (Sadly, those are also devices that aren't going to see IPv6, either.)
On Wed, 17 Jun 2015 21:17:53 -0400, Ca By <cb.list6@gmail.com> wrote:
https://tools.ietf.org/html/draft-wilson-class-e-02
Proposed and denied. Please stop this line and spend your efforts on ipv6
By APNIC. Cisco did, too, btw. And they weren't first, either. Nor is this going to be the last time someone suggests it. To paraphrase Curran (since he's not popping by to say it), it's a lot of work that ultimately yields a small amount of space that's STILL going to run out. 16 /8's won't fix the problem. Just deploy IPv6 already. Sure, there's plenty to complain about -- and we do complain! -- but it's what we have. --Ricky
Given how slowly IPv6 is deploying, this choice may prove to have been shortsighted.
I doubt it. As you said, there is A LOT of crap out there that would have to be updated. Pulling a number out of the air, I'd guess *most* in-use devices would NEVER see such an update. Even from companies that do still exist. (Sadly, those are also devices that aren't going to see IPv6, either.)
Most stuff out there do only care about that its subnet mask OR's up correctly with its ip and gw. Poof, there did 99.9 per cent of all devices get excluded. Most stuff that do use and/or misuse this freightening block of darkest cyberspace are either high end network equipment (who drop) or some end users/mcast sender which are behind NAT anyway. I believe it's a great idea. Let's at least try it out, like an alpha-test. We choose a temporary /8 (easy to remember) and divide it into /16s or less, depending on how many interested candidates we are able to raise. After being approved by IANA we begin advertising our new prefixes for a finite amount of time. If the world ends, or is about to, we stop. I believe we would bump into minor caveats but ISP's are beginning to NAT their end customers due to the lack of free ips and I wouldn't want to live in a world where that was the norm. This madness has to stop and v6 won't salvate us for yet another total sonar eclipse or three. Let us at least try it out - if it goes well we have bought us some time. If not, revert. Thank you for listening. br /Mr Bjork
On Wednesday, June 17, 2015, Jonas Björk <mr.jonas.bjork@me.com> wrote:
Given how slowly IPv6 is deploying, this choice may prove to have been shortsighted.
I doubt it. As you said, there is A LOT of crap out there that would have to be updated. Pulling a number out of the air, I'd guess *most* in-use devices would NEVER see such an update. Even from companies that do still exist. (Sadly, those are also devices that aren't going to see IPv6, either.)
Most stuff out there do only care about that its subnet mask OR's up correctly with its ip and gw. Poof, there did 99.9 per cent of all devices get excluded. Most stuff that
Pretty sure this is wrong.
do use and/or misuse this freightening block of darkest cyberspace are either high end network equipment (who drop) or some end users/mcast sender which are behind NAT anyway.
I believe it's a great idea. Let's at least try it out, like an alpha-test. We choose a temporary /8 (easy to remember) and divide it into /16s or less, depending on how many interested candidates we are able to raise. After being approved by IANA we begin advertising our new prefixes for a finite amount of time. If the world ends, or is about to, we stop.
I believe we would bump into minor caveats but ISP's are beginning to NAT their end customers due to the lack of free ips and I wouldn't want to live in a world where that was the norm. This madness has to stop and v6 won't salvate us for yet another total sonar eclipse or three.
Definately wrong. There are many networks larger and smaller than yours that run ipv6-only (ds-lite, 464xlat, whatever facebook does in their dc). You are wasting time and money. Let us at least try it out - if it goes well we have bought us some time.
If not, revert. Thank you for listening.
br /Mr Bjork
IIRC, the short answer why it wasn't repurposed as additional unicast addresses was that too much deployed gear has it hardcoded as "reserved, future functionality unknown, do not use." Following an instruction to repurpose 240/4 as unicast addresses, such gear would not receive new firmware or obsolete out of use quickly enough to be worth the effort.
More to the point, the amount of work required to fix all the existing equipment to handle 240/4 would not be a lot less than the work required to get it to handle IPv6, and it would only have pushed the IPv4 exhaustion out a few years. It was entirely reasonable to conclude that it would not have been a good use of anyone's time or money. Look at the bright side: you can use the money you didn't spend on 240/4 upgrades to buy slightly used IPv4 space on the grey market or CGN equipment. R's, John
How many devices need IPs? Is there a reason ARIN can't be used? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Jun 17, 2015 10:18 PM, "John Levine" <johnl@iecc.com> wrote:
IIRC, the short answer why it wasn't repurposed as additional unicast addresses was that too much deployed gear has it hardcoded as "reserved, future functionality unknown, do not use." Following an instruction to repurpose 240/4 as unicast addresses, such gear would not receive new firmware or obsolete out of use quickly enough to be worth the effort.
More to the point, the amount of work required to fix all the existing equipment to handle 240/4 would not be a lot less than the work required to get it to handle IPv6, and it would only have pushed the IPv4 exhaustion out a few years. It was entirely reasonable to conclude that it would not have been a good use of anyone's time or money.
Look at the bright side: you can use the money you didn't spend on 240/4 upgrades to buy slightly used IPv4 space on the grey market or CGN equipment.
R's, John
There is already more than enough address space allocated for NAT, you don't need to start using random prefixes that may or may not be needed for other purposes in the future. For all we know, tomorrow someone could write an RFC requesting an address reserved for local anycast DNS and it could be assigned from this block. On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen <lnguyen@opsource.net> wrote:
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
You'll find as well, a lot of hosts (eg, I know at least Windows XP) won't forward to Class E destinations. -Tom On Wed, Jun 17, 2015 at 2:50 PM, Ray Soucy <rps@maine.edu> wrote:
There is already more than enough address space allocated for NAT, you don't need to start using random prefixes that may or may not be needed for other purposes in the future.
For all we know, tomorrow someone could write an RFC requesting an address reserved for local anycast DNS and it could be assigned from this block.
On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen <lnguyen@opsource.net> wrote:
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
-- Ray Patrick Soucy Network Engineer University of Maine System
T: 207-561-3526 F: 207-561-3531
MaineREN, Maine's Research and Education Network www.maineren.net
Not used in the sense you imagine, but I designed a hack where we hash IPv6 addresses into 224/3 (class D and E space) so backends that don't support IPv6 can still be provided a pseudo-IP. This accelerated support of IPv6 across all Google services without needing to wait for each individual backend to provide support. See https://www.nanog.org/meetings/nanog50/presentations/Wednesday/NANOG50.Talk4... slide 4 for a description, or http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net... for open-sourced code. There may be other uses for IPs beyond routing. Damian On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen <lnguyen@opsource.net> wrote:
Is that safe to use internally? Anyone using it? Just for NATTING on Cisco gears...
No, we examined this back in 2007. See your favorite cache site for http://puck.nether.net/mailman/listinfo/240-e -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG
participants (17)
-
Ca By -
Damian Menscher -
Eduardo Schoedler -
Job Snijders -
Joe Provo -
John Levine -
Jonas Björk -
Josh Luthman -
Luan Nguyen -
Luan Nguyen -
Mark Andrews -
Rafael Possamai -
Ray Soucy -
Ricky Beam -
Tom Paseka -
Tony Wicks -
William Herrin