Thread: inet/cidr ipv6 operations

Good day.

We trying to implement IPv6 address space management with postgres
support, but I found few strange problems.

One of them - problems with math. In IPv4 we can be sure, that
inet'0.0.0.1' + N allows to get any address you want, because N < 2^64,
and IPv4 is just 32-bit size.

But IPv6 is differ. Let's assume we wants to get 'next' /64 range.
Current range is inet'2a00:ab00:0:1/64'. We want next.

Postgres do not allow adding inet + inet, so we need to add natural
number. But 'next' /64 is 'just' 2^64. And postgres rejecting that
operations because N is too large. ... And under some conditions we can
use even /56 or /48 - which is really large numbers.

If postgres allows to do something like that: inet'2a00:ab00:0:1/64' +
inet'0:0:0:1/64' it should make life much easy.

Or may be I miss something?

Thanks.

On Tue, Jan 29, 2013 at 9:34 PM, George Shuklin
<george.shuklin@gmail.com> wrote:
> But IPv6 is differ. Let's assume we wants to get 'next' /64 range. Current
> range is inet'2a00:ab00:0:1/64'. We want next.
>
> Postgres do not allow adding inet + inet, so we need to add natural number.
> But 'next' /64 is 'just' 2^64. And postgres rejecting that operations
> because N is too large. ... And under some conditions we can use even /56 or
> /48 - which is really large numbers.
>
> If postgres allows to do something like that: inet'2a00:ab00:0:1/64' +
> inet'0:0:0:1/64' it should make life much easy.

Or alternatively, does PostgreSQL have any integer type larger than
64-bit bigint? I've become accustomed to using bignums in most of my
programming; arbitrary-precision integers allow all sorts of handy
flexibilities. Are there any plans to add bignums (something like
GMP's mpz) to the engine?

ChrisA

Chris Angelico <rosuav@gmail.com> writes:
> Or alternatively, does PostgreSQL have any integer type larger than
> 64-bit bigint? I've become accustomed to using bignums in most of my
> programming; arbitrary-precision integers allow all sorts of handy
> flexibilities. Are there any plans to add bignums (something like
> GMP's mpz) to the engine?

It's hard to muster much excitement about that when we've already
got "numeric".

As far as the OP's problem goes, I wonder if there wouldn't be some use
in an inet+(big)int function that does shift-and-add, ie move the
integer over by the number of bits that have to remain zero according to
the netmask.  I'm not seeing the use for adding enormous random integers
to IP addresses --- but "three over from this /64 block" doesn't seem so
improbable.

            regards, tom lane

On Wed, Jan 30, 2013 at 2:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>> Or alternatively, does PostgreSQL have any integer type larger than
>> 64-bit bigint? I've become accustomed to using bignums in most of my
>> programming; arbitrary-precision integers allow all sorts of handy
>> flexibilities. Are there any plans to add bignums (something like
>> GMP's mpz) to the engine?
>
> It's hard to muster much excitement about that when we've already
> got "numeric".

True, but I wasn't able (with 9.1, so that might have changed since)
to add inet to numeric. Maybe that would be easier?

I don't think inet + inet is the right thing for this. It would make
just as much sense for inet '2000::/16' + inet '2001::/16' to equal
inet '2000::/15', so it's not going to "read" as clearly. Expanding
the "netblock + number" concept to numeric makes reasonable sense.

> As far as the OP's problem goes, I wonder if there wouldn't be some use
> in an inet+(big)int function that does shift-and-add, ie move the
> integer over by the number of bits that have to remain zero according to
> the netmask.  I'm not seeing the use for adding enormous random integers
> to IP addresses --- but "three over from this /64 block" doesn't seem so
> improbable.

Interesting. Not sure what sort of syntax would work there, but it
does grok well. Instead of thinking about an IPv6 block as a 128-bit
integer plus a tag, you can treat it as an N-bit integer, where N is
the CIDR length. I like it! And assuming your blocks are /64 or
larger, that'd cover all logical uses (I can imagine, for instance,
adding 65536 to a /64, but not adding 2^63).

ChrisA

Chris Angelico <rosuav@gmail.com> writes:
> On Wed, Jan 30, 2013 at 2:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It's hard to muster much excitement about that when we've already
>> got "numeric".

> True, but I wasn't able (with 9.1, so that might have changed since)
> to add inet to numeric. Maybe that would be easier?

There's no such function today, but it could be added if anyone cared
enough.

> I don't think inet + inet is the right thing for this.

Agreed, that doesn't seem very sensible --- it's a units failure,
in some sense.

            regards, tom lane