Thread
-
Re: [HACKERS] cidr
Paul A Vixie <vixie@vix.com> — 1998-07-21T06:44:04Z
Replies to three messages here. > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 01:13:34 -0400 (EDT) > > The only problem is that if we assume /32, how do we auto-netmask class > A/B/C addresses? I guess we don't. If they want a netmask, they are > going to have to specify it in cidr format. Right. But read on -- what you're calling a netmask is really a prefix length, and I think there's some confusion as to what it is. > I will be honest. I always found the network/host IP address > distinction to be very unclearly outlined in old/non-cidr address > displays, and this causes major confusion for me when trying to figure > out how things are configured. Me too. > I like INET too. It is up to you. How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) make it work (either by making internal_length=10 or going variable length) or (b) just make this thing IPv4 only and take care of IPv6 separately/later? I've started to wonder if we ought to call the type INET and limit it to V4. (In the C socket bindings, IPv6 addresses are in_addr6 / sockaddr_in6, and the address family is AF_INET6 -- I don't know whether to plan on reflecting this in the postgres types, i.e., use a separate one for IPv6, or not.) > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 01:30:05 -0400 (EDT) > > > ... but why would you want to know the mantissa without the scale? > > I guess I thought someone might want to have ipaddr() and netmask() > functions so they can do: > > x = 192.7.34.21/24 > ipaddr(x) -> 192.7.34.21 > netmask(x) -> 255.255.255.0 This is the downreference from above. It does not work that way. /24 is not a shorthand for specifying a netmask -- in CIDR, it's a "prefix length". That means "192.7.34.21/24" is either (a) a syntax error or (b) equivilent to "192.7.34/24". Btw, it appears from my research that the BIND functions *do* impute a "class" if (a) no "/width" is specified and (b) the classful interpretation would be longer than the classless interpretation. No big deal but it qualifies something I said earlier so I thought I'd mention it. > x = 192.7.0.0/16 > ipaddr(x) -> 192.7.0.0 > netmask(x) -> 255.255.0.0 > > These function are defined on the cidr type, and can be called if > someone wants the old output format. Can we wait and see if someone misses / asks for these before we make them? > ..., the 127.1 ambiguity was very strange. netstat -rn is very hard to > understand using the old format. I was amazed at the number of people who had hardwired "127.1" though :-(. > From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Tue, 21 Jul 1998 01:33:41 -0400 (EDT) > > Doing complex stuff like indexing with contrib stuff is tricky, and one > reason we want to move stuff out of there as it becomes popular. It is > just too hard for someone not experienced with the code to implement. > Add to this the fact that the oid at the time of contrib installation > will change every time you install it, so it is even harder/impossible > to automate. Perhaps we ought to make new type insertion easier since it's so cool?
-
Re: [HACKERS] cidr
Marc G. Fournier <scrappy@hub.org> — 1998-07-21T12:11:47Z
On Mon, 20 Jul 1998, Paul A Vixie wrote: > > I like INET too. It is up to you. > > How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) > make it work (either by making internal_length=10 or going variable length) > or (b) just make this thing IPv4 only and take care of IPv6 separately/later? Not sure about b, but doesn't FreeBSD (at least) already support IPv6? If so, I imagine that Linux does too? How much "later" are we talking about here? I'm sorry, but the IPv4 vs IPv6 issue hasnt' been something I've followed much, so don't know the differences...:(
-
Re: [HACKERS] cidr
Nick Bastin <nbastin@rbbsystems.com> — 1998-07-21T14:35:21Z
Paul A Vixie wrote: > > I like INET too. It is up to you. > > How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) > make it work (either by making internal_length=10 or going variable length) > or (b) just make this thing IPv4 only and take care of IPv6 separately/later? Making it IPv4 only just means we'll have to do it again later, and having IPv6 functionality now would be good for those of us who are currently working with IPv6 networks... Nick Bastin Systems Administrator RBb Systems
-
Re: [HACKERS] cidr
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-07-21T14:40:58Z
> > I like INET too. It is up to you. > > How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) > make it work (either by making internal_length=10 or going variable length) > or (b) just make this thing IPv4 only and take care of IPv6 separately/later? I say stick with IPv4 at this point. We can always change it in future upgrades. dump/reload will handle any changes in the internal format. > > I've started to wonder if we ought to call the type INET and limit it to V4. > (In the C socket bindings, IPv6 addresses are in_addr6 / sockaddr_in6, and > the address family is AF_INET6 -- I don't know whether to plan on reflecting > this in the postgres types, i.e., use a separate one for IPv6, or not.) We can call it INET now, and change it to INET4/INET6 if we decide we want separate types for the two address types. > > > From: Bruce Momjian <maillist@candle.pha.pa.us> > > Date: Tue, 21 Jul 1998 01:30:05 -0400 (EDT) > > > > > ... but why would you want to know the mantissa without the scale? > > > > I guess I thought someone might want to have ipaddr() and netmask() > > functions so they can do: > > > > x = 192.7.34.21/24 > > ipaddr(x) -> 192.7.34.21 > > netmask(x) -> 255.255.255.0 > > This is the downreference from above. It does not work that way. /24 is > not a shorthand for specifying a netmask -- in CIDR, it's a "prefix length". > That means "192.7.34.21/24" is either (a) a syntax error or (b) equivilent > to "192.7.34/24". How do we store the netmask? Is that a separate field? > > Btw, it appears from my research that the BIND functions *do* impute a "class" > if (a) no "/width" is specified and (b) the classful interpretation would be > longer than the classless interpretation. No big deal but it qualifies > something I said earlier so I thought I'd mention it. > > > x = 192.7.0.0/16 > > ipaddr(x) -> 192.7.0.0 > > netmask(x) -> 255.255.0.0 > > > > These function are defined on the cidr type, and can be called if > > someone wants the old output format. > > Can we wait and see if someone misses / asks for these before we make them? Suppose I want to retrieve only 'host' addresses. How do we do that? > > Doing complex stuff like indexing with contrib stuff is tricky, and one > > reason we want to move stuff out of there as it becomes popular. It is > > just too hard for someone not experienced with the code to implement. > > Add to this the fact that the oid at the time of contrib installation > > will change every time you install it, so it is even harder/impossible > > to automate. > > Perhaps we ought to make new type insertion easier since it's so cool? Yep, it is cool. When the code is installed as a standard part of the backend, you have more facilities to install types. There are examples of many other types in the include/catalog/*.h files, so you just pick one and duplicate the proper partsTrying to do that with an SQL statement is really messy, particularly because the standard types DON'T use SQL to install themselves. You also must specify unique OIDs for these new entries. Also, the terminology is not something that many people are familiar with, so a lot of it is having the user understand what they need to do. The manuals do a pretty good job. If you have any specific ideas, or things that got you confused that we should clearify, please let us know. Fortunately, there are only a few types in the /contrib area, and as you have learned. As people find the types useful, we want to move them into the main source. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
-
Re: [HACKERS] cidr
Vince Vielhaber <vev@michvhf.com> — 1998-07-21T14:51:45Z
On Tue, 21 Jul 1998, The Hermit Hacker wrote: > On Mon, 20 Jul 1998, Paul A Vixie wrote: > > > > I like INET too. It is up to you. > > > > How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) > > make it work (either by making internal_length=10 or going variable length) > > or (b) just make this thing IPv4 only and take care of IPv6 separately/later? > > Not sure about b, but doesn't FreeBSD (at least) already support > IPv6? If so, I imagine that Linux does too? How much "later" are we > talking about here? > > I'm sorry, but the IPv4 vs IPv6 issue hasnt' been something I've > followed much, so don't know the differences...:( Why not two types, cidr and cidr6? There's more than one type of int, float, etc... Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> TEAM-OS2 Online Searchable Campground Listings http://www.camping-usa.com "There is no outfit less entitled to lecture me about bloat than the federal government" -- Tony Snow ========================================================================== -
Re: [HACKERS] cidr
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-07-21T15:02:11Z
> Paul A Vixie wrote: > > > I like INET too. It is up to you. > > > > How do folks feel about polymorphism between IPv4 and IPv6? Should we (a) > > make it work (either by making internal_length=10 or going variable length) > > or (b) just make this thing IPv4 only and take care of IPv6 separately/later? > > Making it IPv4 only just means we'll have to do it again later, and having > IPv6 functionality now would be good for those of us who are currently working > with IPv6 networks... Oh. OK. We do have variable-length types. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)