Re: RFC 1918 network range choices

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 Harde

Re: RFC 1918 network range choices

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 r

Re: RFC 1918 network range choices

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 h

Re: RFC 1918 network range choices

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

Re: RFC 1918 network range choices

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 "inve

Re: RFC 1918 network range choices

    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 In

Re: RFC 1918 network range choices

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

Re: RFC 1918 network range choices

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

Re: RFC 1918 network range choices

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

Re: RFC 1918 network range choices

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 gen

Re: RFC 1918 network range choices

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

Re: RFC 1918 network range choices

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

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

Re: RFC 1918 network range choices

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

RE: RFC 1918 network range choices

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 Octob

RE: RFC 1918 network range choices

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 go

Re: RFC 1918 network range choices

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.

Re: RFC 1918 network range choices

5641 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 *auth

Re: RFC 1918 network range choices

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 t

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