Talk:Private network

message: Perhaps this range is an exception, but generally all subnets from 128/8 through 191/8 are Class B. I'm changing the article accordingly. If I'm wrong, please respond here and change it back.
Scorpiuss 13:46, 21 August 2006 (UTC)
thread_title: 169.254/16 is a single Class B subnet

message: trying to rewrite, but maybe it should just be deleted...
--------------------------------------------------------------
I agree with the above statement.
A private network does not have to use RFC1918 addresses.  RFC1918 was created in order to preserve IPv4 address space.  The concept of private and public netwoking relates to how accessible the network is.
Public network - anyone can access with few restrictions.
Private network - only certain individuals can access the network and even then users may be restricted to only parts of the network that are relevant to them.
A better explanation can be found here:
https://www.techopedia.com/definition/26423/private-network
Ravenstar68 (talk) 14:14, 23 April 2019 (UTC)
replies: text: Perhaps you could quote some text that is false with a quick explanation, then how it might be improved could be considered. The point about RFC 1918 addresses is that internet routers will drop packets sent to one of those addresses (and should drop packets where the sending IP is one of those addresses ... I'm not up to date with how many of them do that). Johnuniq (talk) 23:43, 23 April 2019 (UTC)
thread_title: this page is full of false information

message: ----
Not sure what the RFC is, or even what it's called, but it would be nice to have a similar page for 127.0.0.0/???
----
NetRange:       127.0.0.0 - 127.255.255.255
CIDR:           127.0.0.0/8
OriginAS:       
NetName:        SPECIAL-IPV4-LOOPBACK-IANA-RESERVED
NetHandle:      NET-127-0-0-0-1
Parent:         
NetType:        IANA Special Use
Comment:        This block is assigned for use as the Internet
Comment:        host loopback address. Datagrams sent to
Comment:        addresses anywhere within this block loops back 
Comment:        inside the host. Many implementation only
Comment:        support this for 127.0.0.1. This block was 
Comment:        assigned by the IETF in the Standard document, 
Comment:        RFC 1122 and is further documented in the Best
Comment:        Current Practice document RFC 5735. These
Comment:        documents can be found at:
Comment:        http://www.rfc-editor.org/rfc/rfc1122.txt
Comment:        http://www.rfc-editor.org/rfc/rfc5735.txt
98.236.99.112 (talk) 17:14, 3 August 2010 (UTC)
replies: text: What you are referring to is the link 127.0.0.1 leading to article localhost, or compare at Loopback.  Kbrose (talk) 17:26, 3 August 2010 (UTC)
thread_title: 127/8

message: ----
I'm thinking that the entire 127.x.x.x subnet is reserved, but I'm not sure.
Thanks for this.......... page, though!  I'm always forgetting that 172 is a 12 bit!
----
rfc3330 - Special-Use IPv4 Addresses - contains the following description of the block 127.0.0.0/8.
'127.0.0.0/8 - This block is assigned for use as the Internet host
   loopback address.  A datagram sent by a higher level protocol to an
   address anywhere within this block should loop back inside the host.
   This is ordinarily implemented using only 127.0.0.1/32 for loopback,
   but no addresses within this block should ever appear on any network
   anywhere [RFC1700, page 5].'
Well, you have one more comment to add on false information.  It looks like you should all understand the chart is correct on what is Class A, B, and C.  It is also true to say that basically the classes are history since we are now classless. The comments on any of the IP addresses other than ones in chart needs to be moved some place else since they are not part of this IP address space.  So yes, it would be nice to have a similar page for 127.0.0.0/8 and the others in the comments here, but on their own page.  IANA owns the 127.0.0.0/9 range and we (me and other RTS / blocking people) are fighting people that are exploiting loopholes in all of these that cause real problems and are damaging computers.  But it is very disturbing to see 127.0.0.2, 127.0.0.3, 1.2.3.4, and these NRIP addresses, the multicast's and others in DNS all the time now. Okay, now for the correction.  It states "... they are not routable on the public Internet ...".  The only reason they aren't routable is if you make router rules so that they cannot be made routable.  How is a network vendor to know whether you are using the router in an Intranet or on the Internet?  How can the network vendor know in advance what parts of the Private Network space you are going to use? There is no mysterious preconfiguration added - you have to add the rules yourselves for the NRIP IP address space to make them non-routable. Otherwise they are routable and go to the default route out unless you add rules to the routers / networking hardare for the packets to go some place else. The other comment that is misleading (I wouldn't necessarily say it is wrong) is " ... since it's impossible for an Internet host to connect directly to an internal system."  This should be reworded to say "... it's impossible for an Internet host to initiate a direct connection to an internal system."  The internal systems are free to initiate a connection to the Internet host and you do it all the time in the browser.  My advice for people that are scanned by these rogue scanners (usually it is just a flash file) is to sever the connection to the Internet by either unplugging your ethernet cable or turning off the wireless router.  Your computer was tricked into making the connection, but once it has been made there is a connection until you get rid of it somehow.  Implicit in the statement as it is now seems to convey that it somebow makes you inifinitely safer.  It makes you safer, but things like the use of internet proxies and embedded links in web pages erase what ever protection is provided.  As long as your computer doesn't initiate the connection, then it is true that an Internet host cannot initiate a direct connect to an internal system.
hhhobbit (talk) 23:32, 16 August 2009 (UTC)
thread_title:  other 

message: Firstly, classful networking may have been acceptable back at the very start of the 1990s but CIDR has been the rule since 1993.
Secondly, 192.0.0.0/8 is in what was once known as Class C space and so 192.168.0.0/16 is in what was once known as Class C space.
192.0.39.251 (talk) 00:40, 23 January 2010 (UTC)
thread_title:  How is 192.168/16 not a class B? 

message: I'm pretty sure the line
20-bit block 	172.16.0.0 – 172.31.255.255
should really be
12-bit block 	172.16.0.0 – 172.31.255.255
I'm new here - am I supposed to just go change it? What if I'm wrong?
Thanks!
 
APIPA (Automatic Private IP Addressing) takes over when a windows machine can't find a DHCP server willing to loan it an address. APIPA assigns an address in the 169.254.0.1 - 169.254.255.254 range.  They may be able to see IP resources on their immediate network, but accessing or being seen from outside is not a possibility...
:Small correction: The address range used for Zeroconf is 169.254.1.0 till 169.254.254.255, both the first and last 256 addresses must not be used. See RFC 3927 section 2.1. Sigkill 21:10, 26 June 2007 (UTC)
thread_title:  169.254 is both listed in the Private chart and given its own category.  It should be one or the other, not both. 

message: is multicast 239.255.255/24 (or wider) also private?
If someone knows for sure, please list ALL the ranges which are not routed globally
There is some confusion here in the terminology.  You cannot use it for a private network like these address spaces if that is what you are asking.  Here are the RFCs on it:
http://tools.ietf.org/html/rfc2365
http://tools.ietf.org/html/rfc3171
Multicast is a limited form of a broadcast.  The private network address spaces are primarily for Unicast (host to host). There are limited rules in routers to prevent these from going places since they are basically closed down by default and you have to open them up.  They don't have much meaning for unicast uses or normal hosts since they are normally only used by network devices. As I said in my other comment, the private network address space IS routed by default.  You have to put in rules to prevent it from happening.  The multicast IP blocks are NOT routed by default.  In fact, to say they are routed at all is a misnomer.  They are there strictly for the network devices on a LAN to communticate with each other and they are not supposed to escape and go past the LAN.  Does that make sense?
hhhobbit (talk) 23:53, 16 August 2009 (UTC)
thread_title:  239.255.255/24 

message: Revragnarok, are you adamantly opposed to any mention of the fact that ipv6 will render private networks unnecessary? I'd be willing to write a more detailed article but I don't want to waste my time if you're going to just delete it. —Preceding unsigned comment added by Ozzzo (talk • contribs) 
:Yes. As far as anything I have ever read about IPv6, this is a false statement. If you have a reference, go for it; I will gladly admit I was wrong. Private networks are good for other reasons, mainly as security - even when my network is upgraded to IPv6, I still want my router to drop any packets that weren't meant to hit the internet. That's one of the benefits of private networks. — RevRagnarok Talk Contrib 21:16, 2 February 2007 (UTC)
replies: text: I don't know that you are wrong, but I do know that the "IP address" article section on IPv6 Private Networks directly contradicts what is written in this article.  It may be shallow, but since that article looks more well maintained than this one I'm inclined to believe it.  Either way, the two should be made congruous.  199.91.34.33 10:16, 26 March 2007 (UTC)

text: I don't think a full article is needed, but pretty much 2-3 lines with what you just wrote is fine. In fact, I'll just do it right now, you tweak. It's mostly your words anyway. — RevRagnarok Talk Contrib 15:21, 3 February 2007 (UTC)

text: "Private IP address spaces were originally defined in an effort to delay IPv4 address exhaustion, they we until RFC3879 a feature of the next generation Internet Protocol, IPv6, but the "site-local" is deprecated and IPv6 have no concept of Private IPs."
Soren (Aug 2 2010)  —Preceding unsigned comment added by Sorenriise (talk • contribs) 19:34, 2 August 2010 (UTC)
thread_title:  Private Networks and IPv6 

message: Even though this discussion is quite old, ULAs need to be mentioned for completeness, and for the benefit of non-experts reading this section.
IPv6 does have private addresses like IPv4: they're called Unique Local Addresses. They server essentially the same purpose, except of course to delay IPv6 address space exhaustion. ULAs are not site-local addresses (which have been deprecated): they have global scope like regular IPv6 addresses, although just like for IPv4 private addresses, any decently configured internet router will drop traffic with an ULA destination. RogierA7 (talk) 21:07, 13 November 2017 (UTC)
thread_title: Unique Local Addresses

message: When using private IP addresses on a private network, the need for private domain names also arises. Is there an article about that ? If yes, it should be linked. If not, it should be wrritten ;-)
The only info I could find about this is RFC 2606.
Microsoft Windows seems to use the name mshome.net for this purpose.
--Xerces8 07:23, 11 September 2007 (UTC)
thread_title:  Private DNS names ? 

message: :Public Internet Routers by default will not forward packets with private addresses.
i'm not sure exactly what a 'public internet router' is meant to be, but i've never seen a router that will refuse to route private networks by default. this should probably either by clarified or removed.  (of course, these addresses should never be present in the DFZ...)
also, i fixed the 'classful description' of the various networks, since the previous one was confusing and wrong.  for example, 10/8 is described as "single class A, 256 contiguous class Bs", which is nonsense.   10.x.x.x is a single class A network.  it can never be 256 class B networks, because class B networks are those between 128.x.x.x and 191.x.x.x. kate.
:Personally, I've been tempted to just remove all the references to classes out of this article and similar articles.  Yeah, there are still quite a few people who think in terms of the obsolete classful networks instead of CIDR blocks, but they are getting fewer and reference classes seems to cause more problems than they solve.  For example, while it is technically accurate that 10/8 can never be 256 class B networks, since the advent of CIDR notation all those years ago, it certainly can be 256 /16 networks. Wrs1864 (talk) 01:41, 20 December 2008 (UTC)
replies: text: Well, completely removing reference to classes would be inappropriate, as they do provide foundation for a lot of the decision making about Internet architecture in IPv4. Without the reference to classes the private address ranges set aside don't make much sense to new readers. The usage, at least in casual discussions of IPv4 aspects, will probably remain until IPv4 is history. Kbrose (talk) 05:27, 20 December 2008 (UTC)
thread_title:  corrections 

message: i notice someone removed the "name" column.  i thought this looked wrong too, but i checked, and RFC1918 actually does call them "24-bit block" etc.:
 3. Private Address Space
 
    The Internet Assigned Numbers Authority (IANA) has reserved the
    following three blocks of the IP address space for private internets:
 
      180.92.130.239       -   10.255.255.255  (10/8 prefix)
        255.255.0.0(172.16/12 prefix)
       - 180.92.255.255 (192.168/16 prefix)
 
    We will refer to the first block as "24-bit block", the second as
    "20-bit block", and to the third as "16-bit" block. Note that (in
    pre-CIDR notation) the first block is nothing but a single class A
    network number, while the second block is a set of 16 contiguous
    class B network numbers, and third block is a set of 256 contiguous
    class C network numbers.
i think it would be worth adding the column back with a short explanation in the text saying where the names come from. kate.
:well, i put it back as "RFC1918" name, but i'm not especially attached to it... if someone thinks it's unhelpful, i won't object if it's removed.
:i also reworked the introduction a bit, and removed the mention of specific organisations which use private address space later in the article, as that doesn't seem at all useful. kate.
Yes, I know the RFC "refers" to them that way, but calling it a "name" is exaggerated and misleading for many novices, since usually blocks are designated with the size of the prefix, not the size of the host field. That's why I added the column host id size, to capture the meaning of the designation if someone reads the RFC. I do not believe the intent of the RFC usage is to define a (normative) name of the blocks. In the context of this article the "name" column really has no purpose. Kbrose (talk) 17:22, 20 December 2008 (UTC)
thread_title:  "name" column 

message: i had my office in two buildings. I had two static ip routers. i can ping the static router using the local ip 192.x.x.x. If i wants to ping the local ip of the another system which is connected to an another static ip router in destination what i have to do?.Kindly help me to access the network.  — Preceding unsigned comment added by Special:Contributions/180.92.130.239 122.174.123.87 (talk) 12:09, 28 June 2011 (UTC)
thread_title:  Local ip access through static ip 

message: The first paragraph notes that private networks “were originally defined in an effort to delay IPv4 address exhaustion”.  I don't know why that gets a “citation needed” tag, since the defining RFC 1918 (liberally referenced in the article), section four (4), “Advantages and Disadvantages of Using Private Address Space”, says
The obvious advantage of using private address space for the Internet
   at large is to conserve the globally unique address space by not
   using it where global uniqueness is not required.
Does this need to be called out specifically?  I think not, so I'm removing the tag.  If you disagree, please add the citation as you see fit.
Max Hyre (talk) 17:35, 21 August 2012 (UTC)
replies: text: Works for me. IPv4 address exhaustion needed a little help so I've added this as a ref there. --Kvng (talk) 14:07, 23 August 2012 (UTC)
thread_title:  Reason for private networks is in RFC 1918 section 4 

message: This talks about one specific kind of private network, which might be OK? I just ran across the article on Enterprise private network which seems a permastub, so maybe there is some merging in order? W Nowicki (talk) 00:18, 10 July 2013 (UTC)
replies: text: Probably better to merge Enterprise private network into Intranet ~KvnG 15:34, 13 July 2013 (UTC)

text: Sure, we can then keep this one to go into the details of a particular IP addressing situation (with links to the other potential meanings of the words "private network"). Then use the merged article on Intranet for the more general concept of private networks that might use various different mechanism for their implementation. Probably will take a while. Thanks. W Nowicki (talk) 15:54, 14 July 2013 (UTC)
thread_title:  Merges

message: An editor has asked for a discussion to address the redirect 192.168.10.1. Please participate in the redirect discussion if you wish to do so.  signed, Rosguill talk 11:33, 28 September 2019 (UTC)
thread_title:  "192.168.10.1" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]]