From: Bakul Shah <bakul@iitbombay.org>
To: ron minnich <rminnich@gmail.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] conventions around zero padding in ip4
Date: Sat, 7 May 2022 09:38:07 -0700 [thread overview]
Message-ID: <727FE2A1-2E57-432B-8A3D-3249FA5AF29A@iitbombay.org> (raw)
In-Reply-To: <CAP6exY++wLs+qqAaHL-7bJGfahS6AE1uitxZG1=yP4Se7sZ_rg@mail.gmail.com>
On May 7, 2022, at 9:14 AM, ron minnich <rminnich@gmail.com> wrote:
>
> I first learned in the 80s that 127.1 meant 127.0.0.1. I always
> assumed zero padding was defined in a standard *somewhere*, but am
> finding out maybe not. I talked to the IP OG, and he tells me that
> padding was not in any standard. [side note: it's weird and wonderful
> to still have so many people "present at the creation" of computing as
> we know it still around, and to find they are so willing to answer
> naive questions!]
>
> Padding is a standard in ip6, possibly because the addresses are so
> long. :: is your friend.
>
> IP4 padding came up recently: the ip command interprets 10.2 as
> 10.2.0.0, whereas most things (golang libraries, ping, ...) interpret
> it as 10.0.0.2. The latter interpretation accords with what I learned
> 40y ago.
>
> But, I find myself wondering: where was the first use of the IP4 zero
> padding convention?
From RFC791:
Addresses are fixed length of four octets (32 bits). An address
begins with a network number, followed by local address (called the
"rest" field). There are three formats or classes of internet
addresses: in class a, the high order bit is zero, the next 7 bits
are the network, and the last 24 bits are the local address; in
class b, the high order two bits are one-zero, the next 14 bits are
the network and the last 16 bits are the local address; in class c,
the high order three bits are one-one-zero, the next 21 bits are the
network and the last 8 bits are the local address.
So n.m format == network-number.local-address. The converse question is
who came up with the a.b.c.d format where each of a,b,c,d is in 0..255?
next prev parent reply other threads:[~2022-05-07 16:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-07 16:14 ron minnich
2022-05-07 16:38 ` Bakul Shah [this message]
2022-05-07 16:48 ` Erik E. Fair
2022-05-07 18:49 ` Steffen Nurpmeso
2022-05-07 19:14 ` Warner Losh
2022-05-07 19:50 ` ron minnich
2022-05-07 19:57 ` ron minnich
2022-05-07 23:19 ` Bakul Shah
2022-05-07 23:49 ` Warner Losh
2022-05-08 10:28 ` Ralph Corderoy
2022-05-08 5:21 ` jason-tuhs
2022-05-08 10:22 ` Ralph Corderoy
2022-05-09 14:08 ` Steffen Nurpmeso
2022-05-10 10:49 ` Ralph Corderoy
2022-05-07 19:43 Noel Chiappa
2022-05-08 14:54 ` Michael Kjörling
2022-05-09 16:14 Noel Chiappa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=727FE2A1-2E57-432B-8A3D-3249FA5AF29A@iitbombay.org \
--to=bakul@iitbombay.org \
--cc=rminnich@gmail.com \
--cc=tuhs@minnie.tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).