The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] conventions around zero padding in ip4
@ 2022-05-07 16:14 ron minnich
  2022-05-07 16:38 ` Bakul Shah
                   ` (5 more replies)
  0 siblings, 6 replies; 17+ messages in thread
From: ron minnich @ 2022-05-07 16:14 UTC (permalink / raw)
  To: TUHS main list

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?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 16:14 [TUHS] conventions around zero padding in ip4 ron minnich
@ 2022-05-07 16:38 ` Bakul Shah
  2022-05-07 16:48 ` Erik E. Fair
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 17+ messages in thread
From: Bakul Shah @ 2022-05-07 16:38 UTC (permalink / raw)
  To: ron minnich; +Cc: TUHS main list

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?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 16:14 [TUHS] conventions around zero padding in ip4 ron minnich
  2022-05-07 16:38 ` Bakul Shah
@ 2022-05-07 16:48 ` Erik E. Fair
  2022-05-07 18:49 ` Steffen Nurpmeso
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 17+ messages in thread
From: Erik E. Fair @ 2022-05-07 16:48 UTC (permalink / raw)
  To: ron minnich; +Cc: TUHS main list

See inet_addr(3) - the history section in the NetBSD man pages says 4.2 BSD.

	https://man.netbsd.org/inet_addr.3

Speculation: it would not surprise me to find that the "a.b" form turning into "a.0.0.b" was a convenience for ARPANET - ucb-arpa (DEC VAX-11/780) address was 10.0.0.78 or 0/78 in the old form: host 0 on IMP 78, as seen below in an ARPANET hosts file from November 1982 that I have saved (that's just before the Jan 1, 1983 NCP-to-IP transition that heralded the operational beginning of the Internet). The file is sorted in IMP number order.

	Erik

:  Updated on Mon Nov 15 18:59:52 PST 1982
NET  arpanet       10  arpa    ;  258 known hosts
NET  nonet           0  nonet  ;
anyhost              0/0,nonet  nonet
ucla-ats         0/1,arpanet
ucla-ccn         1/1,arpanet ccn
ucla-security         2/1,arpanet ucla-s ucla-net
ucla-locus         3/1,arpanet
sri-nsc11         0/2,arpanet nsc11 dnsri
sri-kl         1/2,arpanet sri kl
sri-csl         2/2,arpanet sri-vis11 sri-f2 f2 csl
sri-tsc         3/2,arpanet sri-tscb tscb
nosc-cc         0/3,arpanet nuc-cc nosc-elf nosc
nosc-spel         1/3,arpanet nosc-secure1
logicon         2/3,arpanet
nprdc         3/3,arpanet nprdc-unix nprdc-atts
utah-tac         2/4,arpanet
utah-20         3/4,arpanet
bbnf         0/5,arpanet bbn-tenexf
bbng         1/5,arpanet bbn-tenexg
bbna         3/5,arpanet bbn-tenexa
mit-multics         0/6,arpanet multics
mit-dms         1/6,arpanet dms
mit-ai         2/6,arpanet ai
mit-ml         3/6,arpanet ml
rand-relay         1/7,arpanet cs-rand rand-cs
rand-tac         2/7,arpanet
rand-unix         3/7,arpanet rand-ai
nrl         0/8,arpanet
nswc-wo         2/8,arpanet
nrl-tops10         3/8,arpanet
nrl-css         7/8,arpanet nrl-csd
harv-10         0/9,arpanet acl
yale         2/9,arpanet
ll         0/10,arpanet
ll-tcp         1/10,arpanet
ll-xn         2/10,arpanet
ll-11         3/10,arpanet
su-ai         0/11,arpanet sail
su-tac         2/11,arpanet
su-score         3/11,arpanet score
dti-vms         0/12,arpanet
dti         1/12,arpanet
gunter-unix         0/13,arpanet gafs
gunter-adam         1/13,arpanet
gunter-tac         2/13,arpanet gunt
cmu-cs-b         0/14,arpanet cmu-10b cmub
cmu-cs-a         1/14,arpanet cmu-10a cmua
cmu-cs-c         3/14,arpanet cmu-20c cmuc
ames-67         0/16,arpanet ames
ames-tip         2/16,arpanet
ames-11         3/16,arpanet
mitre         0/17,arpanet
mitre-tac         2/17,arpanet
dcn1         3/17,arpanet linkabit
radc-multics         0/18,arpanet radc
radc-xper         1/18,arpanet xper
radc-tac         2/18,arpanet radt
radc-tops20         3/18,arpanet radc-20
rochester         4/18,arpanet roch
radc-unix         5/18,arpanet
nbs-vms         0/19,arpanet nbs-10 nbs
nbs-sdc         1/19,arpanet
nbs-unix         2/19,arpanet
nbs-pl         3/19,arpanet
cctc         0/20,arpanet
dcec-tac         2/20,arpanet
edn-unix         3/20,arpanet
lll-unix         0/21,arpanet lll-comp
lll-mfe         1/21,arpanet mfe
isi-speech11         0/22,arpanet
usc-isi         1/22,arpanet usc-isia isia isi usc-isic isic
usc-eclb         0/23,arpanet eclb
usc-eclc         1/23,arpanet eclc
usc-tac         2/23,arpanet
usc-ecl         3/23,arpanet ecl usc-ecla ecla
nadc         2/24,arpanet
wharton-10         3/24,arpanet wharton
seismo         0/25,arpanet
pentagon-tip         2/26,arpanet
pent-unix         3/26,arpanet
usc-isid         0/27,arpanet isid
isi-png11         1/27,arpanet
isi-vaxa         2/27,arpanet vaxa
arpa-dms         0/28,arpanet
arpa-tac1         1/28,arpanet
arpa-tac2         2/28,arpanet
arpa-png11         3/28,arpanet arpa-xgp11
brl         0/29,arpanet
brl-tac         2/29,arpanet
brl-bmd         3/29,arpanet bmd70
cca-unix         0/31,arpanet cca cca-tenex
cca-vms         1/31,arpanet
cca-tac         2/31,arpanet
mit-devmultics         3/31,arpanet devmultics cisl
parc-maxc         0/32,arpanet parc parc-maxc1 parc-maxc2
kestrel         3/32,arpanet sci-ics sci kes sct
nps         0/33,arpanet
fnoc         1/33,arpanet fnwc
nps-tac         2/33,arpanet
fnoc-secure         3/33,arpanet fnwc-secure
lbl         0/34,arpanet
lbl-unix         1/34,arpanet
nosc-secure2         0/35,arpanet usc-isir1 isir1
nosc-sdl         1/35,arpanet nelc-elf nelc
accat-tac         2/35,arpanet nelc-tip
nosc-secure3         3/35,arpanet
coins-tas         0/36,arpanet
cincpacflt-wm         1/36,arpanet
cincpac-tac         2/36,arpanet
purdue         0/37,arpanet purdue-cs purdue-ncp
csnet-purdue         2/37,arpanet purdue-rvax rvax
bragg-sta1         1/38,arpanet
bragg-tac         2/38,arpanet
src-ccp         0/39,arpanet sdac-ccp
src-unix         1/39,arpanet sdac-unix
src-nep         2/39,arpanet sdac-nep
bbn40-tac         0/40,arpanet
ncc-tac         2/40,arpanet
office-1         0/43,arpanet of1
office-2         1/43,arpanet of2 office off
office-3         2/43,arpanet of3 almsa
office-7         3/43,arpanet of7 cecom
mit-xx         0/44,arpanet xx
ll-asg         1/44,arpanet
mit-tstgw         2/44,arpanet
mit-mc         3/44,arpanet mc
collins-pr         0/46,arpanet
collins-tac         2/46,arpanet
okc-unix         3/46,arpanet
wpafb         0/47,arpanet
wpafb-afwal         1/47,arpanet avsail wpafb-afal
wpafb-tip         2/47,arpanet
afwl         0/48,arpanet
afwl-tip         2/48,arpanet
bbnb         0/49,arpanet bbn-tenexb
bbnc         3/49,arpanet bbn bbn-tenex
darcom-tac         2/50,arpanet
sri-unix         2/51,arpanet
ada-vax         0/52,arpanet isi-vaxb ajpo vaxb
usc-isie         1/52,arpanet isie
usc-isif         2/52,arpanet isif
usc-isib         3/52,arpanet isib
afsc-ad         0/53,arpanet eglin
ncsc         1/53,arpanet ncsl
afsc-dev         2/53,arpanet eglin-dev
martin         3/53,arpanet mmc
cit-20         0/54,arpanet cal-tech
cit-vax         1/54,arpanet cit-11
acc         2/54,arpanet
jpl-vax         3/54,arpanet
anl         0/55,arpanet argonne
anl-mcs         1/55,arpanet
sumex-aim         0/56,arpanet aim
su-dsn         1/56,arpanet
tycho         0/57,arpanet nsa
coins-gateway         1/57,arpanet coins
nyu         0/58,arpanet
bnl         1/58,arpanet brookhaven
rutgers         2/58,arpanet rutgers-20 rutgers-10
etac         0/59,arpanet
centacs-mmp         0/60,arpanet
coradcom-tip         2/60,arpanet
centacs-tf         3/60,arpanet
stla-tac         2/61,arpanet stl-tip
utexas-11         0/62,arpanet
utexas-20         1/62,arpanet utexas
bbn-rsm         0/63,arpanet bbnr
bbn-tac         1/63,arpanet
martin-b         1/64,arpanet mmc-b
robins-tac         2/64,arpanet wralc-tac
robins-unix         3/64,arpanet
afsc-sd         0/65,arpanet afsd
afsc-sd-tac         1/65,arpanet sd-tip
aerospace         2/65,arpanet aero
mitre-bedford         0/66,arpanet mitre-b
afgl         1/66,arpanet
afgl-tac         2/66,arpanet
afsc-hq         0/67,arpanet hqafsc
afsc-hq-tac         1/67,arpanet hqafsc-tac
usgs1-multics         0/68,arpanet reston rest
usgs1-amdahl         2/68,arpanet reston-amdahl ram
usgs1-tac         3/68,arpanet
usgs2-multics         0/69,arpanet denver
usgs2-tac         1/69,arpanet
usafa-gateway         2/69,arpanet usafa
usgs3-multics         0/70,arpanet menlo
usgs3-tac         1/70,arpanet
bbn-clxx         2/71,arpanet clxx
bbn-nu         0/72,arpanet
bbn-unix         1/72,arpanet bbnu
bbnp         2/72,arpanet
sri-nic         0/73,arpanet nic
sri-warf         1/73,arpanet warf tscf
sri-ai         2/73,arpanet aic
sri-iu         3/73,arpanet iuv
wsmr-tip         2/74,arpanet
ypg         0/75,arpanet
yuma-tac         2/75,arpanet
bbn-testip         2/76,arpanet
mit-tac         2/77,arpanet
ucb-arpa         0/78,arpanet
ucb-c70         1/78,arpanet berkeley ucb
ucb-ingres         2/78,arpanet ucb-vax ucb-ingvax
mcclellan         3/78,arpanet sacramento-unix
dec-2136         0/79,arpanet
dec-marlboro         1/79,arpanet dec
hi-multics         0/80,arpanet honey
sac2-tac         1/80,arpanet
sac-tac         2/80,arpanet
nalcon         0/81,arpanet
dtnsrdc         1/81,arpanet
david-tac         2/81,arpanet
nems         3/81,arpanet
bbnt         0/82,arpanet
bbn-vax         1/82,arpanet bbnv
bbn-inoc         2/82,arpanet
bbns         3/82,arpanet
bbn-noc2         6/82,arpanet
nswc-dl         0/84,arpanet
nswc-tac         2/84,arpanet
nwc-387a         0/85,arpanet
nwc-elf         1/85,arpanet
nwc-tac         2/85,arpanet
nwc-387b         3/85,arpanet
sandia         0/87,arpanet snl
nlm-mcs         0/88,arpanet nlm mcs
washington         0/91,arpanet udub udub-ward
washington-tac         2/91,arpanet
uw-vlsi         3/91,arpanet udub-vlsi
nusc-npt         2/92,arpanet
nusc         3/92,arpanet
office-8         0/93,arpanet of8
office-10         1/93,arpanet darcom-ka
office-12         2/93,arpanet
csnet-sh         1/94,arpanet csnetb csnet uwisc wisconsin
s1-gateway         0/95,arpanet
s1-a         1/95,arpanet
s1-c         3/95,arpanet
udel-relay         0/96,arpanet ud-relay csnet-relay darcom-hq udel
udel-tcp         1/96,arpanet
udel-ee         2/96,arpanet
cornell         3/96,arpanet

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 16:14 [TUHS] conventions around zero padding in ip4 ron minnich
  2022-05-07 16:38 ` Bakul Shah
  2022-05-07 16:48 ` Erik E. Fair
@ 2022-05-07 18:49 ` Steffen Nurpmeso
  2022-05-07 19:14 ` Warner Losh
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 17+ messages in thread
From: Steffen Nurpmeso @ 2022-05-07 18:49 UTC (permalink / raw)
  To: ron minnich; +Cc: TUHS main list

ron minnich wrote in
 <CAP6exY++wLs+qqAaHL-7bJGfahS6AE1uitxZG1=yP4Se7sZ_rg@mail.gmail.com>:
 |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.

It was/is called compression there, and it was optional ("may") at
first (in RFC 1884).  RFC 1884 was an overall wonderful RFC,
uppercase or lowercase are possible, leading zeros in a field were
optional ("not necessary") etc.

Unfortunately RFC 5952 loaded too much Sushi and Sake first, and
turned this to a soldiers dream, "Leading zeros MUST be
suppressed", "Shorten as Much as Possible", " "::" MUST NOT be
used to shorten just one 16-bit 0 field", "longest run [.] MUST be
shortened", "MUST [.] lowercase".

Luckily SMTP seems to keep the elder 

 |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?

I did not even know this is possible, but for special software
like postfix SMTP etc., where it de-facto means "substring", so
10.2 is 10.2.0.0/16 (unless i am totally mistakent now).
I could imagine that the introduction of CIDR notation as such
(RFC 1519) played a role?

I have had no idea of networks but modem beeps at all, coming from
a staid pupils' desk with C64 -> DOS -> 4DOS / Windows 3.1 -> 4DOS
/ Windows95B (and then, and then!!  It became real) , and there
you had the GUI boxes which "zero padded" anything, unless i am
mistaken.

Btw ipcalc(1) (of RedHat aka https://gitlab.com/ipcalc) is
incapable to deal with that abbreviation at all.
So it maybe is a generation issue, like most other things.
"'Hope i die before i get old".

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 16:14 [TUHS] conventions around zero padding in ip4 ron minnich
                   ` (2 preceding siblings ...)
  2022-05-07 18:49 ` Steffen Nurpmeso
@ 2022-05-07 19:14 ` Warner Losh
  2022-05-07 19:50   ` ron minnich
  2022-05-07 23:19   ` Bakul Shah
  2022-05-08  5:21 ` jason-tuhs
  2022-05-08 10:22 ` Ralph Corderoy
  5 siblings, 2 replies; 17+ messages in thread
From: Warner Losh @ 2022-05-07 19:14 UTC (permalink / raw)
  To: ron minnich; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

On Sat, May 7, 2022 at 10:23 AM ron minnich <rminnich@gmail.com> wrote:

> 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.
>

10.2 is ambiguous. In a network context, it means, typically, 10.2.0.0/16
(though your mileage may vary).
In a host context, it means 10.0.0.2. It's this confusion that has lead to
many efforts
to outright kill this notation.


> But, I find myself wondering: where was the first use of the IP4 zero
> padding convention?
>

I know that it was around in the late 80s on TOPS-20 TCP/IP at Stanford,
and in 4.2BSD (4.1c?). It may have also been in use at MIT. It's usage
pre-dates my 1984 joining of the internet...

Warner

[-- Attachment #2: Type: text/html, Size: 1413 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  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
  1 sibling, 1 reply; 17+ messages in thread
From: ron minnich @ 2022-05-07 19:50 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list

here's a simple example:
rminnich@a300:~/tamago/t9$ ping 127.1
PING 127.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.056 ms

telnet 127.1 22
Trying 127.0.0.1...
Connected to 127.1.

All plan 9 programs I try parse 127.1 as 127.0.0.1

I first learned to use this convention in a BSD world, later on sunos.

Interesting, the things you think are a standard, and are actually
just a convention!

On Sat, May 7, 2022 at 12:15 PM Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Sat, May 7, 2022 at 10:23 AM ron minnich <rminnich@gmail.com> wrote:
>>
>> 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.
>
>
> 10.2 is ambiguous. In a network context, it means, typically, 10.2.0.0/16 (though your mileage may vary).
> In a host context, it means 10.0.0.2. It's this confusion that has lead to many efforts
> to outright kill this notation.
>
>>
>> But, I find myself wondering: where was the first use of the IP4 zero
>> padding convention?
>
>
> I know that it was around in the late 80s on TOPS-20 TCP/IP at Stanford, and in 4.2BSD (4.1c?). It may have also been in use at MIT. It's usage pre-dates my 1984 joining of the internet...
>
> Warner

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 19:50   ` ron minnich
@ 2022-05-07 19:57     ` ron minnich
  0 siblings, 0 replies; 17+ messages in thread
From: ron minnich @ 2022-05-07 19:57 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list

curiouser and curiouser, at least some Go packages parse it that way:

rminnich@a300:~/go/src/github.com/u-root/u-root/cmds/core/ping$ cpu
-key ~/.ssh/cpu_rsa 192.168.16 date
Sat May  7 12:56:29 PM PDT 2022
rminnich@a300:~/go/src/github.com/u-root/u-root/cmds/core/ping$ cpu
-key ~/.ssh/cpu_rsa 192.168.0.16 date
Sat May  7 12:57:05 PM PDT 2022
rminnich@a300:~/go/src/github.com/u-root/u-root/cmds/core/ping$

[cpu is basically ssh with the plan 9 cpu command baked in, written in Go]

So as a convention, it's been out and about for close to 40 years,
many systems honor it, it seems not many people know of it, and not
everything interprets it the same way. Huh! Well, you learn something
new every day.

I found it a wonderful shorthand when somebody showed it to me, and
it's wired into my fingers at this point. I just assumed everyone else
used it too. I may dig around and try to figure out when Plan 9 picked
it up, that might give me some idea as to provenance.

On Sat, May 7, 2022 at 12:50 PM ron minnich <rminnich@gmail.com> wrote:
>
> here's a simple example:
> rminnich@a300:~/tamago/t9$ ping 127.1
> PING 127.1 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.056 ms
>
> telnet 127.1 22
> Trying 127.0.0.1...
> Connected to 127.1.
>
> All plan 9 programs I try parse 127.1 as 127.0.0.1
>
> I first learned to use this convention in a BSD world, later on sunos.
>
> Interesting, the things you think are a standard, and are actually
> just a convention!
>
> On Sat, May 7, 2022 at 12:15 PM Warner Losh <imp@bsdimp.com> wrote:
> >
> >
> >
> > On Sat, May 7, 2022 at 10:23 AM ron minnich <rminnich@gmail.com> wrote:
> >>
> >> 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.
> >
> >
> > 10.2 is ambiguous. In a network context, it means, typically, 10.2.0.0/16 (though your mileage may vary).
> > In a host context, it means 10.0.0.2. It's this confusion that has lead to many efforts
> > to outright kill this notation.
> >
> >>
> >> But, I find myself wondering: where was the first use of the IP4 zero
> >> padding convention?
> >
> >
> > I know that it was around in the late 80s on TOPS-20 TCP/IP at Stanford, and in 4.2BSD (4.1c?). It may have also been in use at MIT. It's usage pre-dates my 1984 joining of the internet...
> >
> > Warner

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 19:14 ` Warner Losh
  2022-05-07 19:50   ` ron minnich
@ 2022-05-07 23:19   ` Bakul Shah
  2022-05-07 23:49     ` Warner Losh
  2022-05-08 10:28     ` Ralph Corderoy
  1 sibling, 2 replies; 17+ messages in thread
From: Bakul Shah @ 2022-05-07 23:19 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list

On May 7, 2022, at 12:14 PM, Warner Losh <imp@bsdimp.com> wrote:
> 
> 10.2 is ambiguous. In a network context, it means, typically, 10.2.0.0/16 (though your mileage may vary).
> In a host context, it means 10.0.0.2. It's this confusion that has lead to many efforts
> to outright kill this notation.

On FreeBSD:
ping 10.2 tries to ping 10.0.0.2 and
ping 192.168.300 tries to ping 192.168.1.44 (1*2^8+44 == 300)
ping 10.2.300 tries to ping 10.2.1.44
ping 192.1000000 tries to ping 192.15.66.64 (15*2^15+66*2^8+64 == 1000000)
ping 1000000001 tries to ping 59.154.202.1 (59*2^24+154*2^16+202*2^8+1)
ping 300.300 tries to ping 23.217.138.110 (I haven't worked this out! Prob. a bug)
So the last number is treated as the host number on a given net.
This may have some sense in the classful network world but is
very confusing in the CIDR world.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 23:19   ` Bakul Shah
@ 2022-05-07 23:49     ` Warner Losh
  2022-05-08 10:28     ` Ralph Corderoy
  1 sibling, 0 replies; 17+ messages in thread
From: Warner Losh @ 2022-05-07 23:49 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

On Sat, May 7, 2022, 5:19 PM Bakul Shah <bakul@iitbombay.org> wrote:

> On May 7, 2022, at 12:14 PM, Warner Losh <imp@bsdimp.com> wrote:
> >
> > 10.2 is ambiguous. In a network context, it means, typically,
> 10.2.0.0/16 (though your mileage may vary).
> > In a host context, it means 10.0.0.2. It's this confusion that has lead
> to many efforts
> > to outright kill this notation.
>
> On FreeBSD:
> ping 10.2 tries to ping 10.0.0.2 and
> ping 192.168.300 tries to ping 192.168.1.44 (1*2^8+44 == 300)
> ping 10.2.300 tries to ping 10.2.1.44
> ping 192.1000000 tries to ping 192.15.66.64 (15*2^15+66*2^8+64 == 1000000)
> ping 1000000001 tries to ping 59.154.202.1 (59*2^24+154*2^16+202*2^8+1)
> ping 300.300 tries to ping 23.217.138.110 (I haven't worked this out!
> Prob. a bug)
> So the last number is treated as the host number on a given net.
> This may have some sense in the classful network world but is
> very confusing in the CIDR world.
>


We just know the dotted quad world. In the early days of sparse addresses
and crappy name service (or out of date host files) these shortcuts were a
lifesaver.

Warner

>

[-- Attachment #2: Type: text/html, Size: 1898 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 16:14 [TUHS] conventions around zero padding in ip4 ron minnich
                   ` (3 preceding siblings ...)
  2022-05-07 19:14 ` Warner Losh
@ 2022-05-08  5:21 ` jason-tuhs
  2022-05-08 10:22 ` Ralph Corderoy
  5 siblings, 0 replies; 17+ messages in thread
From: jason-tuhs @ 2022-05-08  5:21 UTC (permalink / raw)
  To: ron minnich; +Cc: TUHS main list


> 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.

A friend spent some time digging into this issue not too long ago; you may 
find his write-up interesting:

https://blog.dave.tf/post/ip-addr-parsing/


  -Jason


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 16:14 [TUHS] conventions around zero padding in ip4 ron minnich
                   ` (4 preceding siblings ...)
  2022-05-08  5:21 ` jason-tuhs
@ 2022-05-08 10:22 ` Ralph Corderoy
  2022-05-09 14:08   ` Steffen Nurpmeso
  5 siblings, 1 reply; 17+ messages in thread
From: Ralph Corderoy @ 2022-05-08 10:22 UTC (permalink / raw)
  To: tuhs

Hi Ron,

> 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.

It has been standardised; see inet_addr(3p) where ‘p’ means the POSIX
version of the man page or
https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html

Briefly, the string must be one of

    a.b.c.d
    a.b.cd
    a.bcd
    abcd

where the number of bytes represented is the number of characters.
Each number is as defined by ISO C, e.g. ‘0x...’ means hex, thus
‘ping 017777777776’.

That's all there is to it.  It's simple to explain and I've used it for
years too.  Given POSIX defines it, without deprecation, programming
languages which don't use the C library and programs which must parse
the string themselves should follow POSIX to avoid those annoying
programs which deviate from the long-established norm.

> 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.

Bug the ip(1) folks, pointing to POSIX.  :-)

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 23:19   ` Bakul Shah
  2022-05-07 23:49     ` Warner Losh
@ 2022-05-08 10:28     ` Ralph Corderoy
  1 sibling, 0 replies; 17+ messages in thread
From: Ralph Corderoy @ 2022-05-08 10:28 UTC (permalink / raw)
  To: tuhs

Hi Bakul,

> On FreeBSD:
> ping 10.2 tries to ping 10.0.0.2 and
> ping 192.168.300 tries to ping 192.168.1.44 (1*2^8+44 == 300)
> ping 10.2.300 tries to ping 10.2.1.44
> ping 192.1000000 tries to ping 192.15.66.64 (15*2^15+66*2^8+64 == 1000000)
> ping 1000000001 tries to ping 59.154.202.1 (59*2^24+154*2^16+202*2^8+1)

Ditto here on Linux with GNU libc.

> ping 300.300 tries to ping 23.217.138.110 (I haven't worked this out! Prob. a bug)

It doesn't parse as a numeric address.  Given it's a.bcd, based on the
notation in my other email, the first 300 is ‘a’ but is bigger than one
byte so is invalid. Yes, a bug.

    $ ping 300.300
    ping: 300.300: Name or service not known
    $

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-08 10:22 ` Ralph Corderoy
@ 2022-05-09 14:08   ` Steffen Nurpmeso
  2022-05-10 10:49     ` Ralph Corderoy
  0 siblings, 1 reply; 17+ messages in thread
From: Steffen Nurpmeso @ 2022-05-09 14:08 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: tuhs

Ralph Corderoy wrote in
 <20220508102208.50A2822158@orac.inputplus.co.uk>:
 |> 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.
 |
 |It has been standardised; see inet_addr(3p) where ‘p’ means the POSIX
 |version of the man page or
 |https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
 |
 |Briefly, the string must be one of
 |
 |    a.b.c.d
 |    a.b.cd
 |    a.bcd
 |    abcd
 |
 |where the number of bytes represented is the number of characters.
 |Each number is as defined by ISO C, e.g. ‘0x...’ means hex, thus
 |‘ping 017777777776’.
 |
 |That's all there is to it.  It's simple to explain and I've used it for
 |years too.  Given POSIX defines it, without deprecation, programming
 |languages which don't use the C library and programs which must parse
 |the string themselves should follow POSIX to avoid those annoying
 |programs which deviate from the long-established norm.
 |
 |> 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.
 |
 |Bug the ip(1) folks, pointing to POSIX.  :-)

"However", RFC 2553 says

  RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999

     The address conversion functions -- inet_ntoa() and inet_addr() --
     convert IPv4 addresses between binary and printable form.  These
     functions are quite specific to 32-bit IPv4 addresses.  We have
     designed two analogous functions that convert both IPv4 and IPv6
     addresses, and carry an address type parameter so that they can be
     extended to other protocol families as well.

And for this POSIX says

  If the af argument of inet_pton( ) is AF_INET, the src string
  shall be in the standard IPv4 dotted-decimal form:
  ddd.ddd.ddd.ddd where "ddd" is a one to three digit decimal
  number between 0 and 255 (see inet_addr( )). The inet_pton()
  function does not accept other formats [.]

I am too lazy / busy to check whether inet_pton() with AF_INET
gets the short version right.
(I personally had IPAdress:: .. pub boolean fromString(const char
*_straddr, ui4 _straddrlen=M1::ui4):

    * Tries to parse the address as stored in \a _straddr.
    * If \a _straddr was successfully parsed a true boolean is returned.
    * Otherwise \THIS has not been modified.
    *
    * This function can parse all usual address representations,
    * in particular all of those which can be produced with toString().
    * It can even parse "127.  0.  0.  1", "127.000.000.001",
    * but \e cannot parse "127.  0.0000.  1" (room for four digits).
    * And ditto for IPv6.
    *
    * \remarks If result is IPv6, flowInfo() and scopeId() are set to 0.
    * \note
    * ARPA strings are not understood!
    * I.e., strings produced by toArpaString() cannot be re-parsed to
    * a plain address with this one!
    *
    * \note
    * ::0.0.0.0 and ::FFFF:0.0.0.0 will fail.
    * ::0.0.0.1 and ::FFFF:0.0.0.1 will also fail.

and now find the need to do

    /* xxx Client had this already, simply binary pass it, too? */
    c_af = (su_cs_find_c(pgp->pg_ca, ':') != NIL) ? AF_INET6 : AF_INET;
    if(inet_pton(c_af, pgp->pg_ca, (c_af == AF_INET ? S(void*,&c_sip.v4)
             : S(void*,&c_sip.v6))) != 1){
       su_log_write(su_LOG_CRIT, _("Cannot re-parse an already "
          "prepared IP address?: "), pgp->pg_ca);
       goto jleave0;
    }
    c_ip = (c_af == AF_INET) ? R(u32*,&c_sip.v4.s_addr)
          : R(u32*,c_sip.v6.s6_addr);

quite lengthy and complicated.  Of course inet_pton() can be made
"extended to other protocol families", and maybe they are already
even, but i find this distressing as either you need to provide
some kind of _(un)?register() or even hardwire, maybe with a tree
of #ifdef, those other families.  And better watch out for
EAFNOSUPPORT at runtime.  Of course i came late and wanted /
needed something specific so i am fine out.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-09 14:08   ` Steffen Nurpmeso
@ 2022-05-10 10:49     ` Ralph Corderoy
  0 siblings, 0 replies; 17+ messages in thread
From: Ralph Corderoy @ 2022-05-10 10:49 UTC (permalink / raw)
  To: tuhs

Hi Steffen,

> > It has been standardised; see inet_addr(3p) where ‘p’ means the
> > POSIX version of the man page or
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
> > 
> > Briefly, the string must be one of
> > 
> >     a.b.c.d
> >     a.b.cd
> >     a.bcd
> >     abcd
...
> "However", RFC 2553 says
>
>   RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
>
>      The address conversion functions -- inet_ntoa() and inet_addr() --
>      convert IPv4 addresses between binary and printable form.  These
>      functions are quite specific to 32-bit IPv4 addresses.  We have
>      designed two analogous functions that convert both IPv4 and IPv6
>      addresses

So that RFC added inet_pton(3) and inet_ntop(3).

> And for this POSIX says
>
>   If the af argument of inet_pton( ) is AF_INET, the src string
>   shall be in the standard IPv4 dotted-decimal form:
>   ddd.ddd.ddd.ddd where "ddd" is a one to three digit decimal
>   number between 0 and 255 (see inet_addr( )). The inet_pton()
>   function does not accept other formats [.]

True.  The non-POSIX inet_pton(3) here points out it only accepts IPv4
in decimal 3.1.4.1 form and pushes the programmer to getaddrinfo(3)
instead.

    NOTES

    Unlike inet_aton(3) and inet_addr(3), inet_pton() supports IPv6
    addresses.  On the other hand, inet_pton() accepts only IPv4 addresses
    in dotted-decimal notation, whereas inet_aton(3) and inet_addr(3)
    allow the more general numbers-and-dots notation (hexadecimal and
    octal number formats, and formats that don't require all four bytes
    to be explicitly written).  For an interface that handles both
    IPv6 addresses, and IPv4 addresses in numbers-and-dots notation,
    see getaddrinfo(3).

And POSIX's getaddrinfo(3p) punts to inet_addr(3p) for describing what
IPv4 formats are accepted, so we've gone full circle.

    If the specified address family is AF_INET or AF_UNSPEC, address
    strings using Internet standard dot notation as specified in
    inet_addr() are valid.

It looks to me that the RFC introduced a limited format which then had
to be standardised but the older interface is still being spread by
newer functions like getaddrinfo().

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
@ 2022-05-09 16:14 Noel Chiappa
  0 siblings, 0 replies; 17+ messages in thread
From: Noel Chiappa @ 2022-05-09 16:14 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]

    > There were other ways of specifying a IP address numerically, initially;

I decided to set the Way-Back Machine to as close to 0 as I could get, and
looked to see what the Terminal Interface Unit:

  https://gunkies.org/wiki/Terminal_Interface_Unit

whose source I recently recovered, did. This is an interesting
implementation, because it was definitely one of the first 4 TCP
implementations done (before any UNIX ones); likely one of the first two,
along with the TENEX one. (Actually, they both likely originally predate the
split of TCP and IP into separate protocols, although this version post-dates
that split.)

The manual:

  http://ana-3.lcs.mit.edu/~jnc/tech/mos/docs/tiunv1.lpt

(in "B. TELNET Commands") and the source:

  http://ana-3.lcs.mit.edu/~jnc/tech/mos/tiu/telnet-1.mac

disagree on how the user gave addresses in numeric form in an 'open' command;
both agree that it was '@O <rest>,<net>,<socket>', but the manual claims
that 'rest' "may be specified symbolically, or numerically in decimal", but the
code shows that '#xxx' could also be used, to give it in hex. (Although if hex
were used, the number could be a max of 16 bits; decimal alloweded up to 42 bits.)


    > From: Michael Kjörling

    > Looks like [A/B/C addresses] happened in 1978 or thereabouts?
    > https://www.rfc-editor.org/ien/ien46.txt

No; it post-dates the IEN era; "Assigned Numbers" of September 1981 (RFC-790)
is the first mention I could find of it. (That Dave Clark IEN is talking
about what later became 'IP subnets' - which ironically long pre-date A/B/C -
see IEN-82, February 1979.)

The Internet Protocol spec of September 1981 (RFC-791) also has A/B/C; my
memory is that this change was _not_ discussed in the INWG, Postel just
sprung it on us in these two RFCs.

I suspect what happened is that Jon (as keeper of the network numbers)
realized that there was an increasing demand for network numbers, and 256
would only last so long, so he sprung into action and did the A/B/C thing.
(If this topic is of more interest, it should get moved to the
'internet-history' list, it's off-topic here.)

Interestingly, RFC-790 says: "One notation for internet host addresses
commonly used divides the 32-bit address into four 8-bit fields and specifies
the value of each field as a decimal number with the fields separated by
periods." Note the "one notation", implying that it wasn't any kind of
standard at that point.

	Noel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
  2022-05-07 19:43 Noel Chiappa
@ 2022-05-08 14:54 ` Michael Kjörling
  0 siblings, 0 replies; 17+ messages in thread
From: Michael Kjörling @ 2022-05-08 14:54 UTC (permalink / raw)
  To: tuhs

On 7 May 2022 15:43 -0400, from jnc@mercury.lcs.mit.edu (Noel Chiappa):
> PS: The A/B/C addresses are actually a moderately late stage of IP
> addresses. At the very start, they were all '8 bits network numbers, and 24
> bits of 'rest''.

Looks like that happened in 1978 or thereabouts?

https://www.rfc-editor.org/ien/ien46.txt

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] conventions around zero padding in ip4
@ 2022-05-07 19:43 Noel Chiappa
  2022-05-08 14:54 ` Michael Kjörling
  0 siblings, 1 reply; 17+ messages in thread
From: Noel Chiappa @ 2022-05-07 19:43 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Ron Minnich

    > 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.

I don't think it was very standardized; I've been working on the Internet
since 1977, and this is the very first I ever recall hearing of it! :-)


    > From: Bakul Shah 

    > 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?

Again, that was not standardized at an early stage, but was, as best I can now
recall, just adopted by general usage (i.e. without any formal discussion).

There were other ways of specifying a IP address numerically, initially;
e.g. for a while at MIT we were using w,x,y,z (with w-z in octal - note the
','s, which were a syntatic tag for the octal form), which was easier to
interpret when looking at a packet dump on a PDP-11. Here:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/arc/tftp.c.1

is the source for a user command (from July, 1979) which allowed host
addresses to be given in that form.

I'm not sure who came up with the dotted decimal form; I suspect you'd need to
find some really old email archives, and look in that. There was, early on, a
list called "tcp-ip", used by people who were getting their machines ready for
the NCP->TCP/IP conversion. However, I suspect the 'dotted quad' predates
that; there was an even earlier mailing list, used in early experimental work,
by the group working on internet technology, whose name escapes me (it was
something like "internet working group").

It's possible that an IEN:

  https://www.rfc-editor.org/ien/ien-index.html

might mention the 'dotted quad' syntax; TCP and IP meeting minutes
would be a good place to start.

	Noel

PS: The A/B/C addresses are actually a moderately late stage of IP
addresses. At the very start, they were all '8 bits network numbers, and 24
bits of 'rest''.

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2022-05-10 10:52 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-07 16:14 [TUHS] conventions around zero padding in ip4 ron minnich
2022-05-07 16:38 ` Bakul Shah
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

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).