nagaboinaramgopal commented on code in PR #14037:
URL: https://github.com/apache/cloudstack/pull/14037#discussion_r4188939504
##########
server/src/main/java/com/cloud/network/security/SecurityGroupManagerImpl.java:
##########
@@ -356,7 +356,7 @@ protected Map<PortAndProto, Set<String>>
generateRulesForVM(Long userVmId, Secur
cidr = cidr + "/32";
cidrs.add(cidr);
if (defaultNic.getIPv6Address() != null) {
- cidrs.add(defaultNic.getIPv6Address() + "/64");
+ cidrs.add(defaultNic.getIPv6Address() +
"/128");
Review Comment:
Thanks for raising this, it's a good thing to pin down. I went and looked at
the agent side to be sure, and I think we might actually be covered here,
though let me know if I'm missing a case.
From what I can see, a VM can't really put a self-chosen address on the wire
in an SG network anyway. The KVM agent installs a source anti-spoof rule in
`security_group.py` (the `-m set ! --match-set <vmipset6> src -j DROP` near the
end of the IPv6 default chain), and that ipset only gets the addresses
CloudStack assigned to the NIC. So a Windows temporary/privacy address wouldn't
be in the set, and its traffic would get dropped at that VM's own vNIC before
the receiving VM's member rule is ever looked at. If that reading is right,
then `/64` wasn't really letting those packets through either, they just died
earlier in the path.
Where `/64` did make a difference, I think, is that it also let any other VM
sharing that `/64` reach the protected VM, member or not, and narrowing to
`/128` lines it up with what the IPv4 side already does at `/32`. Does that
match how you understand it, or is there a setup where a VM ends up sending
from an address CloudStack didn't assign?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
