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. > 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. > > > 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
