The ip_range type seems to be used for two purposes: - traffic selectors
- ip address pools The two uses have diverged. Lots of complexity has been added for the address pool case which is not clearly correct or useful for the traffic selector case. Is there an RFC-based limit on range sizes for traffic selectors? If so, that should be enforced (i.e. violation should be failure, not truncation). If not, we should not trunctate them. For address pools, I think that we get to set the rules. It seems to me that 2^32 is large enough. That's what our code supports. Why not treat a larger size as an actual error rather than truncating to specified range? Then a lot of truncation logic goes away. Clearly this limit must be spelled out in the documentation (perhaps it is -- I haven't looked). The routines that currently do truncation don't know whether they are dealing with a traffic selector or an address pool. I suggest that the old ip_range type be reinstated and that a new type, perhaps "pool_range", be added with the new features. The pool_range type could be composed of an ip_range and some additions. Among other things, this would allow improved modularization and better diagnostics. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
