fix bug in Prefix factory

[gsnider2195]

Closes: #DNE

What's Changed

• Fix bug in prefix factory when a /0 ipv6 network is generated by Faker
  • The string representation of UniqueFaker('pyint', min_length=1, max_length=128) was the class name instead of the actual value. In this context we need to call faker directly instead of using the lazy UniqueFaker (also, uniqueness wasn't actually needed here)
  • Also changed ipv6_cidr to unique to prevent duplicate prefix errors
  • Removed requirement that ipv4 prefixes be created in private address space

TODO

• Explanation of Change(s)
• Added change log fragment(s) (for more information see the documentation)
• Attached Screenshots, Payload Example
• Unit, Integration Tests
• Documentation Updates (when adding/changing features)
• Example Plugin Updates (when adding/changing features)
• Outline Remaining Work, Constraints from Design

[glennmatthews]

FWIW, after diving into the faker code, it looks like the ipv4 faker explicitly excludes a number of reserved address ranges, with the net result that the largest possible IPv4 network it will ever generate is a /3 such as 32./3, 64./3, or 128./3. The ipv6 faker has no such exclusions (though honestly it probably should), but I wonder if we should restrict min_value here to something like 8 just to avoid creating unrealistically large IPv6 subnets that cover the entire address space? (Unless you think we should work on a PR to faker instead... :-) )

[glennmatthews]

Also actually since ipv6_cidr is a network already, maybe min_value should be ipaddress.IPv6Network(ipv6_cidr).prefixlen so we only ever generate subnets of the original network rather than potentially creating supernets?

[gsnider2195]

Also actually since ipv6_cidr is a network already, maybe min_value should be ipaddress.IPv6Network(ipv6_cidr).prefixlen so we only ever generate subnets of the original network rather than potentially creating supernets?

This is only replacing /0 which is only valid for ::/0 so anything >0 will be a subset of the original network

[gsnider2195]

This was fixing a bug we were encountering where it wasn't actually returning an integer. The collision chance here should be around 128*128 so not perfect but probably not worth refactoring right now

[glennmatthews]

Thanks for clarifying my confusion! So now we have a 1/128 chance of getting something from ::/1 to ::/128 right? I wonder if we could/should instead just reject /0 entirely and "reroll" ipv6_cidr until we get something that isn't /0?

[gsnider2195]

Thanks for clarifying my confusion! So now we have a 1/128 chance of getting something from ::/1 to ::/128 right? I wonder if we could/should instead just reject /0 entirely and "reroll" ipv6_cidr until we get something that isn't /0?

I added a custom faker provider in 5202e0b to fix the problem in the default ipv6 faker provider and also allow it to use integers below the ipv4 max range (2**32). I'm not sure what that was doing but it didn't seem necessary.