Bug 235927 - FreeBSD does not reply to ICMP requests when assigned an ip in 240.0.0.0/8
Summary: FreeBSD does not reply to ICMP requests when assigned an ip in 240.0.0.0/8
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-net mailing list
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2019-02-21 21:44 UTC by Loganaden Velvindron
Modified: 2019-03-07 14:20 UTC (History)
4 users (show)

See Also:


Attachments
FreeBSD icmp class-e fix (474 bytes, patch)
2019-02-21 21:44 UTC, Loganaden Velvindron
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Loganaden Velvindron 2019-02-21 21:44:59 UTC
Created attachment 202244 [details]
FreeBSD icmp class-e fix

Due to the shrinkage of the IPv4 space, some people are looking at using Class-E as a way to further expand the range of usable IPv4 addresses. In order to make this happen, an audit is needed for FreeBSD to check for 240.0.0.0/4 assignment. When assigning a class-e ip to FreeBSD-12, it works except for ICMP.

Example, when pinging the FreeBSD machine:
ping 240.0.1.199
PING 240.0.1.199 (240.0.1.199) 56(84) bytes of data.
^C
--- 240.0.1.199 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5088ms

However, SSH is accessible:
nc -v 240.0.1.199 22
Connection to 240.0.1.199 22 port [tcp/ssh] succeeded!
SSH-2.0-OpenSSH_7.8 FreeBSD-20180909

This attached patch removes the check for experimental/class-e range address and allows ICMP to work.

ping 240.0.1.199
PING 240.0.1.199 (240.0.1.199) 56(84) bytes of data.
64 bytes from 240.0.1.199: icmp_seq=1 ttl=64 time=0.664 ms
64 bytes from 240.0.1.199: icmp_seq=2 ttl=64 time=0.860 ms
64 bytes from 240.0.1.199: icmp_seq=3 ttl=64 time=0.740 ms
Comment 1 Rodney W. Grimes freebsd_committer 2019-02-22 00:30:26 UTC
(In reply to Loganaden Velvindron from comment #0)
Who are "some people", as I believe it would require either an IANA or IETF action to move these addresses from the EXPERIMENTAL status, and change the status of these addresses per RFC 6890 as invalid source addresses.

If "some people" are the IANA or IETF, can you point to a draft RFC?
Comment 2 Conrad Meyer freebsd_committer 2019-02-22 01:52:17 UTC
Regardless of whether or not using class E addresses is canonical, we half-ass it today.

If they're non-canonical, we should *not* allow them to be assigned to interfaces.

If they are, we shouldn't filter ICMP.
Comment 3 Conrad Meyer freebsd_committer 2019-02-22 01:58:02 UTC
Note that there are two other Class E checks, at least referencing the same macro name, that should probably be turned off at the same time as the icmp check (if turning off the check is the right thing to do):

ipfw/nat64: nat64_check_ip4()

netinet/in: in_canforward()
Comment 4 Rodney W. Grimes freebsd_committer 2019-02-22 02:11:42 UTC
The name class E was abolished in 2002 when RFC3330 designated 240/4 as reserved and referenced rfc1700, which is STD 2, that reference appears to be for the 255.255.255.255 limited broadcast address.

I have removed the obsolete name "class E" from the title of this bug and used the current "240/4" designtation.

(In reply to Conrad Meyer from comment #2)
I do not have a serious problem with this patch, but would like to know we are not just doing this at someones request without further reasons than "someone is playing with it."
Comment 5 Loganaden Velvindron 2019-02-22 02:27:46 UTC
(In reply to Conrad Meyer from comment #3)
Yes, I'm also working on the 2 other areas.
Comment 6 Loganaden Velvindron 2019-02-22 02:40:59 UTC
(In reply to Rodney W. Grimes from comment #4)

There is a scheduled talk about this effort at netdev:
https://netdevconf.org/0x13/session.html?talk-ipv4-unicast-expansions

Linux has already accepted a patch to allow assignment of 240.0.0.0/4:
https://www.spinics.net/lists/netdev/msg540240.html

OpenWRT (major third party firmware) has accepted a similar patch:
https://git.openwrt.org/?p=project/netifd.git;a=commit;h=cd089c52de96e47cf99410f66701e04e24155b9a

A new ID will be submitted to the IETF soon. 
Please note that there were some attempts in the past in the IETF already:
https://tools.ietf.org/html/draft-fuller-240space-02

At the time it was perceived that ipv6 would take over faster. However, the adoption of ipv6 has been slower than expected. 

See this thread also:
https://www.mail-archive.com/cerowrt-devel@lists.bufferbloat.net/msg05838.html
Comment 7 Rodney W. Grimes freebsd_committer 2019-02-22 04:31:47 UTC
(In reply to Loganaden Velvindron from comment #6)

>Linux has already accepted a patch to allow assignment of 240.0.0.0/4:
>https://www.spinics.net/lists/netdev/msg540240.html
This patch appears to fix very ancient code that still treated this
as part of the multicast space.  The patches also add use of language
(ClassE) that was obsoleted 16 years ago.  
https://www.spinics.net/lists/netdev/msg539064.html is the correct
reference to the message with the patch in it.

>OpenWRT (major third party firmware) has accepted a similar patch:
This is inline with what your asking for here.

>A new ID will be submitted to the IETF soon.
A new ID for what? Do you mean removing this from IANA reserved?

>Please note that there were some attempts in the past in the IETF already:
>https://tools.ietf.org/html/draft-fuller-240space-02
A 2007 attempt by Cisco, have you considered contact them about moving forward with that draft?

As it stands today the RFC say this is an invalid source address, so we should continue to respect those standards in a standard released product, however I would not have a problem with #ifdef FOO_EXPERMINTAL disabling these restrictions, or a sysctl that did it.

There are some much larger obsticles to getting this working on the internet at a larger scale, in that there are far too many firewalls that filter this range, and getting it out of them is going to take a long time.  That time wont even start until they are reclassed by IANA with an update to RFC6890 and you would probably best get that done as it is the long lead show stopper to this idea.  Getting FreeBSD, Linux and such fixed is pointless if people are going to continue to firewall this range.
Comment 8 Dave Taht 2019-02-22 16:22:41 UTC
(In reply to Rodney W. Grimes from comment #7)

To clarify a few things... 

The last major attempt at making 240/4 "real" happened in the 2008-2010 timeframe - bsd and linux gained the ability to assign and route it around then (and osx had it in the first place). The IETF conflated "making it work" with "how they should be used" and after the CGN address space was defined support died out there. There was consensus then about making them unicast, I think, from talking to all the participants in the debate.

Linux had one teeny patch dropped on the floor back then which allowed assignment from the ifconfig sysctl still used by busybox (otherwise the netlink based tools like iproute had no restrictions), so it had otherwise been able to assign/route/ping for all this time. So we just fixed that (and obsoleted IN_EXPERIMENTAL entirely) in linux 4.20 and backported it to openwrt. There's other patches outstanding across other tools in the ipv4-cleanup github repo.

So... the minor bug regarding using this space on freebsd was this single line check for icmp, and I don't think removing that needs a sysctl or ifdef. assignment and routing already work. 

I agree that after kernel support lands that the next bigger barriers are firewalls, bcp38, and other devices on the path... and the ietf. Knocking out the ping issue is just one small step along the way.

Lastly, it's far from a lone dev at pushing this stuff forward again, however we totally don't mind just accumulating more patches in our repo until more visibility and consensus is achieved. That said... one line patch...
Comment 9 Dave Taht 2019-02-22 16:26:57 UTC
(In reply to Conrad Meyer from comment #2)
>Regardless of whether or not using class E addresses is canonical, we half-ass it >today.

+1

>If they're non-canonical, we should *not* allow them to be assigned to interfaces.

-1

>If they are, we shouldn't filter ICMP.

+1.

:) Thx for also spotting the other areas that needed to be addressed.
Comment 10 Conrad Meyer freebsd_committer 2019-02-22 18:10:39 UTC
(In reply to Dave Taht from comment #9)
> (In reply to Conrad Meyer from comment #2)
> >If they're non-canonical, we should *not* allow them to be assigned to interfaces.
> 
> -1

Help me understand the disagreement :-).  I guess I should clarify — in the absence of one or more enabled sysctl(s) permitting use of reserved address space, my conclusion is that we shouldn't allow reserved IP ranges to be assigned/routed.  Especially when we do not support them in other parts of the stack which will silently fail (ICMP, ipfw, forwarding; maybe others).

Maybe my suggestion is overstepping the intentions of the IPv4 RFC; it has been a long time since I looked at it, and class E wasn't my focus at the time.

Any way, if you want to elaborate on that, I'd love to learn more.  Thank you.