| ▲ | ilkkao a day ago |
| You can definitely craft an IP packet by hand and send it. If it's IPv4, you need to put a number between 0 and 255 to the protocol field from this list: https://www.iana.org/assignments/protocol-numbers/protocol-n... Core routers don't inspect that field, NAT/ISP boxes can. I believe that with two suitable dedicated linux servers it is very possible to send and receive single custom IP packet between them even using 253 or 254 (= Use for experimentation and testing [RFC3692]) as the protocol number |
|
| ▲ | Twisol a day ago | parent | next [-] |
| > If it's IPv4, you need to put a number between 0 and 255 to the protocol field from this list: To save a skim (though it's an interesting list!), protocol codes 253 and 254 are suitable "for experimentation and testing". |
|
| ▲ | morcus 19 hours ago | parent | prev | next [-] |
| What happens when the remaining 104 unassigned protocol numbers are exhausted? |
| |
| ▲ | hylaride 18 hours ago | parent | next [-] | | We're about half-way to exhausted, but a huge chunk of the ones assigned are long deprecated and/or proprietary technologies and could conceivably be reassigned. Assignment now is obviously a lot more conservative than it was in the 1980s. There is sometimes drama with it, though. Awhile back, the OpenBSD guys created CARP as a fully open source router failover protocol, but couldn't get an official IP number and ended up using the same one as VRRP. There's also a lot of historical animosity that some companies got numbers for proprietary protocols (eg Cisco got one for its then-proprietary EIGRP). https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers | |
| ▲ | Ekaros 15 hours ago | parent | prev | next [-] | | Probably use of some type of options. Up to 320 bits, so I think there is reasonable amount of space there for good while. Ofc, this makes really messy processing, but with current hardware not impossible. | |
| ▲ | marcosdumay 18 hours ago | parent | prev [-] | | People will start overloading the numbers. I do hope we'll have stopped using IPv4 by then... But well, a decade after address exhaustion we are still on it, so who knows? | | |
| ▲ | kbolino 17 hours ago | parent [-] | | IPv6 uses the exact same 8-bit codes as IPv4. It uses them a little differently -- in IPv4, there is one protocol per packet, while in IPv6, "protocols" can be chained in a mechanism called extension headers -- but this actually makes the problem of number exhaustion more acute. | | |
| ▲ | brewmarche 15 hours ago | parent [-] | | What if extension headers made it better? We could come up with a protocol consisting solely of a larger Next Header field and chain this pseudo header with the actual payload whenever the protocol number is > 255. The same idea could also be used in IPv4. | | |
| ▲ | kbolino 15 hours ago | parent [-] | | I didn't mean to imply otherwise. But, as you say, this is equally applicable to IPv4 and IPv6. There were a lot of issues solved by IPv6, but "have even more room for non-TCP/UDP transports" wasn't one of them (and didn't need to be, tbqh). | | |
| ▲ | brewmarche 9 hours ago | parent [-] | | I agree, although I am a bit surprised to see that we’ve used more than half of the protocol numbers already |
|
|
|
|
|
|
| ▲ | rfmoz 15 hours ago | parent | prev | next [-] |
| Playing with protocol number change usually results in “Protocol Unreachable” or “Malformed Packet” from your OS. |
|
| ▲ | inglor_cz a day ago | parent | prev | next [-] |
| This is an interesting list; it makes you appreciate just how many obscure protocols have died out in practice. Evolution in networks seems to mimic evolution in nature quite well. |
|
| ▲ | stavros a day ago | parent | prev [-] |
| Very interesting, thanks! |
