7 ms·

Curious case of Martian traffic in Linux

schoen 3y ago
It's not correct that the modern Linux kernel refuses to forward packets with a source address in 0.0.0.0/8. The only address that it refuses to forward this way is 0.0.0.0/32. I just got a patch into the ip(7) man page that describes this https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=8cf319f3db889f80b0309ac32ef61be0b7d8cb94 https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/... although there hasn't been a man-pages release since then, so you probably can't see this on your own system yet. The original change (included in Linux 5.3) is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96125bf9985a75db00496dd2bc9249b777d2b19b https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... (I'm working on a project that aims to make these addresses potentially useful for numbering Internet hosts in the future, as part of which Dave Taht's patch linked above was written, so I follow this very closely!) Separately, you need to be able to process a 0.0.0.0/32 source address on external interfaces (though not to forward it) in order to be able to implement a DHCP server, as that's the source address used by DHCP clients. (edit: another commenter pointed out that this commonly uses raw sockets so it doesn't necessarily require any explicit kernel support)
- usovalx 3y ago
  May dhcp client/servers are using raw sockets and will thus bypass incorrect firewall config/martian packet filtering.
  - schoen 3y ago
    Yes, I forgot about that but you're right that that's the typical implementation method. So the DHCP case does not necessarily need any special kernel support (other than not prefiltering before the raw socket). Thanks for the correction.
- bombcar 3y ago
  Is there any similar work to change 127/8 to be something more reasonable like 127/16 or 24?
  - schoen 3y ago
    We have proposed it! https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-127-03.html https://www.ietf.org/archive/id/draft-schoen-intarea-unicast... The big prize is 240/4. https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-04.html https://www.ietf.org/archive/id/draft-schoen-intarea-unicast... Our proposals have not been warmly received in the intarea WG so far.
    - jacquesm 3y ago
      I think it is pretty reasonable to be reluctant to make such changes because it may well break stuff.
      - schoen 3y ago
        Well, for 240/4 in particular we (in a very expansive sense of "we"¹) started making the change back in 2008 in response to https://datatracker.ietf.org/doc/pdf/draft-fuller-240space-00 https://datatracker.ietf.org/doc/pdf/draft-fuller-240space-0... If we (for an expansive sense of "we") had kept it up more actively, we would already have had 15 years of progress on updating implementations and evolving people's expectations. That wouldn't have been a super-fast change, necessarily. We (for a narrow sense of "we") think it's pretty likely that people will still be interested in having more IPv4 space in 15 years from now, so it's too bad that progress is (somewhat) stalled on this (with most Unix-like systems allowing it, and Windows not allowing it, and dedicated routers from before about 2013-2016 often not allowing it). ¹ the specific project I'm working on, started by John Gilmore, didn't exist yet at that time, but is trying to revive/continue this idea
        jacquesm 3y ago
        Fair enough, but that more or less emphasizes my point: if it wasn't done by 2010 or so that means that a ton of IoT hardware has now shipped that may never see updates and that would possibly end up failing when presented with such a departure from what the expected behavior was at the time the hardware was shipped. You change old established standards at your peril, especially how IPV4 is routed and which ranges are reserved. There are quite a few things that retrospectively could have been handled better and a large number of huge ranges got handed out like candy back in the day. Some of those have been reclaimed and some still remain. It may be easier and with less chance of breaking stuff if those ranges were reclaimed more aggressively.
prewett 3y ago
I was hoping this was somebody with network equipment in NASA, seeing actual DSN traffic over their network...
Robotbeat 3y ago
I thought this was about actual interplanetary networking. Can we change the title to be less clickbait and more informative?
- knome 3y ago
  https://en.wikipedia.org/wiki/Martian_packet https://en.wikipedia.org/wiki/Martian_packet A quick usenet search shows references to the term back into the 90's.
  - kamray23 3y ago
    The RFC which defines the term is from 1995, so it's been established enough to find its way into an RFC 28 years ago.
    - JdeBP 3y ago
      If one reads RFC 1812, one finds that it does not exactly define the term. It uses it in a heading but doesn't use it in a way that agrees with its later definition of "martian", since its explanation of "martian address filtering" encompasses traffic that is not "martian" per its own glossary. A contemporary definition that is not self-contradictory is in Eric S. Raymond's New Hacker's Dictionary, published four years earlier; but which isn't what RFC 1812 says either, however. So whilst the people who weren't alive in the 1990s are wrong to be hung up on the "I thought it meant 'from Mars'." confusion, since the saddening reality of 2023 is that we're no nearer to that being a realistic source of confusion than we were in 1991; the obverse of the coin is that, like much of the Jargon File, it's woolly slang set over-hard into stone by Eric S. Raymond and a document from Cisco that it is unwise to rely upon for strict technical meaning.
      - Robotbeat 3y ago
        > So whilst the people who weren't alive in the 1990s are wrong to be hung up on the "I thought it meant 'from Mars'." confusion, since the saddening reality of 2023 is that we're no nearer to that being a realistic source of confusion than we were in 1991; There’s a Mars Fleet of about 11 operational spacecraft and robotic landers/rovers/etc on or around Mars right now, and in fact the robotic helicopter, Ingenuity, runs Linux. I legitimately thought it was related to those. There were no operational missions at Mars in 1991. https://svs.gsfc.nasa.gov/4414 https://svs.gsfc.nasa.gov/4414 https://en.wikipedia.org/wiki/List_of_missions_to_Mars https://en.wikipedia.org/wiki/List_of_missions_to_Mars
denton-scratch 3y ago
A martian is a packet that has a source address in a network for which the interface it's arriving on isn't configured. They're not restricted to 0/8; they can have just about any source address. > The best way to fix this issue is to change Netflow / IPFIX / sFlow agent configuration on device to use another legitimate IP address instead of 0.0.0.0. Um, yes. 0.0.0.0 looks like a really bad choice of source address.
renewiltord 3y ago
> It's relatively tricky to read as text and you may prefer to look on screenshot of my console If you copy it from the console and then use a `<pre>` tag rather than a `<blockquote>` tag it'll work well. See here: https://i.imgur.com/gAsb9TR.png https://i.imgur.com/gAsb9TR.png
- pronoiac 3y ago
  It's Ghost, so Markdown's available, and you could use a triple-backtick block, ``` before and after.
gumby 3y ago
"martian" isn't an official term from the RFCs, and is terrible usage. If linux is not running on mars at the moment (perhaps in the Chinese rover?) it surely will be in the not too distant future. And a router in orbit may need to distinguish between martian and terrestrial traffic. Which the code can easily do of course, but a foolish name like this could confuse someone debugging code during development, or worse while debugging a communication problem in process far away. (BTW this is an earnest, not humorous comment).
- kamray23 3y ago
  Martian is an official term from the RFC's, though? It's mentioned in section 5.3.7 of RFC 1812 from 1995. That happens to be the exact section of the exact RFC with the recommendation whose kernel implementation is shown in the article. It seems to be fairly established terminology, having sat in that RFC for the last 28 years.
  - gumby 3y ago
    Thanks! It wasn't in the ones I looked at. Darn, it's still a short-sighted choice. Even "interstellar" would be good for another 75 years or so ( https://i4is.org/what-we-do/technical/project-dragonfly/ https://i4is.org/what-we-do/technical/project-dragonfly/ ), though "intergalactic" would be better, even if ipv6 were used.
    - kamray23 3y ago
      Jump it in the middle with "intergalactic planetary, planetary intergalactic" packets and nobody can think it's actually from space.
      - gumby 3y ago
        “TilBrooklyn” would be less confusing.
- kadoban 3y ago
  To me it does not seem like it would arise in similar enough contexts to be confusing. "Martian" meaning the planet would come up in application code, not in the kernel. Why would the kernel even have that concept?
jimmaswell 3y ago
Why would the external device use this ip in the first place?
hoseja 3y ago
https://pavel.network/content/images/2023/04/drop.png https://pavel.network/content/images/2023/04/drop.png Why can't RFCs be readable by default? Why do they still have explicit line- and page-breaks and fixed-width fonts?

It's not correct that the modern Linux kernel refuses to forward packets with a source address in 0.0.0.0/8. The only address that it refuses to forward this way is 0.0.0.0/32. I just got a patch into the ip(7) man page that describes this https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=8cf319f3db889f80b0309ac32ef61be0b7d8cb94 https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/... although there hasn't been a man-pages release since then, so you probably can't see this on your own system yet. The original change (included in Linux 5.3) is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96125bf9985a75db00496dd2bc9249b777d2b19b https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... (I'm working on a project that aims to make these addresses potentially useful for numbering Internet hosts in the future, as part of which Dave Taht's patch linked above was written, so I follow this very closely!) Separately, you need to be able to process a 0.0.0.0/32 source address on external interfaces (though not to forward it) in order to be able to implement a DHCP server, as that's the source address used by DHCP clients. (edit: another commenter pointed out that this commonly uses raw sockets so it doesn't necessarily require any explicit kernel support)

usovalx 3y ago
May dhcp client/servers are using raw sockets and will thus bypass incorrect firewall config/martian packet filtering.
- schoen 3y ago
  Yes, I forgot about that but you're right that that's the typical implementation method. So the DHCP case does not necessarily need any special kernel support (other than not prefiltering before the raw socket). Thanks for the correction.
bombcar 3y ago
Is there any similar work to change 127/8 to be something more reasonable like 127/16 or 24?
- schoen 3y ago
  We have proposed it! https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-127-03.html https://www.ietf.org/archive/id/draft-schoen-intarea-unicast... The big prize is 240/4. https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-04.html https://www.ietf.org/archive/id/draft-schoen-intarea-unicast... Our proposals have not been warmly received in the intarea WG so far.
  - jacquesm 3y ago
    I think it is pretty reasonable to be reluctant to make such changes because it may well break stuff.
    - schoen 3y ago
      Well, for 240/4 in particular we (in a very expansive sense of "we"¹) started making the change back in 2008 in response to https://datatracker.ietf.org/doc/pdf/draft-fuller-240space-00 https://datatracker.ietf.org/doc/pdf/draft-fuller-240space-0... If we (for an expansive sense of "we") had kept it up more actively, we would already have had 15 years of progress on updating implementations and evolving people's expectations. That wouldn't have been a super-fast change, necessarily. We (for a narrow sense of "we") think it's pretty likely that people will still be interested in having more IPv4 space in 15 years from now, so it's too bad that progress is (somewhat) stalled on this (with most Unix-like systems allowing it, and Windows not allowing it, and dedicated routers from before about 2013-2016 often not allowing it). ¹ the specific project I'm working on, started by John Gilmore, didn't exist yet at that time, but is trying to revive/continue this idea
      - jacquesm 3y ago
        Fair enough, but that more or less emphasizes my point: if it wasn't done by 2010 or so that means that a ton of IoT hardware has now shipped that may never see updates and that would possibly end up failing when presented with such a departure from what the expected behavior was at the time the hardware was shipped. You change old established standards at your peril, especially how IPV4 is routed and which ranges are reserved. There are quite a few things that retrospectively could have been handled better and a large number of huge ranges got handed out like candy back in the day. Some of those have been reclaimed and some still remain. It may be easier and with less chance of breaking stuff if those ranges were reclaimed more aggressively.

prewett 3y ago

I was hoping this was somebody with network equipment in NASA, seeing actual DSN traffic over their network...

Robotbeat 3y ago

I thought this was about actual interplanetary networking. Can we change the title to be less clickbait and more informative?

knome 3y ago
https://en.wikipedia.org/wiki/Martian_packet https://en.wikipedia.org/wiki/Martian_packet A quick usenet search shows references to the term back into the 90's.
- kamray23 3y ago
  The RFC which defines the term is from 1995, so it's been established enough to find its way into an RFC 28 years ago.
  - JdeBP 3y ago
    If one reads RFC 1812, one finds that it does not exactly define the term. It uses it in a heading but doesn't use it in a way that agrees with its later definition of "martian", since its explanation of "martian address filtering" encompasses traffic that is not "martian" per its own glossary. A contemporary definition that is not self-contradictory is in Eric S. Raymond's New Hacker's Dictionary, published four years earlier; but which isn't what RFC 1812 says either, however. So whilst the people who weren't alive in the 1990s are wrong to be hung up on the "I thought it meant 'from Mars'." confusion, since the saddening reality of 2023 is that we're no nearer to that being a realistic source of confusion than we were in 1991; the obverse of the coin is that, like much of the Jargon File, it's woolly slang set over-hard into stone by Eric S. Raymond and a document from Cisco that it is unwise to rely upon for strict technical meaning.
    - Robotbeat 3y ago
      > So whilst the people who weren't alive in the 1990s are wrong to be hung up on the "I thought it meant 'from Mars'." confusion, since the saddening reality of 2023 is that we're no nearer to that being a realistic source of confusion than we were in 1991; There’s a Mars Fleet of about 11 operational spacecraft and robotic landers/rovers/etc on or around Mars right now, and in fact the robotic helicopter, Ingenuity, runs Linux. I legitimately thought it was related to those. There were no operational missions at Mars in 1991. https://svs.gsfc.nasa.gov/4414 https://svs.gsfc.nasa.gov/4414 https://en.wikipedia.org/wiki/List_of_missions_to_Mars https://en.wikipedia.org/wiki/List_of_missions_to_Mars

denton-scratch 3y ago

A martian is a packet that has a source address in a network for which the interface it's arriving on isn't configured. They're not restricted to 0/8; they can have just about any source address. > The best way to fix this issue is to change Netflow / IPFIX / sFlow agent configuration on device to use another legitimate IP address instead of 0.0.0.0. Um, yes. 0.0.0.0 looks like a really bad choice of source address.

renewiltord 3y ago

> It's relatively tricky to read as text and you may prefer to look on screenshot of my console If you copy it from the console and then use a `<pre>` tag rather than a `<blockquote>` tag it'll work well. See here: https://i.imgur.com/gAsb9TR.png https://i.imgur.com/gAsb9TR.png

pronoiac 3y ago
It's Ghost, so Markdown's available, and you could use a triple-backtick block, ``` before and after.

gumby 3y ago

"martian" isn't an official term from the RFCs, and is terrible usage. If linux is not running on mars at the moment (perhaps in the Chinese rover?) it surely will be in the not too distant future. And a router in orbit may need to distinguish between martian and terrestrial traffic. Which the code can easily do of course, but a foolish name like this could confuse someone debugging code during development, or worse while debugging a communication problem in process far away. (BTW this is an earnest, not humorous comment).

kamray23 3y ago
Martian is an official term from the RFC's, though? It's mentioned in section 5.3.7 of RFC 1812 from 1995. That happens to be the exact section of the exact RFC with the recommendation whose kernel implementation is shown in the article. It seems to be fairly established terminology, having sat in that RFC for the last 28 years.
- gumby 3y ago
  Thanks! It wasn't in the ones I looked at. Darn, it's still a short-sighted choice. Even "interstellar" would be good for another 75 years or so ( https://i4is.org/what-we-do/technical/project-dragonfly/ https://i4is.org/what-we-do/technical/project-dragonfly/ ), though "intergalactic" would be better, even if ipv6 were used.
  - kamray23 3y ago
    Jump it in the middle with "intergalactic planetary, planetary intergalactic" packets and nobody can think it's actually from space.
    - gumby 3y ago
      “TilBrooklyn” would be less confusing.
kadoban 3y ago
To me it does not seem like it would arise in similar enough contexts to be confusing. "Martian" meaning the planet would come up in application code, not in the kernel. Why would the kernel even have that concept?

jimmaswell 3y ago

Why would the external device use this ip in the first place?

hoseja 3y ago

https://pavel.network/content/images/2023/04/drop.png https://pavel.network/content/images/2023/04/drop.png Why can't RFCs be readable by default? Why do they still have explicit line- and page-breaks and fixed-width fonts?