Thread
-
Re: [HACKERS] Re: inet/cidr/bind
Paul Vixie <paul@vix.com> — 1998-10-20T06:21:37Z
> > no. the last three inputs are not valid where a host address is expected. > > Can you amplify? Is it correct as far as cidr goes? If so, I have no > problem making it an error for the inet type. My thinking was based > on the earlier concept of having one type and accepting networks in it. > If we have the separate cidr type then I guess inet should always require > 4 octets (until ipv6 anyway) and cidr should be used for networks. Networks do not have to have all four octets specified, only enough octets to cover the prefix length that's given. Networks should have default netmasks based on classful assumptions. Networks never have any bits beyond their prefix length, which is why the question of "nonzero host part" does not even really arise. There is no "host part" in a network. And in my concept of them, they are variably sized. > How about something like 192.63.0.0/16? Should that be an error under the > inet type since it is the network? I am thinking not since technically > 192.63.0.0 is a valid host under 192.63/16 although it is generally > avoided since there is still software that assumes that it is the > network or even the broadcast. The all-zeros host address is available and value, but as you say, deprecated. > > so shall i test the inet_cidr_ functions and punt them on in? > > Ok, before I have a reality shift, the inet_cidr_ functions are simply > the original inet_net_ functions renamed, right? No. The inet_net_ functions describe CIDRized networks. The inet_cidr_ functions, which I've written but not yet committed to BIND 8.next, are new. I am absolutely loathe to submit them at this point, since the act of bridging host addresses and their prefix lengths makes no sense to me. Here's a cisco showing a CIDR block (mine, as it turns out): palo-alto>sho ip rou 204.152.184.0 Routing entry for 204.152.184.0/21, supernet Known via "bgp 1280", distance 20, metric 0 Tag 3557, type external Last update from 198.32.176.3 2w0d ago Routing Descriptor Blocks: * 198.32.176.3, from 198.32.176.3, 2w0d ago Route metric is 0, traffic share count is 1 AS Hops 1 Here's a BSD/OS box showing a bunch of CIDR blocks (inside my network): # netstat -rn Destination Gateway Flags Refs Use Interface default 204.152.184.4 UG 0 103154609 de1 127 127.0.0.1 UR 0 0 lo0 127.0.0.1 127.0.0.1 UH 0 59294 lo0 192.5.5.1 204.152.184.19 UGH 0 1160628 de0 192.5.5.2 204.152.184.19 UGH 0 507879 de0 192.5.5.88/29 204.152.184.19 UG 0 4 de0 192.5.5.96/27 204.152.184.19 UG 0 35150 de0 192.5.5.124/30 204.152.184.19 UG 0 12361 de0 192.5.5.241 204.152.184.4 UGH 0 55164 de1 198.32.176 204.152.184.1 UG 0 15250 de1 198.32.176.6 204.152.184.1 UGHc 0 76 de1 204.152.184/28 link#2 UC 0 0 de1 204.152.184.1 0:c0:95:e0:1e:1c UHLc 4 493 de1 204.152.184.3 0:c0:95:e0:2e:8c UHLc 0 1 lo0 204.152.184.4 0:c0:95:e0:1e:24 UHLc 4 7125 de1 204.152.184.5 0:c0:95:e0:26:80 UHLc 1 0 de1 204.152.184.16/29 link#1 UC 0 0 de0 ^C The things which are "hosts" have four octets, are of fixed length, and do not have netmasks. The things which are "networks" have some other number of octets, are variably sized, and do have netmasks (actually, prefix lengths). At the risk of reopening a discussion which ought to have been closed a long while back, I suggest that polymorphism is bad and that an INET type which is built out of BIND's inet_net_ functions is perfectly capable of holding a host address (since /32 is the default if all four octets are specified), and that we run absolutely zero risk if we call the type INET, add indexing linkages for it, and get outta town. There is an argument for a sugartype called IHOST which generates a /32 INET but uses inet_pton() and inet_ntop() for parsing/printing so as to avoid the "/%d" that nobody needs to see and also to ensure that only fully formed host addresses can be input. There is an argument for another, completely separate type, called MACADDR, which is an IEEE 48-bit address (suitable for ethernet or fddi arp tables). There is no argument I know of for a type which combines the host address and the netmask of its interface. I've got applications in mind for each of the above three types -- has anybody got a specific application they want to build which requires a CIDR-like host address which is of fixed size, has the ability to preserve the "unset"-ness of the prefix length from input through storage to output, and also has the ability to preserve a particular prefix length from input through storage to output? I'll use INET in a registry database like IANA's or InterNIC's. I'll use INET, IHOST and MACADDR in a distributed DHCP database. What would anybody use a mixture of INET and IHOST for, that they could not do just as easily with a pair of IHOST's? Forget the number theory for a moment and let's talk about applications which are uniquely enabled by any new type we consider. Once that's done, we can talk about avoiding unfortunate overlaps. I've got the code done for supporting hosts-with-prefixes, but I don't like it and I would not use it in any PgSQL application I can imagine. Help?
-
Re: [HACKERS] Re: inet/cidr/bind
D'Arcy J.M. Cain <darcy@druid.net> — 1998-10-20T13:27:51Z
Thus spake Paul A Vixie > Networks do not have to have all four octets specified, only enough octets > to cover the prefix length that's given. Networks should have default > netmasks based on classful assumptions. Networks never have any bits beyond > their prefix length, which is why the question of "nonzero host part" does > not even really arise. There is no "host part" in a network. And in my > concept of them, they are variably sized. I think we (at least I) are still confused about what the types are. I see two types on the table; a) A type to hold networks only b) A type to hold hosts with optional netmasks Can we agree that these are the two types we are discussing? If so can we agree on which is which? I have been assuming that A was cidr and B was inet but perhaps I have it backwards. > The all-zeros host address is available and value, but as you say, deprecated. But not illegal, right? > No. The inet_net_ functions describe CIDRized networks. The inet_cidr_ > functions, which I've written but not yet committed to BIND 8.next, are > new. I am absolutely loathe to submit them at this point, since the act > of bridging host addresses and their prefix lengths makes no sense to me. OK, so it looks like I had it backwards all along. So we can just put the inet.c function back in exactly as it was then? If we agree on this then we are half way there and at least we have something for 6.4 right now. > At the risk of reopening a discussion which ought to have been closed a long > while back, I suggest that polymorphism is bad and that an INET type which is > built out of BIND's inet_net_ functions is perfectly capable of holding a > host address (since /32 is the default if all four octets are specified), > and that we run absolutely zero risk if we call the type INET, add indexing > linkages for it, and get outta town. > > There is an argument for a sugartype called IHOST which generates a /32 INET > but uses inet_pton() and inet_ntop() for parsing/printing so as to avoid the > "/%d" that nobody needs to see and also to ensure that only fully formed host > addresses can be input. So host only - no additional information carried in the type? > There is an argument for another, completely separate type, called MACADDR, > which is an IEEE 48-bit address (suitable for ethernet or fddi arp tables). Nothing to do with our current discussion, right? You are just mentioning it for completeness and we shall never speak of it again, or at least not till after 6.4? > There is no argument I know of for a type which combines the host address and > the netmask of its interface. I've got applications in mind for each of the > above three types -- has anybody got a specific application they want to build > which requires a CIDR-like host address which is of fixed size, has the > ability to preserve the "unset"-ness of the prefix length from input through > storage to output, and also has the ability to preserve a particular prefix > length from input through storage to output? Radius server for Ascend terminal servers. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner. -
Re: [HACKERS] Re: inet/cidr/bind
Matthew N. Dodd <winter@jurai.net> — 1998-10-20T16:10:08Z
I'm voting that the rest of the peanut gallary sit down and allow PostgreSQL to adopt Vixie's world vision of the INET type. If after the release it is found to be lacking it can be addressed then. Lets give the man some credit; he's got a better idea of what will be useful than anyone else I've seen here. Everyone else seems to be stumbling around attempting to argue a point while trying to figure out what the heck they're arguing about. If you don't understand what Paul is trying to do, then sit down, read a few books and come back when you do. This whole issue is really heading towards a stalemate otherwise. As usual, feel free to ignore me. Paul, thanks for taking the time to educate everyone here. Your patience is appriciated and I only hope that the features you need will pan out in the release. On Mon, 19 Oct 1998, Paul A Vixie wrote: > > > no. the last three inputs are not valid where a host address is expected. > > > > Can you amplify? Is it correct as far as cidr goes? If so, I have no > > problem making it an error for the inet type. My thinking was based > > on the earlier concept of having one type and accepting networks in it. > > If we have the separate cidr type then I guess inet should always require > > 4 octets (until ipv6 anyway) and cidr should be used for networks. > > Networks do not have to have all four octets specified, only enough octets > to cover the prefix length that's given. Networks should have default > netmasks based on classful assumptions. Networks never have any bits beyond > their prefix length, which is why the question of "nonzero host part" does > not even really arise. There is no "host part" in a network. And in my > concept of them, they are variably sized. > > > How about something like 192.63.0.0/16? Should that be an error under the > > inet type since it is the network? I am thinking not since technically > > 192.63.0.0 is a valid host under 192.63/16 although it is generally > > avoided since there is still software that assumes that it is the > > network or even the broadcast. > > The all-zeros host address is available and value, but as you say, deprecated. > > > > so shall i test the inet_cidr_ functions and punt them on in? > > > > Ok, before I have a reality shift, the inet_cidr_ functions are simply > > the original inet_net_ functions renamed, right? > > No. The inet_net_ functions describe CIDRized networks. The inet_cidr_ > functions, which I've written but not yet committed to BIND 8.next, are > new. I am absolutely loathe to submit them at this point, since the act > of bridging host addresses and their prefix lengths makes no sense to me. > > Here's a cisco showing a CIDR block (mine, as it turns out): > > palo-alto>sho ip rou 204.152.184.0 > Routing entry for 204.152.184.0/21, supernet > Known via "bgp 1280", distance 20, metric 0 > Tag 3557, type external > Last update from 198.32.176.3 2w0d ago > Routing Descriptor Blocks: > * 198.32.176.3, from 198.32.176.3, 2w0d ago > Route metric is 0, traffic share count is 1 > AS Hops 1 > > Here's a BSD/OS box showing a bunch of CIDR blocks (inside my network): > > # netstat -rn > Destination Gateway Flags Refs Use Interface > default 204.152.184.4 UG 0 103154609 de1 > 127 127.0.0.1 UR 0 0 lo0 > 127.0.0.1 127.0.0.1 UH 0 59294 lo0 > 192.5.5.1 204.152.184.19 UGH 0 1160628 de0 > 192.5.5.2 204.152.184.19 UGH 0 507879 de0 > 192.5.5.88/29 204.152.184.19 UG 0 4 de0 > 192.5.5.96/27 204.152.184.19 UG 0 35150 de0 > 192.5.5.124/30 204.152.184.19 UG 0 12361 de0 > 192.5.5.241 204.152.184.4 UGH 0 55164 de1 > 198.32.176 204.152.184.1 UG 0 15250 de1 > 198.32.176.6 204.152.184.1 UGHc 0 76 de1 > 204.152.184/28 link#2 UC 0 0 de1 > 204.152.184.1 0:c0:95:e0:1e:1c UHLc 4 493 de1 > 204.152.184.3 0:c0:95:e0:2e:8c UHLc 0 1 lo0 > 204.152.184.4 0:c0:95:e0:1e:24 UHLc 4 7125 de1 > 204.152.184.5 0:c0:95:e0:26:80 UHLc 1 0 de1 > 204.152.184.16/29 link#1 UC 0 0 de0 > ^C > > The things which are "hosts" have four octets, are of fixed length, and do not > have netmasks. The things which are "networks" have some other number of > octets, are variably sized, and do have netmasks (actually, prefix lengths). > > At the risk of reopening a discussion which ought to have been closed a long > while back, I suggest that polymorphism is bad and that an INET type which is > built out of BIND's inet_net_ functions is perfectly capable of holding a > host address (since /32 is the default if all four octets are specified), > and that we run absolutely zero risk if we call the type INET, add indexing > linkages for it, and get outta town. > > There is an argument for a sugartype called IHOST which generates a /32 INET > but uses inet_pton() and inet_ntop() for parsing/printing so as to avoid the > "/%d" that nobody needs to see and also to ensure that only fully formed host > addresses can be input. > > There is an argument for another, completely separate type, called MACADDR, > which is an IEEE 48-bit address (suitable for ethernet or fddi arp tables). > > There is no argument I know of for a type which combines the host address and > the netmask of its interface. I've got applications in mind for each of the > above three types -- has anybody got a specific application they want to build > which requires a CIDR-like host address which is of fixed size, has the > ability to preserve the "unset"-ness of the prefix length from input through > storage to output, and also has the ability to preserve a particular prefix > length from input through storage to output? > > I'll use INET in a registry database like IANA's or InterNIC's. > > I'll use INET, IHOST and MACADDR in a distributed DHCP database. > > What would anybody use a mixture of INET and IHOST for, that they could not > do just as easily with a pair of IHOST's? > > Forget the number theory for a moment and let's talk about applications which > are uniquely enabled by any new type we consider. Once that's done, we can > talk about avoiding unfortunate overlaps. > > I've got the code done for supporting hosts-with-prefixes, but I don't like it > and I would not use it in any PgSQL application I can imagine. Help? > -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? |
-
Re: [HACKERS] Re: inet/cidr/bind
D'Arcy J.M. Cain <darcy@druid.net> — 1998-10-20T17:43:30Z
Thus spake Matthew N. Dodd > I'm voting that the rest of the peanut gallary sit down and allow > PostgreSQL to adopt Vixie's world vision of the INET type. If after the > release it is found to be lacking it can be addressed then. Actually, we already have. The discussion is only over adding a second type and what, exactly, it should be. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.