10 * 172.16 * 192.168 ... why? - Networking

This is a discussion on 10 * 172.16 * 192.168 ... why? - Networking ; hi does have any sense this numbers? 10, may be, it's easy to remember for our decimal-sistem 192 it's the first of the C class... but why *168*? and 172.16? it seems random......

+ Reply to Thread
Results 1 to 14 of 14

Thread: 10 * 172.16 * 192.168 ... why?

  1. 10 * 172.16 * 192.168 ... why?

    hi
    does have any sense this numbers?

    10, may be, it's easy to remember for our decimal-sistem
    192 it's the first of the C class... but why *168*?
    and 172.16?

    it seems random...

  2. Re: 10 * 172.16 * 192.168 ... why?

    antonio writes:

    >hi
    >does have any sense this numbers?


    >10, may be, it's easy to remember for our decimal-sistem
    >192 it's the first of the C class... but why *168*?
    >and 172.16?


    It's random. So what?


    >it seems random...


  3. Re: 10 * 172.16 * 192.168 ... why?

    On Sun, 13 Apr 2008 15:18:46 +0200, antonio wrote:

    > does have any sense this numbers?
    >
    > 10, may be, it's easy to remember for our decimal-sistem 192 it's the
    > first of the C class... but why *168*? and 172.16?


    Because those network blocks had not already been assigned by ICANN when
    they reserved them?

    > it seems random...


    Only to random minds : >

  4. Re: 10 * 172.16 * 192.168 ... why?

    On Sun, 13 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article <4802096d$0$29603$4fafbaef@reader1.news.tin.it>, antonio wrote:

    >does have any sense this numbers?


    It was what was available.

    >10, may be, it's easy to remember for our decimal-sistem


    /8 (formerly called Class A) address ranges are limited. There were
    only 128 in the original scheme, and they threw away two of those
    (0.0.0.0/8 and 127.0.0.0/8) leaving 126. Today, 96 of them have been
    assigned. See http://www.iana.org/assignments/ipv4-address-space. In
    fact, 10.0.0.0/8 was the old DARPA address range and it was retired.
    See RFC1627 for indications of the problems about the re-use of that
    address range.

    >192 it's the first of the C class... but why *168*?
    >and 172.16?
    >
    >it seems random...


    It's what was available. See RFC3330 for further hints. Address space
    is in demand, which is why IPv6 was developed. As of last month, there
    were 2609197794 IPv4 addresses in use - 70.4 percent of the available.
    For perspective, the same figures for last December (3 months earlier),
    were 2564407724 and 69.2 percent. At the end of 1993, about the time of
    RFC1597 (which was replaced by RFC1918), the figures were 1233944064 and
    33.3 percent, so one third of the address space was already in use.

    Old guy

  5. Re: 10 * 172.16 * 192.168 ... why?

    > It's random. So what?

    it's random?
    well! why?


    (or is it a radom reason too?)

  6. Re: 10 * 172.16 * 192.168 ... why?

    > Because those network blocks had not already been assigned by ICANN when
    > they reserved them?


    this is the best (and maybe the only...) hypothesis...

  7. Re: 10 * 172.16 * 192.168 ... why?

    Moe Trin ha scritto:
    > On Sun, 13 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    > article <4802096d$0$29603$4fafbaef@reader1.news.tin.it>, antonio wrote:
    >
    >> does have any sense this numbers?

    >
    > It was what was available.
    >
    >> 10, may be, it's easy to remember for our decimal-sistem

    >
    > /8 (formerly called Class A) address ranges are limited. There were
    > only 128 in the original scheme, and they threw away two of those
    > (0.0.0.0/8 and 127.0.0.0/8) leaving 126. Today, 96 of them have been
    > assigned. See http://www.iana.org/assignments/ipv4-address-space. In
    > fact, 10.0.0.0/8 was the old DARPA address range and it was retired.
    > See RFC1627 for indications of the problems about the re-use of that
    > address range.
    >
    >> 192 it's the first of the C class... but why *168*?
    >> and 172.16?
    >>
    >> it seems random...

    >
    > It's what was available. See RFC3330 for further hints. Address space
    > is in demand, which is why IPv6 was developed. As of last month, there
    > were 2609197794 IPv4 addresses in use - 70.4 percent of the available.
    > For perspective, the same figures for last December (3 months earlier),
    > were 2564407724 and 69.2 percent. At the end of 1993, about the time of
    > RFC1597 (which was replaced by RFC1918), the figures were 1233944064 and
    > 33.3 percent, so one third of the address space was already in use.
    >
    > Old guy



    WOW!
    amazing!


  8. Re: 10 * 172.16 * 192.168 ... why?

    > It's what was available. See RFC3330 for further hints. Address space
    > is in demand...


    ....and maybe the most *sorted* adresses was demanded first...


  9. Re: 10 * 172.16 * 192.168 ... why?

    On Sun, 13 Apr 2008 15:18:46 +0200, antonio wrote:

    > hi
    > does have any sense this numbers?
    >
    > 10, may be, it's easy to remember for our decimal-sistem 192 it's the
    > first of the C class... but why *168*? and 172.16?
    >
    > it seems random...


    By my calculations, 10 * 172.16 * 192.168 = 330836.42880.

  10. Re: 10 * 172.16 * 192.168 ... why?

    On Sun, 13 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article <48025192$0$29596$4fafbaef@reader1.news.tin.it>, antonio wrote:

    >> It's what was available. See RFC3330 for further hints. Address space
    >> is in demand...

    >
    >...and maybe the most *sorted* adresses was demanded first...


    That is more difficult to say. A quick grep of the delegation files from
    the five RIRs looking for IPv4 addresses in the 192.x.x.x range that were
    allocated/assigned before the end of 1993 turns up 12166 lines. These
    allocations/assignments are coming from three RIRs (APNIC, ARIN, and RIPE
    because AFRINIC and LACNIC didn't exist until later), and it appears that
    they were allocating space individually. Each person doing these
    allocations/assignments was following their own procedure within those
    blocks - such that one may have started at the beginning of his block
    and assigned consecutive ranges, while another may have been trying to
    assign blocks based on the region or country. (Recall that originally,
    ARIN was making all allocations/assignments, then RIPENCC took over for
    Europe and Africa, then APNIC took over the Asia/Pacific part of the
    world, eventually followed by LACNIC for Central/South America and
    most recently, AFRINIC for Africa.) This more or less is the same
    "problem" about how do you assign IP addresses on your LAN. Do you
    start at x.y.z.1 and work up? Or have you some numbering scheme, where
    hosts x.y.z.1 through x.y.z.9 are routers and DNS servers, hosts x.y.z.10
    through x.y.z.N are workstations located on the first floor or this building
    or some similar idea?

    Old guy

  11. Re: 10 * 172.16 * 192.168 ... why?

    In article <4802096d$0$29603$4fafbaef@reader1.news.tin.it>,
    antonio wrote:
    > hi
    > does have any sense this numbers?
    >
    > 10, may be, it's easy to remember for our decimal-sistem
    > 192 it's the first of the C class... but why *168*?
    > and 172.16?
    >
    > it seems random...


    They require relatively few components to recognize in hardware:

    10 = 0x0A = 0000 1010
    192.168 = 0xC0 0xB8 = 1100 0000 1010 1000
    172.16 = 0xAC 0x10 = 1010 1100 0001 0000

    But I don't know how significant a factor that was in their selection.

    --
    -eben QebWenE01R@vTerYizUonI.nOetP royalty.mine.nu:81

    Q: What kind of modem did Jimi Hendrix use?
    A: A purple Hayes.

  12. Re: 10 * 172.16 * 192.168 ... why?

    On Mon, 21 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Hactar wrote:

    >antonio wrote:


    >> does have any sense this numbers?
    >>
    >> 10, may be, it's easy to remember for our decimal-sistem
    >> 192 it's the first of the C class... but why *168*?
    >> and 172.16?
    >>
    >> it seems random...

    >
    >They require relatively few components to recognize in hardware:


    Ummm, when was the last time you popped the hood on a computer, and
    had a look at the components on the motherboard? Looking for IP
    addresses out of the billions of items of data that are floating
    around doesn't require dedicated hardware. It's done as a bit
    comparison in the CPU.

    >10 = 0x0A = 0000 1010
    >192.168 = 0xC0 0xB8 = 1100 0000 1010 1000
    >172.16 = 0xAC 0x10 = 1010 1100 0001 0000


    except that the last one is only looking at the top 12 bits because
    the range is 172.16.0.0 - 172.31.255.255 per RFC1918.

    >But I don't know how significant a factor that was in their selection.


    How do you assign IP addresses on your LAN? Do you start at the first
    available, and increment? What happens when there are three people on
    different continents assigning addresses - how do you coordinate that?
    It might be easier if those three individuals (ARIN, RIPE and APNIC -
    the other two, LACNIC and AFRINIC were added later) were given blocks,
    and allowed to assign addresses from within those blocks in a manner
    they see fit to use. See
    http://www.iana.org/assignments/ipv4-address-space

    For some light reading, use your favorite search engine and find copies
    of these RFCs (or try http://www.ietf.org/rfc/rfc0717.txt and so on)

    0717 Assigned Network Numbers. J. Postel. July 1976. (Format: TXT=2322
    bytes) (Status: HISTORIC)

    0796 Address mappings. J. Postel. September 1981. (Format: TXT=11239
    bytes) (Obsoletes IEN 115) (Status: UNKNOWN)

    1174 IAB recommended policy on distributing internet identifier
    assignment and IAB recommended policy change to internet "connected"
    status. V.G. Cerf. August 1990. (Format: TXT=21321 bytes) (Status:
    INFORMATIONAL)

    1366 Guidelines for Management of IP Address Space. E. Gerich. October
    1992. (Format: TXT=17793 bytes) (Obsoleted by RFC1466) (Status:
    INFORMATIONAL)

    1466 Guidelines for Management of IP Address Space. E. Gerich. May
    1993. (Format: TXT=22262 bytes) (Obsoletes RFC1366) (Obsoleted by
    RFC2050) (Status: INFORMATIONAL)

    2050 Internet Registry IP Allocation Guidelines. K. Hubbard, M.
    Kosters, D. Conrad, D. Karrenberg, J. Postel. November 1996. (Format:
    TXT=28975 bytes) (Obsoletes RFC1466) (Also BCP0012) (Status: BEST
    CURRENT PRACTICE)

    RFC1366 and RFC1466 have been replaced by RFC2050, but may be useful to
    see how things were developed. Or you could start with RFC0717 when
    there were _four_ IP networks (3.x.x.x, 7.x.x.x, 10.x.x.x, and 11.x.x.x)
    and that was the entire game.

    Old guy

  13. Re: 10 * 172.16 * 192.168 ... why?

    In article ,
    Moe Trin wrote:
    > On Mon, 21 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    > article , Hactar wrote:
    >
    > >antonio wrote:

    >
    > >> does have any sense this numbers?
    > >>
    > >> 10, may be, it's easy to remember for our decimal-sistem
    > >> 192 it's the first of the C class... but why *168*?
    > >> and 172.16?
    > >>
    > >> it seems random...

    > >
    > >They require relatively few components to recognize in hardware:

    >
    > Ummm, when was the last time you popped the hood on a computer, and
    > had a look at the components on the motherboard? Looking for IP
    > addresses out of the billions of items of data that are floating
    > around doesn't require dedicated hardware. It's done as a bit
    > comparison in the CPU.


    _Now_ it is. How were routers constructed when IPv4 was designed?

    --
    -eben QebWenE01R@vTerYizUonI.nOetP royalty.mine.nu:81

    Q: What kind of modem did Jimi Hendrix use?
    A: A purple Hayes.

  14. Re: 10 * 172.16 * 192.168 ... why?

    On Tue, 22 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Hactar wrote:

    >Moe Trin wrote:


    >>Hactar wrote:


    [RFC1918 addresses]

    >>>They require relatively few components to recognize in hardware:

    >>
    >> Ummm, when was the last time you popped the hood on a computer, and
    >> had a look at the components on the motherboard? Looking for IP
    >> addresses out of the billions of items of data that are floating
    >> around doesn't require dedicated hardware. It's done as a bit
    >> comparison in the CPU.

    >
    >_Now_ it is. How were routers constructed when IPv4 was designed?


    That would be back in 1980, and the few routers in existence at the
    time were based on mini-computers - try a PDP-11 as an example.

    Simple reason. Assume a router with three network interfaces. Which
    interface are you going to send the packets destined for network
    host 10.10.10.10 to? Is it going to be the same one as 10.20.30.40?
    Obviously each installation is going to have there own choice of
    addresses, located on the interface of their choice. Are you going
    to have a hardware comparator for each network range? How are you
    going to configure them - DIP switches? (It's not easy to decode
    the locations, but have a look at RFC0846, and see where the _hosts_
    with IPs 10.1.0.x were located in early 1983. You might recognize MIT
    and USC as being at opposite sides of the continent.)

    Not that many people were building their own routers, any more than
    people were building their own network cards. Consequently, those
    routers had to be programmable to cater for the different IP ranges
    in use. If you stop and think of the hardware required (those
    packets could be 1526 octets long which includes the preamble of 8
    bytes, Ethernet header of 14 bytes [and trailer of 4 bytes]) and
    the destination IP address is going to be 4 bytes starting 16 or
    24 bytes past that 14 byte header depending on the version of
    Ethernet encapsulation (RFC0894 verses RFC1042, verses several
    proprietary versions), implementing this in hardware is going to
    be "interesting" - that's sure a bunch of 74LS373s never mind the
    circuitry that is going to clock each one. And don't forget that
    your router is decrementing the TTL (13th byte in the IP header)
    and you have to recompute the header checksum (15th and 16th
    byte in the IP header), and while you're at it, you need to look at
    the IP options (if any) starting at the 21st byte, to see if there
    isn't something like routing commands or a 'record-route' option
    present (meaning you've more more work to do with the packet
    before shipping it to the next hop).

    The last problem is that IP wasn't the only network protocol that
    was running on those wires - even back in 1980. And worse, a few
    of those protocols were routable.

    Old guy

+ Reply to Thread