Re: [HACKERS] cidr

> Thus spake Bruce Momjian
> > I think we have to be able to store both old-style and cidr-style
> > addresses for several reasons:
>
> I must be missing something. Can you suggest a classfull network
> designation that doesn't fit into the CIDR system? For example,
> what's the difference between the following networks?
>
> Class "A" network 10
> 10.0.0.0 mask 255.0.0.0
> 10.0.0.0/8
>
> Don't they all refer to exactly the same thing? If you subnet that
> network into 256 equal subnets you might have this instead.
>
> Class "B" network 10.42
> 10.42.0.0 mask 255.255.0.0
> 10.42.0.0/16
>
> Now that first one is an invalid designation in the old classfull system
> so it doesn't matter if you can specify it. Under CIDR, however, that
> subnet is perfectly valid (except that that particular range won't route
> on the Internet) and the designations work. So why not store the old
> classfull networks in the cidr type? They fit just fine.

OK, let me explain what I think Paul was saying. cidr is used for
networks. You can use it for hosts by specifying /32. It is not the
same as a netmask. For example:

host 192.24.45.32

Now, this is a host address. We can say its netmask is 255.255.255.0,
or was can say it is part of network 192.24.45/24, which would allow you
compute the netmask as 255.255.255.0. The problem is that you need the
type to support cidr, hosts, and netmasks.

My idea is to internally store the new type as 8 bytes:

____ ____ ____ ____ ____ ___ ___ ____
cidr addr x . x . x . x ip6 ip6
bits len

That way, if they specify cidr bits, we store it. If they don't we make
the bits field equal -1, and print/sort appropriately. The addr len is
usually 3, but ip6 is also easy to add by making the addr len equal 6.

> > we need to be able to store netmasks too, which aren't cidr
>
> Now this is an issue but it is the same issue as hosts. Netmasks
> can also be designated as /32. However, if all you want to store
> is the netmask, just use int. The range is 0 to 32.
>
> > So a generic INET type is clearer, and will support both address types.
>
> I have no particular problem with calling it INET instead of CIDR if
> that gets the type into the system but let's be clear that either way,
> any host and netmask combination can be stored whether it fits in
> the old class system or not.
>
> Perhaps there is an underlying difference of assumptions about what
> the actual type is. Let me take a stab at defining it (without
> naming it) and see if we're all on the same bus.
>
> I see the underlying data type storing two things, a host address
> (which can hold an IPv4 or IPv6 IP) and a netmask which can be
> stored as a small int, 8 bits is plenty. The input function would
> read IP numbers as follows (I'm making some of this up as I go.)
>
> x.x.x.x/y IP x.x.x.x with masklen y
> x.x.x.x:y.y.y.y IP x.x.x.x with masklen determined by examining
> y.y.y.y raising an exception if it is an invalid
> mask (defined as all ones followed by all zeroes)
> x.x.x.x IP x.x.x.x masklen of 32
>
> The output functions would print in a standard way, possibly allowing
> alternate representations like we do for money. Also, there would
> be functions to extract the host, the network or the netmask.
>
> Is this close to what everyone thinks or are we talking about completely
> different things?

Again, not sure we want to merge address and netmask for hosts in the
same field.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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)