Talk:Private network

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as High-importance).

169.254/16 is a single Class B subnet

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)[reply]

this page is full of false information

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)[reply]

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)[reply]

127/8

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)[reply]

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)[reply]

other

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)[reply]

is 136...* Private ???

is 136.*.*.* Private ???

Nope.

IPv6

I know that IPv6 has link-local and site-local addresses, whatever those are, but I'm not sure if IPv6 has a parallel to these addresses other than IPv4-mapped ones... Any ideas? --Scott P

Might be nice to have article for "Public IP Address"

Might be nice to have article for "Public IP Address" just to clarify the terms "Private IP Address" and "Public IP Address". It can also contrast the diffeerences and link to descriptions of puiblic IP Address assignment and recording...

How is 192.168/16 not a class B?

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)[reply]

because this range is not class B ,class B subnet is 255.0.0.0 and class B rang is 172.16.0.0 —Preceding unsigned comment added by 117.241.65.88 (talk) 06:44, 24 March 2010 (UTC)[reply]

The preceeding unsigned comment is simply wrong.
The default subnet masks are in fact: Class A = 255.0.0.0, Class B = 255.255.0.0, Class C = 255.255.255.0
Free Source - http://www.tcpipguide.com/free/t_IPDefaultSubnetMasksForAddressClassesABandC.htm
Further, 172.16.0.0 through 172.32.255.255 is the 'Class B' Private Range (like 10.x.x.x and 192.168.x.x).
The Class IP ranges are A = 0.0.0.0 to 127.255.255.255, B = 128.0.0.0 to 191.255.255.255, C = 192.0.0.0 to 223.255.255.255 (D is multicast-only - 224.0.0.0 to 239.255.255.255, E is experimental-only 240.0.0.0 to 255.255.255.255).
They're determined by the 4 leftmost bits (not 3 as claimed in the main article) of the first binary octet (1111 1111)... 0xxx xxxx = A, 10xx xxxx = B, 110x xxxx = C, 1110 xxx = D, 1111 xxxx = E). If you can't remember the ranges, plug the first 3 numbers from an IPv4 address into a calculator then switch to binary display. Darr247 (talk) 18:02, 2 December 2012 (UTC)[reply]

169.254 is both listed in the Private chart and given its own category. It should be one or the other, not both.

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)[reply]

239.255.255/24

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)[reply]

Private Networks and IPv6

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)[reply]

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)[reply]

IPV6 does allow IPs to be non-routed for security, but there are no "special" IPs that everyone will use for "private networks." IPV6 will provide enough IPs for everyone to have plenty, so if someone wants a private network, they will just configure their routers to not route some of their public IPs. The details of this are still being worked out, but the process is far enough along to confidently say that there will be no "private network" IPs in IPV6. There was going to be this NAT-like thing called "site local" addresses but it has been removed from the IPV6 spec; see RFC 3879 http://tools.ietf.org/html/rfc3879 How about if I work up a better article with references? Ozzzo 03:46, 3 February 2007 (UTC)[reply]

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[1]. It's mostly your words anyway. — RevRagnarok ^{Talk Contrib} 15:21, 3 February 2007 (UTC)[reply]

This is the problem with IPv6. Nobody really has a true concept of how the addresses will be used. If you want to be more precise, this is like IPv4 was in the past. Hopefully in the future there will be better guidelines along this subject. I feel a new entry in the WIKI would be more appropriate as more information is obtained. 76.2.153.45 (talk) 05:29, 22 January 2009 (UTC) Shawn Brown[reply]

The opening paragraph states "Private IP address spaces were originally defined in an effort to delay IPv4 address exhaustion, but they are also a feature of the next generation Internet Protocol, IPv6." however my reading of this discussion, and my reading of RFC3879 makes me beleive the statement being un-true as site-local networks being the equivalent is no longer part of IPv6 -- if this is correct can we update the opening statement to be something more like

"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)[reply]

Unique Local Addresses

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)[reply]

Private DNS names ?

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)[reply]

corrections

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)[reply]

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)[reply]

256 contiguous class Cs = 1 class B

Doesn't "256 contiguous class Cs" equal 1 class B? ~AQ 01:19, 20 December 2008 (UTC)[reply]

By network host numbers, perhaps, logistically no. Class is determined by the first 3 bits of the address. Kbrose (talk) 05:31, 20 December 2008 (UTC)[reply]

it's common to refer to any /24 network as a "class C" and any /16 network as a "class B", but as Kbrose says, it's wrong. see classful addressing for more. kate.

actually, the 'class' is determined by the first four bits of the IPv4 address.

0xxx xxxx = A, 10xx xxxx = B, 110x xxxx = C, 1110 xxx = D, 1111 xxxx = E

It would be nice if someone fixed that in the main article. Darr247 (talk) 18:29, 2 December 2012 (UTC)[reply]

"name" column

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)[reply]

Local ip access through static ip

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)[reply]

Reason for private networks is in RFC 1918 section 4

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)[reply]

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)[reply]

Merges

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)[reply]

Probably better to merge Enterprise private network into Intranet ~KvnG 15:34, 13 July 2013 (UTC)[reply]

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)[reply]

Explanation of 169.254.1.0 to 169.254.254.255 range

I'm not a network expert, so this is why it confuses me. In the RFC, they are using range from x.y.z.0 to x.y.z.255, but you effectively can't use addresses ending with 0 and 255. So the range of address of end device on any /24 network is from .1 to .254. On the other hand range from 169.254.1.0 to 169.254.254.255 seems confusing to me, because everywhere is written, that the link local address is from range 169.254.0.0/16. I'm not alone who thing that this is an error. It was also on other languages of wikipedia pages (e.g. cs). But it is clearly written in the RFC. Problem is, that you must read whole RFC 6890 and RFC 3927 to find that it is correct. I'm afraid to change anything in this article because of every my change was reverted, so I would like to ask:

Can we add at least the reference to the specific setion of the RFC 3927, so it will be:

"...an address from 169.254.1.0 to 169.254.254.255<ref>RFC 3927 section 2.1</ref> may be assigned pseudorandomly."

J123b567 (talk) 11:20, 9 November 2017 (UTC)[reply]

As you must agree, your earlier change was reverted because it was incorrect.

Wrt your last change, I don't quite agree with Kvng that the information you added is entirely redundant: the existing information was that those addresses are not to be used for some reason. You added that they are reserved, which is new. However, you also repeated that 169.254.0.0/24 and 169.254.255.0/24 must not be allocated. Nevertheless, I personally think that your change was not directly relevant in the context: the section is not about how 169.254.0.0/16 is allocated, but about which address range is available for automatic link-local allocation.

I do agree with you, that the fact that RFC 3927 excludes and reserves 169.254.255.0/24 and 169.254.0.0/24 can be unexpected to readers, and as such, I think it is of subsidiary interest. My proposal is therefore to explicitly say that the first and last /24 ranges are reserved for other uses by RFC3927, in a note (with <ref group="Note">...</ref>) to be added after the text with the exception of the first and the last /24 subnets in the range. You might try doing that right away, or you could choose to wait a few more days first, for a reaction from Kvng.

On the subject of x.y.z.0 and x.y.z.255 vs. 169.254.0.0/24 and 169.254.255.0/24:

(in case it's not sufficiently clear yet)

In any subnet, the first and last address are reserved, the last address being the broadcast address for that subnet. In a /24 subnet, those addresses are .0 and .255. In a /28 subnet, e.g. 1.2.3.192/28, the reserved addresses would be 1.2.3.192 and 1.2.3.207, with the latter being the subnet broadcast address. In a /16 subnet in turn, that means that .0.0 and .255.255 are automatically reserved, with .255.255 being the broadcast address for the subnet. All of this is completely unrelated to the 169.254.0.0/16 range, except that, it being a /16 subnet, 169.254.0.0 and 169.254.255.255 are automatically reserved, with the latter being the broadcast address.

In addition to those two reserved addresses, RFC3927 reserves all other addresses in 169.254.0.0/24 and 169.254.255.0/24 as well. You could consider it a whim of the writers of the RFC. IMO they made a sensible choice to reserve some addresses in that range, e.g. in case the IETF ever wants to define some 'standard' services (i.e. hosts) in such a link-local network, for which it would be very useful if they had a standardized, well-known address in the link-local range.

RogierA7 (talk) 16:25, 9 November 2017 (UTC)[reply]

RogierA7 thanks for pointing out that material added by J123b567 that I reverted was not entirely redundant. If we want to get a mention of "reserved for future use" we can restore that but, for accessibility sake, I think it would be better reserved addresses should be called out as ranges not as something based on CIDR notation. I do think "reserved for future use" is a somewhat tangential topic so support RogierA7's suggestion that it be mentioned in a note. ~Kvng (talk) 14:57, 12 November 2017 (UTC)[reply]

RogierA7 I completely agree, that my first modification was wrong and was caused by my bad knowledge and laziness to read mentioned RFCs. Second edit was longer then needed because of my bad english. So, Kvng, can it be ""...an address from 169.254.1.0 to 169.254.254.255 may be assigned pseudorandomly<ref group="Note">The first and last /24 subnets are reserved for other uses by RFC 3927 in section 2.1.</ref>.""

IMO the term 'subnet' shouldn't be used in this case. Instead I'd use 'range' or 'subrange', as those ranges are not entire subnets. They are just (sub)ranges, belonging to subnet 169.254.0.0/16. (BTW: No need to point out that I didn't consistently do that myself in my previous comment :-)

As the text that immediately precedes the note uses a ′start to end′ notation for the address range, for consistency and readability I'd do the same in the note.

RogierA7 (talk) 20:20, 13 November 2017 (UTC)[reply]

Looks like we're close enough to consensus to give something a try. Please review this edit and make any necessary tweaks. ~Kvng (talk) 15:31, 16 November 2017 (UTC)[reply]

192.0.0.0 - 192.0.0.7

Does the 192.0.0.0/29 range belong here as well? ^[1]

References

^ Alain, Durand,; James, Woodyatt,; Ralph, Droms,; L., Lee, Yiu. "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion". tools.ietf.org. Retrieved 2018-11-11.{{cite web}}: CS1 maint: extra punctuation (link) CS1 maint: multiple names: authors list (link)

"192.168.10.1" listed at Redirects for discussion

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)[reply]

Intro ("lede") is incomprehensible

The intro ("lede") is incomprehensible to this semi-lay reader. I looked up "VPN" and got this article, but I still don't understand what a VPN is. Acwilson9 (talk) 02:32, 5 January 2022 (UTC)[reply]

If you looked up "VPN" and got this article, rather than Virtual private network, whatever tools you used to do the lookup made an error - the article you want for VPNs is that article, rather than this article (the "V" in "VPN" stands for "virtual"). Guy Harris (talk) 10:21, 5 January 2022 (UTC)[reply]

Wikipedia and Google search seem to direct properly. Perhaps this misdirection was from another external search engine.

I do think the lead could use some improvement. It contains some semicircular definitions and doesn't clearly explain why or how private networks are used. ~Kvng (talk) 15:03, 11 January 2022 (UTC)[reply]

[1] Alain, Durand,; James, Woodyatt,; Ralph, Droms,; L., Lee, Yiu. "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion". tools.ietf.org. Retrieved 2018-11-11.{{cite web}}: CS1 maint: extra punctuation (link) CS1 maint: multiple names: authors list (link)

[1]