Re: RFC 1918 network range choices

[Ryan Harden]

Interesting you call sections 2,4,5 a security model when section 6 explicitly 
states "Security issues are not addressed in this memo.”

Sections 2, 4, and 5 are motivational and design considerations. Using RFC1918 
space is not and should not be considered a security practice.

/Ryan

Ryan Harden
Research and Advanced Networking Architect
University of Chicago - ASN160
P: 773.834.5441




> On Oct 6, 2017, at 8:51 AM, Joe Klein  wrote:
> 
> Which part?  The allocation of the addresses or the security model (section
> 2, 4 & 5)?
> 
> Note: Very few system, network, or security professionals have even read
> anything besides section 3, the private address allocation.  Could be why
> we have some many compromises --- just saying.
> 
> Joe Klein
> 
> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
> PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8
> 
> On Thu, Oct 5, 2017 at 4:28 PM, Randy Bush  wrote:
> 
 The answer seems to be "no, Jon's not answering his email anymore".
>> 
>> jon was not a big supporter of rfc1918
>> 



signature.asc
Description: Message signed with OpenPGP

Re: RFC 1918 network range choices

[Daniel Karrenberg]

On 05/10/2017 13:28, Randy Bush wrote:
>>> The answer seems to be "no, Jon's not answering his email anymore".
>
> jon was not a big supporter of rfc1918

If I recall correctly not one of the authors was a "big supporter". Some
things are not full of beauty and glory; yet they have to be done.
I recall a number of conversations with Jon about this, at least one of
them face-to-face. I am convinced he fully agreed that it was necessary.

Daniel

Re: RFC 1918 network range choices

[Daniel Karrenberg]

On 05/10/2017 07:40, Jay R. Ashworth wrote:
> Does anyone have a pointer to an *authoritative* source on why
>
> 10/8
> 172.16/12 and
> 192.168/16
>
> were the ranges chosen to enshrine in the RFC? ...

The RFC explains the reason why we chose three ranges from "Class A,B &
C" respectively: CIDR had been specified but had not been widely
implemented. There was a significant amount of equipment out there that
still was "classful".

As far as I recall the choice of the particular ranges were as follows:

10/8: the ARPANET had just been turned off. One of us suggested it and
Jon considered this a good re-use of this "historical" address block. We
also suspected that "net 10" might have been hard coded in some places,
so re-using it for private address space rather than in inter-AS routing
might have the slight advantage of keeping such silliness local.

172.16/12: the lowest unallocated /12 in class B space.

192.168/16: the lowest unallocated /16 in class C block 192/8.

In summary: IANA allocated this space just as it would have for any
other purpose. As the IANA, Jon was very consistent unless there was a
really good reason to be creative.

Daniel (co-author of RFC1918)

Re: RFC 1918 network range choices

[Owen DeLong]

> On Oct 5, 2017, at 5:14 PM, Lyndon Nerenberg  wrote:
> 
> 
>> On Oct 5, 2017, at 4:52 PM, Steve Feldman  wrote:
>> 
>> I have a vague recollection of parts of 192.168.0.0/16 being used as default 
>> addresses on early Sun systems.  If that's actually true, it might explain 
>> that choice.
> 
> 192.9.200.X rings a bell; but those might have been the example addresses 
> they used in the SunOS 3.X documentation.

I recall 192.9.200.X being used both in documentation and in default system 
configurations.

Owen
(Former) Sun Employee #10056

Re: RFC 1918 network range choices

[Joe Klein]

Which part?  The allocation of the addresses or the security model (section
2, 4 & 5)?

Note: Very few system, network, or security professionals have even read
anything besides section 3, the private address allocation.  Could be why
we have some many compromises --- just saying.

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8

On Thu, Oct 5, 2017 at 4:28 PM, Randy Bush  wrote:

> >> The answer seems to be "no, Jon's not answering his email anymore".
>
> jon was not a big supporter of rfc1918
>

Re: RFC 1918 network range choices

[Alain Hebert]

    Well,

    Some HP unixes, and documentation, still uses 192.1.1.x.

    Hey free publicity for BBN.

    I have a client still using 192.1.10/24 just because of it. Been 4 
years and they still won't change it :(


-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 10/05/17 20:14, Lyndon Nerenberg wrote:

On Oct 5, 2017, at 4:52 PM, Steve Feldman  wrote:

I have a vague recollection of parts of 192.168.0.0/16 being used as default 
addresses on early Sun systems.  If that's actually true, it might explain that 
choice.

192.9.200.X rings a bell; but those might have been the example addresses they 
used in the SunOS 3.X documentation.

Re: RFC 1918 network range choices

[Michael Thomas]

On 10/05/2017 05:14 PM, Lyndon Nerenberg wrote:

On Oct 5, 2017, at 4:52 PM, Steve Feldman  wrote:

I have a vague recollection of parts of 192.168.0.0/16 being used as default 
addresses on early Sun systems.  If that's actually true, it might explain that 
choice.

192.9.200.X rings a bell; but those might have been the example addresses they 
used in the SunOS 3.X documentation


That's what i recall too. For some reason i thought it was hp, but that 
could easily be wrong.


Mike

Re: RFC 1918 network range choices

[Lyndon Nerenberg]

> On Oct 5, 2017, at 4:52 PM, Steve Feldman  wrote:
> 
> I have a vague recollection of parts of 192.168.0.0/16 being used as default 
> addresses on early Sun systems.  If that's actually true, it might explain 
> that choice.

192.9.200.X rings a bell; but those might have been the example addresses they 
used in the SunOS 3.X documentation.

Re: RFC 1918 network range choices

[Steve Feldman]

> On Oct 5, 2017, at 4:14 PM, William Herrin  wrote:
> 
> On Thu, Oct 5, 2017 at 1:32 PM, Jerry Cloe  wrote:
> 
>> Several years ago I remember seeing a mathematical justification for it,
>> and I remember thinking at the time it made a lot of sense, but now I can't
>> find it.
>> 
> 
> Hi Jerry,
> 
> If there's special ASIC-friendly math here, beyond what was later
> generalized with CIDR, it's not obvious.
> 
> 10.0: 1010  
> 
> 172.16:  1010 1100 0001 
> 
> 172.31:  1010 1100 0001 
> 
> 192.168: 1100  1010 1000
> 
> AFAIK, it was simply one range each from classes A, B and C.

As mentioned in one of the links posted earlier, 10.0.0.0/8 was the original 
ARPANET class A assignment.  (See RFC 970, which brings back a lot of 
memories.)  Once the ARPANET was shut down in 1990 that block was no longer 
used, so it became available for reuse in RFC1918.

I have a vague recollection of parts of 192.168.0.0/16 being used as default 
addresses on early Sun systems.  If that's actually true, it might explain that 
choice.
Steve

Re: RFC 1918 network range choices

[William Herrin]

On Thu, Oct 5, 2017 at 1:32 PM, Jerry Cloe  wrote:

> Several years ago I remember seeing a mathematical justification for it,
> and I remember thinking at the time it made a lot of sense, but now I can't
> find it.
>

Hi Jerry,

If there's special ASIC-friendly math here, beyond what was later
generalized with CIDR, it's not obvious.

10.0: 1010  

172.16:  1010 1100 0001 

172.31:  1010 1100 0001 

192.168: 1100  1010 1000

AFAIK, it was simply one range each from classes A, B and C.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: RFC 1918 network range choices

[Joe Provo]

On Thu, Oct 05, 2017 at 03:04:42PM -0400, valdis.kletni...@vt.edu wrote:
> On Thu, 05 Oct 2017 13:39:04 -0400, Jay Ashworth said:
> 
> > I have seen a number of versions of that in reading things people sent me 
> > and
> > things I found myself, and all of them seem to depend on ASICs that didn't
> > exist at the time the ranges were chosen, and probably also CIDR which also
> > didn't exist. They sound good, but I'm not buying em. :-)
> 
> Can't speak t the ASICs, but CIDR existed, even if your vendor was behind the
> times and still calling stuff class A/B/C. (Such nonsense persisted well into
> this century). Check the dates...
[snip]

To be fair, the actual formal allocation was 1994 with rfc1597. 
1918 was the reconciliation of 1597 and 1627 (ISTR the division 
was also why we saw 1796 and 1814).

The practice had been used for a while before the codification 
but I don't have a good citation. IAB minutes of 1992 speak of 
the practice and the tut-tutting of not wanting people to do 
it, but not citing specific numbers and math.

Cheers!

Joe

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 

Re: RFC 1918 network range choices

[Randy Bush]

>> The answer seems to be "no, Jon's not answering his email anymore".

jon was not a big supporter of rfc1918

Re: RFC 1918 network range choices

[Brian Kantor]

On Thu, Oct 05, 2017 at 03:04:42PM -0400, valdis.kletni...@vt.edu wrote:
> Can't speak t the ASICs, but CIDR existed, even if your vendor was behind the
> times and still calling stuff class A/B/C. (Such nonsense persisted well into
> this century). Check the dates...

The concept of using a number-of-bits to describe
what is now called CIDR existed as early as 1987:

http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8706.mm.www/0011.html

- Brian

Re: RFC 1918 network range choices

[valdis . kletnieks]

On Thu, 05 Oct 2017 13:39:04 -0400, Jay Ashworth said:

> I have seen a number of versions of that in reading things people sent me and
> things I found myself, and all of them seem to depend on ASICs that didn't
> exist at the time the ranges were chosen, and probably also CIDR which also
> didn't exist. They sound good, but I'm not buying em. :-)

Can't speak t the ASICs, but CIDR existed, even if your vendor was behind the
times and still calling stuff class A/B/C. (Such nonsense persisted well into
this century). Check the dates...

1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz,
 D. Karrenberg, G. J. de Groot, E. Lear. February 1996. (Format:
 TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Updated by RFC6761)
 (Also BCP0005) (Status: BEST CURRENT PRACTICE) (DOI:
 10.17487/RFC1918)

1517 Applicability Statement for the Implementation of Classless
 Inter-Domain Routing (CIDR). Internet Engineering Steering Group, R.
 Hinden. September 1993. (Format: TXT=7357 bytes) (Status: HISTORIC)
 (DOI: 10.17487/RFC1517)

1518 An Architecture for IP Address Allocation with CIDR. Y. Rekhter, T.
 Li. September 1993. (Format: TXT=72609 bytes) (Status: HISTORIC)
 (DOI: 10.17487/RFC1518)

1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and
 Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan.
 September 1993. (Format: TXT=59998 bytes) (Obsoletes RFC1338)
 (Obsoleted by RFC4632) (Status: PROPOSED STANDARD) (DOI:
 10.17487/RFC1519)

1520 Exchanging Routing Information Across Provider Boundaries in the
 CIDR Environment. Y. Rekhter, C. Topolcic. September 1993. (Format:
 TXT=20389 bytes) (Status: HISTORIC) (DOI: 10.17487/RFC1520)




pgp9xPjKpRqvc.pgp
Description: PGP signature

RE: RFC 1918 network range choices

[Jay Ashworth]

I have seen a number of versions of that in reading things people sent me and 
things I found myself, and all of them seem to depend on ASICs that didn't 
exist at the time the ranges were chosen, and probably also CIDR which also 
didn't exist. They sound good, but I'm not buying em. :-)

On October 5, 2017 1:32:19 PM EDT, Jerry Cloe  wrote:
>Several years ago I remember seeing a mathematical justification for
>it, and I remember thinking at the time it made a lot of sense, but now
>I can't find it.
>
> 
>I think the goal was to make it easier for routers to dump private
>ranges based on simple binary math, but not sure that concept ever got
>widely used.
>
> 
>Time to start writing  out all the binary.
>
>
> 
>-Original message-
>From:Jay R. Ashworth 
>Sent:Thu 10-05-2017 09:41 am
>Subject:RFC 1918 network range choices
>To:North American Network Operators‘ Group ; 
>Does anyone have a pointer to an *authoritative* source on why
>
>10/8
>172.16/12 and
>192.168/16 
>
>were the ranges chosen to enshrine in the RFC?  Came up elsewhere, and
>I can't 
>find a good citation either.
>
>To list or I'll summarize.
>
>Cheers,
>-- jra
>
> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

RE: RFC 1918 network range choices

[Jerry Cloe]

Several years ago I remember seeing a mathematical justification for it, and I 
remember thinking at the time it made a lot of sense, but now I can't find it.

 
I think the goal was to make it easier for routers to dump private ranges based 
on simple binary math, but not sure that concept ever got widely used.

 
Time to start writing  out all the binary.


 
-Original message-
From:Jay R. Ashworth 
Sent:Thu 10-05-2017 09:41 am
Subject:RFC 1918 network range choices
To:North American Network Operators‘ Group ; 
Does anyone have a pointer to an *authoritative* source on why

10/8
172.16/12 and
192.168/16 

were the ranges chosen to enshrine in the RFC?  Came up elsewhere, and I can't 
find a good citation either.

To list or I'll summarize.

Cheers,
-- jra

 

Re: RFC 1918 network range choices

[John Kristoff]

On Thu, 5 Oct 2017 15:03:58 +
"Jay R. Ashworth"  wrote:

> The answer seems to be "no, Jon's not answering his email anymore".

You might get a better answer over on the internet-history list.  Lots
of people are still around that could probably shed some light on it.

  

John

Re: RFC 1918 network range choices

[Jay R. Ashworth]

The answer seems to be "no, Jon's not answering his email anymore".

This seems semi-authoritative, though, and probably as close as we're
going to get:

https://superuser.com/questions/784978/why-did-the-ietf-specifically-choose-192-168-16-to-be-a-private-ip-address-class/785641

Thanks, Akshay.

Cheers,
-- jra

- Original Message -
> From: "jra" 
> To: "North American Network Operators' Group" 
> Sent: Thursday, October 5, 2017 10:40:57 AM
> Subject: RFC 1918 network range choices

> Does anyone have a pointer to an *authoritative* source on why
> 
> 10/8
> 172.16/12 and
> 192.168/16
> 
> were the ranges chosen to enshrine in the RFC?  Came up elsewhere, and I can't
> find a good citation either.
> 
> To list or I'll summarize.
> 
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: RFC 1918 network range choices

[Akshay Kumar via NANOG]

https://superuser.com/questions/784978/why-did-the-ietf-specifically-choose-192-168-16-to-be-a-private-ip-address-class/785641

On Thu, Oct 5, 2017 at 10:40 AM, Jay R. Ashworth  wrote:

> Does anyone have a pointer to an *authoritative* source on why
>
> 10/8
> 172.16/12 and
> 192.168/16
>
> were the ranges chosen to enshrine in the RFC?  Came up elsewhere, and I
> can't
> find a good citation either.
>
> To list or I'll summarize.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

RFC 1918 network range choices

[Jay R. Ashworth]

Does anyone have a pointer to an *authoritative* source on why

10/8
172.16/12 and
192.168/16 

were the ranges chosen to enshrine in the RFC?  Came up elsewhere, and I can't 
find a good citation either.

To list or I'll summarize.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274