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