On Mon, 14 Oct 2019 at 05:44, Antony Antony <[email protected]> wrote: > > On Sun, Oct 13, 2019 at 01:18:29PM -0400, Andrew Cagney wrote: > > PS: > > > > Moving the size logic out of ttorange() and into a function vis: > > agree. Though I want to recored is_subet (with /) or a range (with > - ) inside the ttorange. That is important for jam_range.
Yes, the two are unrelated. Like your comment says, it's just a hint to jam_range(). Once size and "overflow" are turned into a function (which makes them robust - redundancy in these structures has proven dangerous) we've no need for a new type. Least of all one that only address-pool might need. > > bool range_size(const ip_range *range, uintmax_t *staturated_size) > > MUST_USE_RESULT /* false if overflow */ > > > > (same for converse range+offset) I think does have merit. > > I have the similar idea. If the offset is variable lease the address could > begin closer to the prefix boundry. > > > > On Sun, 13 Oct 2019 at 12:49, Andrew Cagney <[email protected]> wrote: > > > > > > On Sun, 13 Oct 2019 at 11:04, D. Hugh Redelmeier <[email protected]> wrote: > > > > > > > > The ip_range type seems to be used for two purposes: > > > > > > > > - traffic selectors > > > > > > The (ikev2) traffic selector code outputs an ip_subnet, not an > > > ip_range Internally it just happens to use an ip_range as part of the > > > journey towards a subnet. Like the comment points out: > > in ikev2 traffic selectors it is a transient use. I tempted to leave > ip_range the same for now. Your next argument is more convincing. See > bellow. > > > > /* > > > * This is not the subnet you're looking for. > > > * > > > * In libreswan ip_subnet is used to store client routing information. > > > * IKEv2 calls this traffic selectors and it allows the negotiation > > > * of: > > > * > > > * LO_ADDRESS..HI_ADDRESS : LO_PORT..HI_PORT > > > * > > > * The structures below can only handle a limited subset of this, > > > * namely: > > > * > > > * NETWORK_PREFIX | 0 / MASK : PORT > > > * > > > * where PORT==0 imples 0..65535, and (presumably) port can only be > > > * non-zero when the NETWORK_PREFIX/MASK is for a single address. > > > */ > > > > > > > > > > > > > - 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. > > no. I don't think so. Libreswan and linux kernel currenly only accept a > subnet. I herd a Kernel developer, Stefeen, mumbling add kernel support for > range because in RFC IP and port are ranges. > > > > > > > > > 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). > > > > > > This is what Antony did. > > Yes. > > However, there is convience factor in accepting smaller prefixes say /64, > even upto /32 and for testing purposes /1; even though size is truncated to > to 2^32-1. Right. The only thing that uses size is the address pool. It doesn't need to be in ip_range, and there doesn't need to be a new type. > > > > 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. > > > > > > sure. sounds good to me. I don't have a preference. I guess I will move the > .size to ip_pool and size computation a funcation as Andrew suggest. > > > > > Among other things, this would allow improved modularization and > > > > better diagnostics. > > -antony > _______________________________________________ > Swan-dev mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
