Brokenness in parsing of pg_hba.conf

So one of the client machines for one of my databases at work resides
on 10.128.0.45. I had to enter something in pg_hba.conf for it today,
as we're bringing this database up. We have a lot of 10/8 subnets, and
I use it at home, so I'm accustomed to just using 10.128.45 for the IP.
Strangely, however, postgres refused to acknowledge the host when it
connected. I checked it again, and sure enough, the IP was right. It
turns out that postgres parses pg_hba.conf in an unexpected way -- it
does not accept "abbreviated" ip4 addresses (note that this is common
in both ip4 and ip6).

In the manpage for inet_aton, we see:

INTERNET ADDRESSES (IP VERSION 4)
Values specified using the `.' notation take one of the following forms:

a.b.c.d
a.b.c
a.b
a

When four parts are specified, each is interpreted as a byte of data and
assigned, from left to right, to the four bytes of an Internet address.

Andrew Dunstan on IRC mentioned that the parser is using the native
getaddrinfo. I'm not sure if there are any advantages to this; I've
said before that I'm really not a C guy.

Paul Vixie had this to say about the convention:

> What this man page is trying to tell you is that BSD users have
> historically said "10.73" rather than "10.0.0.73" because they both
> worked any place where either worked. This includes DNS primary zone
> files, by the way.
>
>
> I am pretty much assuming that the IETF does not want to standardize
> this BSD practice, and that we ought not to accept ::10.73 as
> equivilent to the longer ::10.0.0.73, especially given that the
> degenerate case given in that man page would be ambiguous with respect
> to ::1234, a valid RFC1884 address specifier whose low order 16 bits
> are hexadecimal 1234 rather than decimal 1234.
>
>
> However, that's only _my_ assumption, and some other implementor may
> feel differently. In fact some other implementor of RFC 1884 might
> decide to just call inet_aton() for parsing that IPv4 "dotted quad",
> which is what I almost did.

The original article can be found here:

http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1996-06/0037.html

I think it is important that postgres behave as expected when handing
it a properly formatted ip4 address. However, I'm aware that many
people don't even realize this is a valid address. As such, I won't
lose any sleep over it, but I thought I'd mention it, since it
surprised me today.

Thoughts?

Alex

--
alex(at)posixnap(dot)net
Alex J. Avriette, Solaris Frobnosticator
"You can get much farther with a kind word and a gun than you can with a kind word alone." - Al Capone

A few points.

1. clarification of my IRC comment: A quick examination seems to shaw
that we use the native getaddrinfo() where it exists, otherwise we use
our own, which in turn calls inet_ntoa().
2. ip6 has a well defined standard for abbreviation, and is quite
important to have since ip6 addresses would otherwise often be tediously
long. I haven't found a comparable standard for abbreviating IP4
addresses. There appears to be a convention relying on behaviour of
inet_aton, and perhaps hallowed by history, but by any measure surely
brain dead and counter intuitive. Why would a.b.c become a.b.0.c and a.b
become a.0.0.b? On Linux it is not even documented. See the email from
Paul Vixie cited below for futher gory details, including a citation of
rfc1208 that specifies exactly 4 parts for a dotted notation. It's not
surprising that he starts one sentence thus: "Now, before you laugh so
hard you fall out of your collective seats,".
3. Maybe some people are used to it. In around 15 years of using and
administering Unix I haven't tripped over this before, so I suspect it's
probably not a huge problem :-)
4. My personal preference would be that if any change is made it would
be to insist on an unabbreviated dotted quad for ip4. Alternatively, we
need to make sure that whatever we do is consistent. That might not be
possible, however, if different platforms or different library calls
behave differently.

cheers

andrew

Alex J. Avriette wrote:

>So one of the client machines for one of my databases at work resides
>on 10.128.0.45. I had to enter something in pg_hba.conf for it today,
>as we're bringing this database up. We have a lot of 10/8 subnets, and
>I use it at home, so I'm accustomed to just using 10.128.45 for the IP.
>Strangely, however, postgres refused to acknowledge the host when it
>connected. I checked it again, and sure enough, the IP was right. It
>turns out that postgres parses pg_hba.conf in an unexpected way -- it
>does not accept "abbreviated" ip4 addresses (note that this is common
>in both ip4 and ip6).
>
>In the manpage for inet_aton, we see:
>
>INTERNET ADDRESSES (IP VERSION 4)
> Values specified using the `.' notation take one of the following forms:
>
> a.b.c.d
> a.b.c
> a.b
> a
>
> When four parts are specified, each is interpreted as a byte of data and
> assigned, from left to right, to the four bytes of an Internet address.
>
>Andrew Dunstan on IRC mentioned that the parser is using the native
>getaddrinfo. I'm not sure if there are any advantages to this; I've
>said before that I'm really not a C guy.
>
>Paul Vixie had this to say about the convention:
>
>
>
>>What this man page is trying to tell you is that BSD users have
>>historically said "10.73" rather than "10.0.0.73" because they both
>>worked any place where either worked. This includes DNS primary zone
>>files, by the way.
>>
>>
>>I am pretty much assuming that the IETF does not want to standardize
>>this BSD practice, and that we ought not to accept ::10.73 as
>>equivilent to the longer ::10.0.0.73, especially given that the
>>degenerate case given in that man page would be ambiguous with respect
>>to ::1234, a valid RFC1884 address specifier whose low order 16 bits
>>are hexadecimal 1234 rather than decimal 1234.
>>
>>
>>However, that's only _my_ assumption, and some other implementor may
>>feel differently. In fact some other implementor of RFC 1884 might
>>decide to just call inet_aton() for parsing that IPv4 "dotted quad",
>>which is what I almost did.
>>
>>
>
>The original article can be found here:
>
>http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1996-06/0037.html
>
>I think it is important that postgres behave as expected when handing
>it a properly formatted ip4 address. However, I'm aware that many
>people don't even realize this is a valid address. As such, I won't
>lose any sleep over it, but I thought I'd mention it, since it
>surprised me today.
>
>Thoughts?
>
>Alex
>
>--
>alex(at)posixnap(dot)net
>Alex J. Avriette, Solaris Frobnosticator
>"You can get much farther with a kind word and a gun than you can with a kind word alone." - Al Capone
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
>
>

On Tue, Jan 06, 2004 at 10:52:19PM -0500, Andrew Dunstan wrote:

> 4. My personal preference would be that if any change is made it would
> be to insist on an unabbreviated dotted quad for ip4. Alternatively, we

I really think this is the wrong way to approach it. The 127.1
convention is common, and valid. To disallow it because you haven't
experienced it is pretty egocentric. If you would instead object on the
grounds of it being difficult to implement, or non portable, or
outright incorrect, I would be fine with it. But the attitude of "I've
never seen this, and I don't like it, regardless of the documentation"
just sucks.

> need to make sure that whatever we do is consistent. That might not be
> possible, however, if different platforms or different library calls
> behave differently.

In how many places are we using inet_aton? I see in the docs:

http://www.postgresql.org/docs/7.4/static/datatype-net-types.html#DATATYPE-INET

It looks like the abbreviated addresses there refer to networks (like
the RFC says). Additionally, if you give it '192.168.1/32', you get
192.168.1.0/32. This is even weirder than I expected.

I'd really like to hear from others what their opinions on this are.

alex

--
alex(at)posixnap(dot)net
Alex J. Avriette, Shepherd of wayward Database Administrators
"We are paying through the nose to be ignorant." - Larry Ellison

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> 1. clarification of my IRC comment: A quick examination seems to shaw
> that we use the native getaddrinfo() where it exists, otherwise we use
> our own, which in turn calls inet_ntoa().
> 2. ip6 has a well defined standard for abbreviation, and is quite
> important to have since ip6 addresses would otherwise often be tediously
> long. I haven't found a comparable standard for abbreviating IP4
> addresses.

AFAICS, Alex is quite far out in left field to believe that this is a
standard notation. The fact that some BSD platforms have accepted it
does not make it standard, especially not when Vixie's research shows
that there is no RFC to legitimize it. (Personally I never heard of
it before either, not that that proves much...)

> 4. My personal preference would be that if any change is made it would
> be to insist on an unabbreviated dotted quad for ip4.

I can't get excited about replacing or second-guessing the platform's
getaddrinfo() or inet_aton() implementation. If you don't like how
those library routines behave, forward your bug report appropriately
--- but it's not Postgres' problem.

regards, tom lane

"Alex J. Avriette" <alex(at)posixnap(dot)net> writes:
> I really think this is the wrong way to approach it. The 127.1
> convention is common, and valid.

AFAICS your own platform's C library doesn't support it, which means
you are on pretty shaky ground to make this claim.

regards, tom lane

"Alex J. Avriette" <alex(at)posixnap(dot)net> writes:
> In how many places are we using inet_aton?

BTW, further digging shows that when the platform has neither
getaddrinfo nor inet_aton, we fall back to src/port/inet_aton.c,
which is a BSD-derived bit of code that behaves exactly as per
your man page quote.

So I'm pretty well convinced that your gripe is misdirected: you
should be complaining to the authors of your C library.

regards, tom lane

On Tue, Jan 06, 2004 at 11:38:44PM -0500, Tom Lane wrote:

> AFAICS, Alex is quite far out in left field to believe that this is a
> standard notation. The fact that some BSD platforms have accepted it

How did I know you'd say that, Tom?

By "standard," I mean, "many people use it." Not, "some standard is
defined." For me, the manpage is enough. Additionally, the fact that I
(and you) can ping 127.1 on our (your) machine is enough for me. Go on,
try it.

> does not make it standard, especially not when Vixie's research shows
> that there is no RFC to legitimize it. (Personally I never heard of

Vixie is known for being slightly ... irritable. If he encounters something
he doesn't like, his first response is "oh, that's stupid." It seems strange
that Linux, BSD, and Solaris (I can investigate IRIX and OSF1 tomorrow) all
support it if it is either incorrect or nonstandard. We're not talking about
just BSD here.

> > 4. My personal preference would be that if any change is made it would
> > be to insist on an unabbreviated dotted quad for ip4.
>
> I can't get excited about replacing or second-guessing the platform's
> getaddrinfo() or inet_aton() implementation. If you don't like how

Given on both Solaris (my database server) and OpenBSD (the machine from
which that manpage came from) I can connect to 127.1, I think you must
be mistaken here. What made you think that it isn't supported?

> those library routines behave, forward your bug report appropriately
> --- but it's not Postgres' problem.

There isn't any point in filing a bug if it will be ignored.

alex

--
alex(at)posixnap(dot)net
Alex J. Avriette, Unix Systems Gladiator
"You cannot invade the mainland United States. There would be a rifle behind each blade of grass." - Admiral Isoroku Yamamoto

"Alex J. Avriette" <alex(at)posixnap(dot)net> writes:
> Given on both Solaris (my database server) and OpenBSD (the machine from
> which that manpage came from) I can connect to 127.1, I think you must
> be mistaken here. What made you think that it isn't supported?

AFAICT, our code simply hands the string off to a C library function ---
either getaddrinfo() or inet_aton() depending on what your platform has.
If it's not behaving the way you want, it's the fault of one of those
routines.

Just to verify, I changed "127.0.0.1" to "127.1" in my local pg_hba.conf
(this is on HPUX 10.20, which has inet_aton but not getaddrinfo), and
could still connect over localhost TCP ... then changed it to "127.2",
and could not connect. So I don't believe there is anything in the PG
code that is discriminating against addresses written this way.

If you still think the problem is PG's and not your C library's, I
invite you to trace through the code and show where we're going wrong.
But right at the moment I don't believe this is our bug.

regards, tom lane

Alex J. Avriette said:
> On Tue, Jan 06, 2004 at 10:52:19PM -0500, Andrew Dunstan wrote:
>
>> 4. My personal preference would be that if any change is made it would
>> be to insist on an unabbreviated dotted quad for ip4. Alternatively,
>> we
>
> I really think this is the wrong way to approach it. The 127.1
> convention is common, and valid. To disallow it because you haven't
> experienced it is pretty egocentric. If you would instead object on the
> grounds of it being difficult to implement, or non portable, or
> outright incorrect, I would be fine with it. But the attitude of "I've
> never seen this, and I don't like it, regardless of the documentation"
> just sucks.
>

Alex,

I think you should be a little less ready to throw around terms of
opprobrium like this.

First, note that I stated that this was my *personal* preference, and that
it only applied if a change was to be made. People here, including me,
often follow a consensus rather than their personal preferences.

Second, you state that this usage is valid. When you first raised the
matter, you were so certain that it was sanctified by standard that you
asked me if I would implement it if you could quote an RFC sanctifying it
(I said yes) and went off to find one. To your surprise, you couldn't, and
now want to say that "valid" is defined for every OS in every context by
the man page for one library call on one OS (or possibly several).

Tom has challenged you to prove that this is caused by Pg code and not
code in your native libraries. Until then, the matter should rest.

cheers

andrew

"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:

> Second, you state that this usage is valid. When you first raised the
> matter, you were so certain that it was sanctified by standard that you
> asked me if I would implement it if you could quote an RFC sanctifying it
> (I said yes) and went off to find one. To your surprise, you couldn't, and
> now want to say that "valid" is defined for every OS in every context by
> the man page for one library call on one OS (or possibly several).

Would the POSIX/IEEE/SuS be authoritative enough?

http://www.opengroup.org/onlinepubs/007904975/functions/getaddrinfo.html

If the specified address family is AF_INET or AF_UNSPEC, address strings
using Internet standard dot notation as specified in inet_addr() are
valid.

http://www.opengroup.org/onlinepubs/007904975/functions/inet_addr.html

Values specified using IPv4 dotted decimal notation take one of the following
forms:

a.b.c.d

When four parts are specified, each shall be interpreted as a byte of data and
assigned, from left to right, to the four bytes of an Internet address.

a.b.c

When a three-part address is specified, the last part shall be interpreted
as a 16-bit quantity and placed in the rightmost two bytes of the network
address. This makes the three-part address format convenient for specifying
Class B network addresses as "128.net.host" .

a.b

When a two-part address is supplied, the last part shall be interpreted as a
24-bit quantity and placed in the rightmost three bytes of the network
address. This makes the two-part address format convenient for specifying
Class A network addresses as "net.host" .

a

When only one part is given, the value shall be stored directly in the
network address without any byte rearrangement.

> Tom has challenged you to prove that this is caused by Pg code and not
> code in your native libraries. Until then, the matter should rest.

Indeed, while I'm not sure what platform the original submitter's using in the
case of glibc it's already a reported bug (by me no less):

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183814

--
greg

Greg Stark wrote:

>"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>
>
>
>>Second, you state that this usage is valid. When you first raised the
>>matter, you were so certain that it was sanctified by standard that you
>>asked me if I would implement it if you could quote an RFC sanctifying it
>>(I said yes) and went off to find one. To your surprise, you couldn't, and
>>now want to say that "valid" is defined for every OS in every context by
>>the man page for one library call on one OS (or possibly several).
>>
>>
>
>Would the POSIX/IEEE/SuS be authoritative enough?
>
>
>

Enough for me, yes, no matter how crazy I think it is ;-)

But as you seem to imply it still looks like Not Our Problem (tm).

cheers

andrew

On Tue, Jan 06, 2004 at 10:52:19PM -0500, Andrew Dunstan wrote:
>
> A few points.
>
> 1. clarification of my IRC comment: A quick examination seems to shaw
> that we use the native getaddrinfo() where it exists, otherwise we use
> our own, which in turn calls inet_ntoa().
> 2. ip6 has a well defined standard for abbreviation, and is quite
> important to have since ip6 addresses would otherwise often be tediously
> long. I haven't found a comparable standard for abbreviating IP4
> addresses.

SUS does define it for inet_ntoa() and inet_addr():

a.b.c.d
When four parts are specified, each shall be interpreted as a
byte of data and assigned, from left to right, to the four
bytes of an Internet address.
a.b.c
When a three-part address is specified, the last part shall be
interpreted as a 16-bit quantity and placed in the rightmost
two bytes of the network address. This makes the three-part
address format convenient for specifying Class B network
addresses as "128.net.host" .
a.b
When a two-part address is supplied, the last part shall be
interpreted as a 24-bit quantity and placed in the rightmost
three bytes of the network address. This makes the two-part
address format convenient for specifying Class A network
addresses as "net.host" .
a
When only one part is given, the value shall be stored directly
in the network address without any byte rearrangement.

All numbers supplied as parts in IPv4 dotted decimal notation may
be decimal, octal, or hexadecimal, as specified in the ISO C
standard (that is, a leading 0x or 0X implies hexadecimal;
otherwise, a leading '0' implies octal; otherwise, the number is
interpreted as decimal).

For inet_pton() it says:

If the af argument of inet_pton() is AF_INET, the src string shall
be in the standard IPv4 dotted-decimal form:
ddd.ddd.ddd.ddd

where "ddd" is a one to three digit decimal number between 0 and
255 (see inet_addr() ). The inet_pton() function does not accept
other formats (such as the octal numbers, hexadecimal numbers, and
fewer than four numbers that inet_addr() accepts).
^^^^^^^^^^^^^^^^^^^^^^^

For getaddrinfo() it says:

If the nodename argument is not null, it can be a descriptive name
or can be an address string. If the specified address family is
AF_INET, [IP6] [Option Start] AF_INET6, [Option End] or AF_UNSPEC,
valid descriptive names include host names. If the specified
address family is AF_INET or AF_UNSPEC, address strings using
Internet standard dot notation as specified in inet_addr() are
valid.

[IP6] [Option Start] If the specified address family is AF_INET6 or
AF_UNSPEC, standard IPv6 text forms described in inet_ntop() are
valid. [Option End]

I'm not sure what this really says, but I can read it to either
use the inet_addr() or inet_ntop() behaviour.

Kurt

Greg Stark wrote:
> a.b.c
>
> When a three-part address is specified, the last part shall be interpreted
> as a 16-bit quantity and placed in the rightmost two bytes of the network
> address. This makes the three-part address format convenient for specifying
> Class B network addresses as "128.net.host" .

I can understand the a.b case, but the a.b.c case is just weird. What
logic is there that it is a.0.b.c? Nothing I can think of except
convention. I agree with Vixie that this syntax is strange and
shouldn't be encouraged.

> > Tom has challenged you to prove that this is caused by Pg code and not
> > code in your native libraries. Until then, the matter should rest.
>
> Indeed, while I'm not sure what platform the original submitter's using in the
> case of glibc it's already a reported bug (by me no less):
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183814

BSD/OS 4.3.1 doesn't like 127.1:

$ ping 127.1
ping: 127.1: hostname nor servname provided, or not known
$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.11 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.056 ms

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Wed, Jan 07, 2004 at 12:53:19PM -0500, Bruce Momjian wrote:
> Greg Stark wrote:
> > a.b.c
> >
> > When a three-part address is specified, the last part shall be interpreted
> > as a 16-bit quantity and placed in the rightmost two bytes of the network
> > address. This makes the three-part address format convenient for specifying
> > Class B network addresses as "128.net.host" .
>
> I can understand the a.b case, but the a.b.c case is just weird. What
> logic is there that it is a.0.b.c? Nothing I can think of except
> convention. I agree with Vixie that this syntax is strange and
> shouldn't be encouraged.

It's a.b.0.c.

Note that the "c" can be bigger than 255, so 128.1.512 turns into
128.1.2.0. This can make perfect sense when you still used
classes.

Kurt

Bruce Momjian wrote:

>Greg Stark wrote:
>
>
>> a.b.c
>>
>> When a three-part address is specified, the last part shall be interpreted
>> as a 16-bit quantity and placed in the rightmost two bytes of the network
>> address. This makes the three-part address format convenient for specifying
>> Class B network addresses as "128.net.host" .
>>
>>
>
>I can understand the a.b case, but the a.b.c case is just weird. What
>logic is there that it is a.0.b.c? Nothing I can think of except
>convention. I agree with Vixie that this syntax is strange and
>shouldn't be encouraged.
>
>

The mentioning of Class B network addresses proves that this is a
convention from ancient times, when a couple of network admins where
using up all A and B networks and didn't want to write all those ".0"
indicating their waste of address space...

Its usability nowadays is very limited, and should be avoided for
clarity reasons.

Regards,
Andreas

Kurt Roeckx wrote:

>For getaddrinfo() it says:
>
> If the nodename argument is not null, it can be a descriptive name
> or can be an address string. If the specified address family is
> AF_INET, [IP6] [Option Start] AF_INET6, [Option End] or AF_UNSPEC,
> valid descriptive names include host names. If the specified
> address family is AF_INET or AF_UNSPEC, address strings using
> Internet standard dot notation as specified in inet_addr() are
> valid.
>
> [IP6] [Option Start] If the specified address family is AF_INET6 or
> AF_UNSPEC, standard IPv6 text forms described in inet_ntop() are
> valid. [Option End]
>
>
>I'm not sure what this really says, but I can read it to either
>use the inet_addr() or inet_ntop() behaviour.
>
>
>
>

I read it to mean that abbreviated forms (via inet_addr()) are OK for
AF_INET but not for AF_INET6 (via inet_pton())

Does anyone else read it differently?

cheers

andrew

On Wed, Jan 07, 2004 at 01:58:54PM -0500, Andrew Dunstan wrote:
>
> I read it to mean that abbreviated forms (via inet_addr()) are OK for
> AF_INET but not for AF_INET6 (via inet_pton())
>

But we use AF_UNSPEC/PF_UNSPEC.

Kurt

On Wed, Jan 07, 2004 at 01:58:54PM -0500, Andrew Dunstan wrote:
> Kurt Roeckx wrote:
>
> > [IP6] [Option Start] If the specified address family is AF_INET6 or
> > AF_UNSPEC, standard IPv6 text forms described in inet_ntop() are
> > valid. [Option End]

> I read it to mean that abbreviated forms (via inet_addr()) are OK for
> AF_INET but not for AF_INET6 (via inet_pton())

I guess I missed that that section is only about IPv6. So it
should use inet_addr()'s behaviour.

Kurt

Kurt Roeckx <Q(at)ping(dot)be> writes:

> It's a.b.0.c.
>
> Note that the "c" can be bigger than 255, so 128.1.512 turns into
> 128.1.2.0. This can make perfect sense when you still used
> classes.

Perhaps it'll seem less strange if I restate the rule so there aren't four
different cases:

A dotted quad is 1-4 numbers separated by dots where each number is an 8 bit
number except for the last which includes all the remaining bits in the 32
bit address.

It might seem strange to people used to networks smaller than /24. But if you
have a /16 with thousand hosts and don't need subnets it makes perfect sense
to number them from 1-1000 rather than using base 256.

I use it all the time for my net-10 addresses. They're subnetted into 10.1/16
10.2/16 etc. Sadly, I don't have thousands of hosts though.

--
greg

Kurt Roeckx <Q(at)ping(dot)be> writes:
> I guess I missed that that section is only about IPv6. So it
> should use inet_addr()'s behaviour.

Well, the question is still whether *our* code is doing anything wrong,
or whether the blame rests entirely with the complainant's C library.
AFAICT the issue must be in his C library, because it seemed to work
as he wanted on my platform...

regards, tom lane

Greg Stark wrote:
>
> Kurt Roeckx <Q(at)ping(dot)be> writes:
>
> > It's a.b.0.c.
> >
> > Note that the "c" can be bigger than 255, so 128.1.512 turns into
> > 128.1.2.0. This can make perfect sense when you still used
> > classes.
>
> Perhaps it'll seem less strange if I restate the rule so there aren't four
> different cases:
>
> A dotted quad is 1-4 numbers separated by dots where each number is an 8 bit
> number except for the last which includes all the remaining bits in the 32
> bit address.
>
> It might seem strange to people used to networks smaller than /24. But if you
> have a /16 with thousand hosts and don't need subnets it makes perfect sense
> to number them from 1-1000 rather than using base 256.
>
> I use it all the time for my net-10 addresses. They're subnetted into 10.1/16
> 10.2/16 etc. Sadly, I don't have thousands of hosts though.

Oh, the last number can be >255. That seems useful, I guess.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Kurt Roeckx wrote:

>On Wed, Jan 07, 2004 at 01:58:54PM -0500, Andrew Dunstan wrote:
>
>
>>I read it to mean that abbreviated forms (via inet_addr()) are OK for
>>AF_INET but not for AF_INET6 (via inet_pton())
>>
>>
>>
>
>But we use AF_UNSPEC/PF_UNSPEC.
>
>
>
>

<mode value="language lawyer">

Even so, as I read it an IP6 address must follow the standard forms set
out under inet_pton(), since that is the ONLY provision made for IP6
addresses.

</mode>

cheers

andrew