0

Problem description: Does internet router discard UDP packet which has IP option data?

I have two hosts which both have internet IPv4 address, and installed ubuntu 20.04. If I send normal UDP packet which has no IP option data, host B will receive the UDP packet.

When I use sendip tool to send UDP packet with 4 bytes IP option data in IP header from host A to host B. Then host B can not receive the UDP packet.

More tests:

  1. When I send icmp/UDP packet which there is no IP option data from host A to host B. Then host B received icmp/UDP packet normally.

2)When I send UDP packet which has 4 byte IP option data from host A to host B. host B will not received the packet. 3) When I send UDP packetwhich has 4 byte IP option data from Windows PC to ubuntu PC. windows PC can receive the UDP packets. When send same packet from windows PC to ubuntu PC, then ubuntu PC will receive the UDP packet.

Does the internet router will discard UDP/TCP packet which has IP option data?

**command example: ** sendip -v -p ipv4 -is 156.254.126.xxx -id 111.229.170.xx -iosid 100 -p udp -us 3000 -ud 8000 -d 0xcafecafecafe 111.229.170.xx

tcpdump src 156.254.126.xxx -vvv

4
  • Do every router somewhere on the internet discards this - probably not. Do some or many routers on the internet discard this - your experiment clearly suggests this. Do you want some explanation why this is the case - see Recommendations on Filtering of IPv4 Packets Containing IPv4 Options - RFC 7126 also known as BCP 186. Commented May 4, 2024 at 7:43
  • Thanks for your response. In RFC7126, it descripted that all the IP options's advice for the router and firewall . Normally, all the packet with IP options should be discard. The IP option type 0 and type 1 should not be dropped. Now, I want to add some information to the IP packet. The normal way is to use IP option. Is there any IP option type which I can use? Commented May 6, 2024 at 12:53
  • What you basically want is an IP option with unspecified semantic ("... add some information to the IP packet") but which nevertheless should not be dropped. The RFC 7216 clearly says that such unspecified semantics also means impossible to evaluate security implications - and thus that in reality it will often gets blocked for this reason. Which suggests that maybe you should not use custom IP options for whatever unknown use case you want to implement, at least as long there are networks involved outside of your control. Commented May 6, 2024 at 14:12
  • Thanks for your advice. I think a better way is to keep some IP option types that can be passed through. If the new router can recognize the special IP option type, it will handle it on its own. And if the old router cannot recognize it, it will be transmitted through. Then the old router can support compatibility with new protocols and feature extensions without any security risks. For eg, each IP option can carried stream ID. With the stream ID, many extensions can be made in the new router. But RFC7216/RFC6814 has cleared almost all IP option types, we can only think of other ways. Commented May 9, 2024 at 2:14

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.