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.
Use 100.64.0.0/10, this is the CGNAT reserved range.I would most definitely not recommend 240.0.0.0
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_Tn9KRsyDGgSq-M4g
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
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 
And what about 0.0.0.0/8?
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!)
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.
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 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
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.
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
> 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
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
> > 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, thisPardon me. But Apple has at least suggested y'all should be ready for
ipv6-only networks, not class EAnd 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.
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.Talk41.colitti-IPv6%20transition%20experiences.pdf
slide 4 for a description, or
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net/InetAddresses.html
for open-sourced code.
There may be other uses for IPs beyond routing.
Damian
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.)
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.)
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
>> 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.
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