cloudfoundry
Add support for icmpv6 protocol
As described in https://datatracker.ietf.org/doc/html/rfc4443, ICMPv6 has a different protocol number and since cloud controller now supports IPv6 it should also support ICMPv6.
https://github.com/cloudfoundry/cloud_controller_ng/blob/32866b6a73466136f240415c91bd30a5a8f522fe/app/messages/validators/security_group_rule_validator.rb#L60
Is a icmpv6 protocol type in ASGs really required? The difference between icmpv4 and icmpv6 could be done based on the IP address format in the ASG destination. This makes especially sense since a destination can be comma separated list of IPv4 and IPv6 addresses/CIDRs.
Hey, @stephanme
I get the idea of inferring ICMPv6 based on the destination IP, but in my opinion, that adds hidden logic and can get messy, especially when ASG destinations mix IPv4 and IPv6. From Diego and Silk side, having "icmpv6" as an explicit protocol makes rules clearer and easier to audit. We’ve already implemented this as a separate protocol, and it’s currently under review. Given the work is already done and integrates cleanly without breaking anything, we’d prefer to keep it this way if possible.
Also worth noting ICMPv4 and ICMPv6 have different type/code definitions, so inferring the version from the destination IP breaks down when you try to validate or apply rules correctly.
Here’s a quick comparison:
| Purpose | ICMPv4 (RFC 792) | ICMPv6 (RFC 4443) |
|---|---|---|
| Echo Request | Type 8, Code 0 | Type 128, Code 0 |
| Echo Reply | Type 0, Code 0 | Type 129, Code 0 |
| Destination Unreachable | Type 3, Codes 0–15 | Type 1, Codes 0–6 |
| Time Exceeded | Type 11, Codes 0–1 | Type 3, Codes 0–1 |
| Packet Too Big | Not supported | Type 2, Code 0 |
| Redirect | Type 5 | Type 137 |
| Neighbor Discovery | Not applicable | Types 133–136 |
https://www.rfc-editor.org/rfc/rfc792.html - for v4 https://datatracker.ietf.org/doc/html/rfc4443#section-4.2 - for v6
The different type and code values are indeed an argument for having separate icmp and icmpv6 protocols in the ASG definition.
For the remaining protocols tcp, udp, and also all, destination lists can contain a mix of IPv4 and IPv6 addresses/ranges and this won't change. Especially for tcp and udp it makes sense as these are protocols above ip.
Wether it is a good idea to mix v4 and v6 addresses in an ASG rule or not is something I would leave to the user.
I agree, for tcp/udp it doesn't make any difference if addresses are mixed or not, we group them by version anyway when applying the rules
