[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: strange ifconfig output..



Rick Jones wrote:
> 
> I would like to add and ask in the same sentence.
> 
> The HOW-TO's (NET3 and ETH) say that including a netmask is unnecissary
> since the system will put the correct netmask inplace for you.
> 
> Jens, you seem to be somewhat the guru in this area.  What is the scoop on
> that?  Is it one of those things that should be but you're better off
> putting it in yourself to be sure?  Or is it only certain situations?
> 

When IP was created, they allocated the IP address space so that 
there would be X number of class A addresses (nm. 255.0.0.0),
X number of class B addresses (255.255.0.0), and X class C
addresses (255.255.255.0) and they used the first couple high-order
bits to determine whether or now the address was class A, B, or C.
Here's an excerpt from Internet Standard 5, which defines IP:

    Address Formats:

      High Order Bits   Format                           Class
      ---------------   -------------------------------  -----
            0            7 bits of net, 24 bits of host    a
            10          14 bits of net, 16 bits of host    b
            110         21 bits of net,  8 bits of host    c
            111         escape to extended addressing mode

      A value of zero in the network field means this network.  This is
      only used in certain ICMP messages.  The extended addressing mode
      is undefined.  Both of these features are reserved for future use.

So under the original regime you *could* tell the netmask from the
address, and software was written to take advantage of this. Then,
however, came the explosion of the internet. So many people came
on the net that routing tables on the backbone got real huge. This
was because you used to be able to get your own class C from the
Internic and they would add to their routing tables the route to get
to you whatever ISP you might be using. Things don't work this way
anymore. This was compounded by the fact that it turned out there
weren't enough class B address--really B is too big and C is too
small. Then along came CIDR, or classless inter-domain routing.  
This meant that addresses would be allocated by the "transit routing
domains". Which is to say: you can only get an IP address which is
within the range your ISP owns, so if their chunk is 206.126.0.0/
255.255.0.0 then any IP they give to someone else will have to
be 206.126.X.X. This halted the growth of the routing tables on the
backbone, enabling them to continue functioning. This also meant
that the address-space would have to be carved up hierarchically and
thus that it was impracticle to enforce the "class" of an IP network.
That's why you can no longer reliably get the netmask from the 
address--because the software was guessing the netmask by looking
at the high-order bits of the address and infering a "class".

As for the "default" route, the software just recognized that 
0.0.0.0 (same as the word "default") isn't a valid network anyway
and just by convention means the default route. Actually, you could
probably use any network, as long as you gave a netmask of 0.0.0.0
and it would work for a "default" route.

-- 
Jens B. Jorgensen
jjorgens@bdsinc.com


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: