Talk:IPv6 address: Difference between revisions

Content deleted Content added

Inline

Latest revision as of 00:53, 18 September 2024

This is the talk page for discussing improvements to the IPv6 address article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: Index, 1: 2 years

Computing: Networking Mid‑importance

	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
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as High-importance).

Internet Mid‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet 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.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet
Mid	This article has been rated as Mid-importance on the project's importance scale.

Is 2002::/16 really deprecated?

The section on reserved addresses says:

2002::/16 — This prefix was used for 6to4 addressing (an address from the IPv4 network 192.88.99.0/24 was also used). The 6to4 addressing scheme is deprecated.

While citing RFC 7526. But the RFC clearly says in section 4:

The basic unicast 6to4 mechanism defined in [RFC3056] and the associated 6to4 IPv6 prefix 2002::/16 are not deprecated. The default address selection rules specified in [RFC6724] are not modified.

AFAIU this RFC only deprecates the anycast version of 6to4 and the associated IPv4 prefix:

This document formally deprecates the anycast 6to4 transition mechanism defined in [RFC3068] and the associated anycast IPv4 address 192.88.99.1. It is no longer considered to be a useful service of last resort.

The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except by a future IETF Standards Action. StayFoolish2021 (talk) 07:46, 20 April 2023 (UTC)[reply]

A Commons file used on this page or its Wikidata item has been nominated for speedy deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for speedy deletion:

Ipv6 address leading zeros.svg

You can see the reason for deletion at the file description page linked above. —Community Tech bot (talk) 09:55, 21 April 2023 (UTC)[reply]

SLAAC Interface identifier composition from MAC address is not accurate

The example about converting 48-bit MAC address into 64-bit interface identifier should be clearer. It appropriately describes addition of FF-FE in the middle, but is missing that the universal/local bit (next to lowest in first byte) should be complemented in the (common) case of Ethernet interface. There is a footnote comment stating this, but in my opinion it could be said more clearly (in a single short sentence) in the actual paragraph. RFC 2464 describes this quite clearly and could be referenced here. Pasisar (talk) 08:45, 4 March 2024 (UTC)[reply]

@@ Line 1: / Line 1: @@
+{{Talk header}}
-{{talkheader|noarchive=yes}}
-{{WikiProject Computing|class=C|importance=mid|network=yes|network-importance=high}}
+{{WikiProject banner shell|class=C|
+{{WikiProject Computing|importance=mid|network=yes|network-importance=high}}
+{{WikiProject Internet |importance=Mid}}
-{{split-to|page=IPv6|diff=|date=9 October 2009}}
+}}
 {{to do}}
+{{split article|to=IPv6 address|from=IPv6|diff=|date=October 2009}}
+{{split article|to=IPv6 address|from=Reserved IP addresses|diff=|date=12 May 2018}}
+{{User:MiszaBot/config|archiveheader = {{talk archive navigation}}|maxarchivesize = 70K|counter = 1|minthreadsleft = 5|minthreadstoarchive = 2|algo = old(730d)|archive = Talk:IPv6 address/Archive %(counter)d}}
+{{User:HBC Archive Indexerbot/OptIn|target=Talk:IPv6 address/Archive index|mask=Talk:IPv6 address/Archive <#>|leading_zeros=0|indexhere=yes}}
+== Is 2002::/16 really deprecated? ==
-== Final Stages ==
-Okay, I think I've finished my editing of the page.  Things that remain to be done:
-* write a short (two or three paragraphs) summary to include in the [[IPv6#Addressing|Addressing]] section of the IPv6 page;
-* write a structure section, about addresses being 128 bits, host numbers and stuff;
-* rewrite the introduction completely, remove anything that went into the Structure section, remove all the silly "my address space is larger than your address space" stuff written by people who don't understand logarithms.--[[User:Jec|Jec]] ([[User talk:Jec|talk]]) 21:51, 2 November 2009 (UTC)
-:Thanks for your input, Jec. Please elaborate on how to change the introduction into a structure section and your comment on 'logarithms'. IPv6 address space <u>is</u> larger (and for good reason) than IPv4 address space and should be at least mentioned in some form or other. Please indicate your view on how to introduce the 'larger address space' without becoming silly.  —— [[User: dandorid|<i><sub><u>D</u></sub><sup><b>a</b></sup><small>n</small><sub><u>d</u></sub><sup><b>o</b></sup><small>r</small><sup> <b>i</b></sup><sub><u>D</u></sub></i>]] ([[User Talk:Dandorid|talk]]) 14:11, 3 November 2009 (UTC)
-::Wrote an introduction on [[IPv6]] about this page and removed several sections that are hereby moved to this page.
-::Added a <nowiki>[[Category:IPv6]]</nowiki> at the bottom of the page.  Probably more catagories are needed there.
+The section on reserved addresses says:
-> Please elaborate on how to change the introduction into a structure section
+''2002::/16 — This prefix was used for 6to4 addressing (an address from the IPv4 network 192.88.99.0/24 was also used). The 6to4 addressing scheme is deprecated.''
-The introduction mixes up stuff that belongs in the introduction with stuff that is about the structure of IPv6 addresses (64-bit prefix and stuff).  This needs to be split.
+While citing RFC 7526. But the RFC clearly says in section 4:
-> Please indicate your view on how to introduce the 'larger address space' without becoming silly.
+''The basic '''unicast''' 6to4 mechanism defined in [[https://datatracker.ietf.org/doc/html/rfc3056 RFC3056]] '''and the associated 6to4 IPv6 prefix 2002::/16 are not deprecated'''. The default address selection rules specified in [[https://datatracker.ietf.org/doc/html/rfc6724 RFC6724]] are not modified.''
-Claims such that IPv6 provides 17 gogozillions addresses per square furlong of the surface of the principality of San Marino are silly.  They tell you absolutely nothing.
+AFAIU this RFC only deprecates the anycast version of 6to4 and the associated IPv4 prefix:
-Try to keep it technical and to the point: with IPv6, the system manager has between 64 and 96 bits of address space to play with. This allows defining a convenient and efficient addressing hierarchy without being constrained by the size of addresses.  (In other words, what is meaningful is the number of bits, not the number of addresses -- i.e. the logarithm of the number of addresses). --[[User:Jec|Jec]] ([[User talk:Jec|talk]]) 00:03, 15 November 2009 (UTC)
+''This document formally deprecates the '''anycast''' 6to4 transition mechanism defined in [[https://datatracker.ietf.org/doc/html/rfc3068 RFC3068]] and the associated anycast IPv4 address 192.88.99.1. It is no longer considered to be a useful service of last resort.''
-:This is a great article!  But no, I don't think those sort of comparisons are silly; they're a illustrative.  Saying it's a 128-bit address space is nice and all, but - ideally - not everyone who reads this page will know what that means.  I'm not saying we should replace this article with a simple english article, but let's throw a bone to the layperson.  Anyway, this article is so technical and thorough, it could use at least one sentence with some spunk! [[User:Psychlohexane|Psychlohexane]] ([[User talk:Psychlohexane|talk]]) 19:51, 1 February 2012 (UTC)
+''The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except by a future IETF Standards Action.'' [[User:StayFoolish2021|StayFoolish2021]] ([[User talk:StayFoolish2021|talk]]) 07:46, 20 April 2023 (UTC)
-:Moved the content around: from intro to IPv6 Address Space and to the Structure section. Also moved last subsection to the Notation section. When I reread it it appeared to be just a way of circumventing a naming clash with UNC paths. A DNS domain was registered by Microsoft, but no actual queries are made, so it is just a different way of writing an IPv6 address.
-:I hope you like it. —— [[User: dandorid|<i><sub><u>D</u></sub><sup><b>a</b></sup><small>n</small><sub><u>d</u></sub><sup><b>o</b></sup><small>r</small><sup> <b>i</b></sup><sub><u>D</u></sub></i>]] ([[User Talk:Dandorid|talk]]) 21:13, 15 November 2009 (UTC)
+== A Commons file used on this page or its Wikidata item has been nominated for speedy deletion ==
-There is something wrong with this:
+The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for speedy deletion:
- Local addresses: ::1/128 — the loopback address is a unicast localhost address (analogous to the RFC.
+* [[commons:File:Ipv6 address leading zeros.svg|Ipv6 address leading zeros.svg]]<!-- COMMONSBOT: speedy | 2023-04-21T09:55:18.196327 | Ipv6 address leading zeros.svg -->
-but I'm not sure what was intended.  [[Special:Contributions/206.171.6.11|206.171.6.11]] ([[User talk:206.171.6.11|talk]]) 16:15, 26 November 2009 (UTC)
+You can see the reason for deletion at the file description page linked above. —[[User:Community Tech bot|Community Tech bot]] ([[User talk:Community Tech bot|talk]]) 09:55, 21 April 2023 (UTC)
+== SLAAC Interface identifier composition from MAC address is not accurate ==
-== Top Templates ==
-Added some templates at the top of this page. —— [[User: dandorid|<i><sub><u>D</u></sub><sup><b>a</b></sup><small>n</small><sub><u>d</u></sub><sup><b>o</b></sup><small>r</small><sup> <b>i</b></sup><sub><u>D</u></sub></i>]] ([[User Talk:Dandorid|talk]]) 18:37, 14 November 2009 (UTC)
+The example about converting 48-bit MAC address into 64-bit interface identifier should be clearer. It appropriately describes addition of FF-FE in the middle, but is missing that the universal/local bit (next to lowest in first byte) should be complemented in the (common) case of Ethernet interface. There is a footnote comment stating this, but in my opinion it could be said more clearly (in a single short sentence) in the actual paragraph. RFC 2464 describes this quite clearly and could be referenced here. [[User:Pasisar|Pasisar]] ([[User talk:Pasisar|talk]]) 08:45, 4 March 2024 (UTC)
-== Address Types: edits reverted ==
-The edits by User:140.124.25.86 and User:12.237.205.131 are hereby reverted, since they are wrong (anycast), have sloppy format (multicast), or incomplete (unicast).  Furthermore, they distract the reader from the subject of the section.
-I like the way of representing an IPv6 address this way though (in a more nuts-and-bolts fashion), but this should be done in the structure section in more general terms. —— [[User: dandorid|<i><sub><u>D</u></sub><sup><b>a</b></sup><small>n</small><sub><u>d</u></sub><sup><b>o</b></sup><small>r</small><sup> <b>i</b></sup><sub><u>D</u></sub></i>]] ([[User Talk:Dandorid|talk]]) 16:31, 26 December 2009 (UTC)
-== Ambiguity in address compression ==
-It isn't clear in the article if a double colon can represent just one group of all zeros or if it must represent at least two. The problem is that RFC 5321 states the latter, whereas RFC 4291 states the former. Could anyone shed light on this, and edit the article accordingly?  <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/94.195.110.161|94.195.110.161]] ([[User talk:94.195.110.161|talk]]) 07:24, 17 August 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
-:There is no ambiguity. Both versions of the RFC are equally clear on this. But this article is wrong and poorly written. Thank you for your observation.[[User:Kbrose|Kbrose]] ([[User talk:Kbrose|talk]]) 17:46, 17 August 2010 (UTC)
-:: Ambigue or not, RFC 5952 clarifies this and says that at least two groups of zeroes can be eligible for double colon representation, not one.  This is changed in the article now. —— [[User: dandorid|<i><sub><u>D</u></sub><sup><b>a</b></sup><small>n</small><sub><u>d</u></sub><sup><b>o</b></sup><small>r</small><sup> <b>i</b></sup><sub><u>D</u></sub></i>]] ([[User Talk:Dandorid|talk]]) 21:04, 19 February 2011 (UTC)
-::: There is no ambiguity. RFC5952 tells how programs should write IPv6 addresses. RFC4291 tells how programs should read IPv6 addresses. More specifically the RFC 4291 tells: 'The use of "::" indicates one or more groups of 16 bits of zeros'. So, an IPv6 address using :: to substitute ONLY one group is VALID.  <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/89.96.141.102|89.96.141.102]] ([[User talk:89.96.141.102|talk]]) 15:43, 29 March 2011 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
-== feature of IPv6 Protocols ==
-we want the features IPv6 protocols  <small><span class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Suresh514|Suresh514]] ([[User talk:Suresh514|talk]] • [[Special:Contributions/Suresh514|contribs]]) 17:52, 3 October 2010 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
-:Can you be clear? This article doesn't cover the protocol-see [[IPv6]] for that.[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 00:03, 13 January 2011 (UTC)
-== Special addresses ==
-Although it is mentioned in the article, the address <tt>ff02::1</tt> does not appear in special addresses. This address is very important because it represents the IPv4 broadcast (it is the multicast group ''all-nodes''). Should not be mentioned as an speciall address ?  <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Mtorrecilla|Mtorrecilla]] ([[User talk:Mtorrecilla|talk]] • [[Special:Contributions/Mtorrecilla|contribs]]) 14:47, 10 February 2011 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
-:Sources?[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 01:28, 12 February 2011 (UTC)
-Sources ???. The IPv6 address article: ''IPv6 does not implement broadcast addressing. Broadcast's traditional role is subsumed by multicast addressing to the all-nodes link-local multicast group ff02::1''
-But we can see it in
-[http://tools.ietf.org/html/rfc4861 RFC 4861]
-Reading [http://tools.ietf.org/html/rfc4291 RFC 4291] I think that we should change FROM
--------------------------------------------------------------------
-; Solicited-Node multicast addresses
-{{Main|Solicited-node multicast address}}
-* <tt>ff02::1:ff00:0/104</tt> — The least significant 24 bits of the group ID are filled with the least significant 24 bits of the interface's unicast or anycast address. These addresses allow link-layer address resolution via [[Neighbor Discovery Protocol]] (NDP) on the link without disturbing all nodes on the local network. A host is required to join a Solicited-Node multicast group for each of its configured unicast or anycast addresses.
--------------------------------------------------------------------
-TO
--------------------------------------------------------------------
-; Reserved multicast addresses
-The multicast addresses <tt>ff00::0/12</tt> are reserved'''<nowiki><ref name=rfc4291></nowiki>''' and should never be assigned to any multicast group.
-* <tt>ff01::1</tt> and <tt>ff02::1</tt> — All Nodes Addresses. These addresses identify the group of all IPv6 nodes, within scope 1 (interface-local) or 2 (link-local).
-* <tt>ff01::2</tt>, <tt>ff02::2</tt>, and <tt>ff05::2</tt> — All Routers Addresses. They identify the group of all IPv6 routers, within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
-* <tt>ff02::1:ff00:0/104</tt> — [[Solicited-node multicast address]]. The least significant 24 bits of the group ID are filled with the least significant 24 bits of the interface's unicast or anycast address. These addresses allow link-layer address resolution via [[Neighbor Discovery Protocol]] (NDP) on the link without disturbing all nodes on the local network. A host is required to join a Solicited-Node multicast group for each of its configured unicast or anycast addresses.
--------------------------------------------------------------------
-[[User:Mtorrecilla|Mtorrecilla]] ([[User talk:Mtorrecilla|talk]]) 13:24, 14 February 2011 (UTC)
-:Acceptable, with the exception that "shall" should be "should" as per [[WP:MOS]].[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 03:43, 15 February 2011 (UTC)
-The literal phrase in RFC 4291 is: ''The above multicast addresses are reserved and shall never be assigned to any multicast group.'' [[User:Mtorrecilla|Mtorrecilla]] ([[User talk:Mtorrecilla|talk]]) 09:42, 15 February 2011 (UTC)
-:: Edited the text somewhat.  I would like to propose the word "will", since that is what the authors of the RFC would like to convey with the word "shall" in a way that other RFC writers and implementors will understand. "Will" is the lay-man's way of saying this. —— [[User: dandorid|<i><sub><u>D</u></sub><sup><b>a</b></sup><small>n</small><sub><u>d</u></sub><sup><b>o</b></sup><small>r</small><sup> <b>i</b></sup><sub><u>D</u></sub></i>]] ([[User Talk:Dandorid|talk]]) 12:00, 15 February 2011 (UTC)
-:: We should indicate what is meant by "assignment to a multicast group"; either here or on the [[multicast]] wiki. Are they not a group themselves? —— [[User: dandorid|<i><sub><u>D</u></sub><sup><b>a</b></sup><small>n</small><sub><u>d</u></sub><sup><b>o</b></sup><small>r</small><sup> <b>i</b></sup><sub><u>D</u></sub></i>]] ([[User Talk:Dandorid|talk]]) 12:06, 15 February 2011 (UTC)
-I'm not native english, so i'm not able to see the diference. Perhaps, the correct word would be "should", because you shouldn't use these addresses (or you must not use them). Please, if you want, change the article and use the word that you think is better.
-About "assignment to a multicast group"..... I think that [[multicast]] wiki is better. [[User:Mtorrecilla|Mtorrecilla]] ([[User talk:Mtorrecilla|talk]]) 15:38, 15 February 2011 (UTC)
-:I agree, because that guideline is written in legal language which isn't appropriate for Wikipedia. It's technically possible but not actually permissible to use those addresses.[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 18:04, 15 February 2011 (UTC)
-== Special address section, unique local addresses external reference ==
-The reference to RFC1918 is correct in the ref name= part of <nowiki> <ref name=1918>RFC 1978 ... </nowiki>but incorrect in the text for the reference. Links to RFCs are autocreated from the TEXT not the tag, and this makes the external link at the bottom of the page direct users to RFC 1978, PPP Predictor Compression Protocol, NOT RFC 1918. Correct line should be <nowiki> <ref name=1918>RFC 1918, ...</ref> </nowiki> NOT <nowiki> <ref name=1918>RFC 1978, ...</ref> </nowiki>. My edit from 2/16 at 20:38 was correct, and should not have been reverted.
-[[Special:Contributions/71.195.229.210|71.195.229.210]] ([[User talk:71.195.229.210|talk]]) 21:00, 16 February 2011 (UTC)
-==United States Department of Defense allocation==
-The ARIN allocations to US DoD are [http://lists.cluenet.de/pipermail/ipv6-ops/2010-August/003856.html controversial]. But I do not think it factually accurate to say they got a /13, when they got 14x /22 ([http://whois.arin.net/rest/net/NET6-2608-1 USDDD-001] to [http://whois.arin.net/rest/net/NET6-260F-F000-1 USDDD-014]), evenly spaced out over a /13.
-I am unsure why SixXS lists it as a /13, as they have never seen it announced, and it is not coming from ARIN data. --[[User:Cybjit|Cybjit]] ([[User talk:Cybjit|talk]]) 21:06, 16 February 2011 (UTC)
-:We can say 14 /22s.[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 00:51, 17 February 2011 (UTC)
-::Yes, changed it now. --[[User:Cybjit|Cybjit]] ([[User talk:Cybjit|talk]]) 20:07, 17 February 2011 (UTC)
-== [[Scientific notation]] is an ''approximation'' while powers of two are exact ==
-I'd like to remind editors of this article that when representing numbers in scientific notation or otherwise in the base 10 systems, remember to say "about" or "approximate," because most of those numbers are only '''approximations''' of the real base 2 numbers. For example, 2<sup>32</sup> is only '''approximated''' by 4.3 x 10<sup>9</sup>.[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 00:51, 18 February 2011 (UTC)
-== Versions ==
-I think the editor who reverted my edit misunderstands the concept of IP versions. IPv4 is the '''fourth''' version and IPv6 the '''sixth''', '''regardless''' of whether versions 1-3 or 5 were deployed or not. I undid the edit back. Please don't revert again unless you can prove me wrong here.[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 02:08, 20 February 2011 (UTC)
-:Your edit is unreferenced and (imo) dubious. It doesn't matter what you or I say about this, and in the absence of a reliable source, I'm going to edit it to not specify that either way.[[User:Rememberway|Rememberway]] ([[User talk:Rememberway|talk]]) 02:38, 20 February 2011 (UTC)
-::The source is the [[IPv6]] article.[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 03:09, 20 February 2011 (UTC)
-:::OK, first, wikipedia articles aren't sources. Second, the only thing I could find in the article was it described as version 6 of the internet protocol. That's actually different from it being the sixth version of the internet protocol. 'version 6' is a name, whereas sixth version means that there's actually been 5 previous versions. If that sounds dubious, consider that you can often have version 4.3 of a release of software or protocols, but you can never have the 4.3th version of software. There is actually a difference.[[User:Rememberway|Rememberway]] ([[User talk:Rememberway|talk]]) 04:00, 20 February 2011 (UTC)
-::::Wikipedia articles are OK for sources for other Wikipedia articles, as I've seen elsewhere. And anyhow, let's just say version 6. Is this consensus?[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 04:03, 20 February 2011 (UTC)
-:::::''"Wikipedia articles are OK for sources for other Wikipedia articles, as I've seen elsewhere."'' Nah. Sorry. Which policy are you claiming says this?[[User:Rememberway|Rememberway]] ([[User talk:Rememberway|talk]]) 04:15, 20 February 2011 (UTC)
-::::::It's not a policy, but it's just copy and pasting, '''with the reference''', so the reference '''carries over.''' I should have said it differently.[[User:Jasper Deng|Jasper Deng]] ([[User talk:Jasper Deng|talk]]) 04:17, 20 February 2011 (UTC)
-::: If we stick to ''version 6 of the Internet Protocol'' we are neutral and avoid using the version number as an [[ordinal number (linguistics)|ordinal number]]. According to [[Internet Protocol#Version history]], IPv6 can be regarded (if you stretch it) as the sixth version of IP (versions 0-3 for testing, 4 for IPv4, and 6 for IPv6, which makes 6 versions). But the version number is in '''NO''' way related to its ordinality; if [[Internet Stream Protocol]] did not exist, IPv6 would surely be named IPv'''5''' (and ''still'' be the sixth version of IP). If version number 6 were given to another protocol before IPv6 was launched, it could be IPv'''7''', or IPv'''41''' for that matter. It is version 6 just because '6' was a free number.  <small><span class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Dandorid|Dandorid]] ([[User talk:Dandorid|talk]] • [[Special:Contributions/Dandorid|contribs]]) 12:43, 24 February 2011 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
-::::In that sense it's the 7th IP; IPv5 did exist, it's just not been widely released; and it was allocated an IP version number.[[User:Rememberway|Rememberway]] ([[User talk:Rememberway|talk]]) 16:37, 24 February 2011 (UTC)
-== IPv6 prefixes ==
-I think it would be a good idea to visualize assigned prefixes and explicitly state their ranges both in hex ( http://www.sabi.co.uk/Notes/swIPv6Prefixes.html ) and in binary (like this http://ip-doc.com/rfc/rfc2373 but with the correct information, of course). Any thoughts? [[User:PAStheLoD|PAStheLoD]] ([[User talk:PAStheLoD|talk]]) 17:13, 6 May 2011 (UTC)
-== Correct statement? ==
-Under http://en.wikipedia.org/wiki/IPv6_address#Networks, a statement is made, "For example, the configuration of an interface with address 2001:db8:a::123 connected to subnet 2001:db8:a::/64 is written as 2001:db8:a::123/64". Is this correct? When I read it, I thought that "... an interface with address 2001:db8:a::123 connected to subnet 2001:db8:a::/48 is written as 2001:db8:a::123/64". Wouldn't the subnet be a 48-bit prefix, not a 64-bit prefix? I didn't know enough to be 100% positive, so I didn't change it. — [[User:Bryan.burgers|Bryan Burgers]] ([[User talk:Bryan.burgers|talk]]) 14:15, 13 June 2011 (UTC)
-:Either is ''correct'' in terms of syntax. Whether you have a /48  or /64 depends on what your ISP gives you though, you can't change from one to the other just because there's zeroes in the address. -[[User:Rememberway|Rememberway]] ([[User_talk:Rememberway|talk]]) 15:41, 13 June 2011 (UTC)
-::As Rememberway said, it is correct. A ipv6 address 2001:db8:a::123/64 belongs to the IPv6 network 2001:0db8:000a:0000::/64. Is it more clear in this way ?
-::If you write the ipv6 2001:db8:a::123/48, its IPv6 network is 2001:0db8:000a::/48, that it is different [[User:Mtorrecilla|Mtorrecilla]] ([[User talk:Mtorrecilla|talk]]) 16:29, 14 June 2011 (UTC)
-== a6 records ==
-Currently [[A6 record]] redirects to [[IPv6#IPv6_in_the_Domain_Name_System]] which directs the user to [[IPv6_address#IPv6_addresses_in_the_Domain_Name_System]] with a "main article link" but there is no mention of them in either of those sections.
-While A6 records are were downgraded to experimental I think they should still be mentioned and explained. The question is where (they are quite complex), should I create an A6 record article independently? should I split [[IPv6 addresses in the Domain Name System]] from this article (reducing it to a summary here?) and explain A6 records in that article? should I just explain them in this article? [[User:Plugwash|Plugwash]] ([[User talk:Plugwash|talk]]) 12:30, 28 July 2011 (UTC)
-:The whole section about DNS should be moved to the DNS wiki in my opinion. You cannot properly explain how to configure them (AAAA or A6 records) in this wiki without making it a long section. You could also put in a section about typesetting an IPv6 address using [[LaTex]]; I mean: it is off-topic anyway. Put in a see-also wikilink and you're done. One thing you should NOT do is discussing a deprecated DNS feature in this article. —— [[User: dandorid|<i><sub><u>D</u></sub><sup><b>a</b></sup><small>n</small><sub><u>d</u></sub><sup><b>o</b></sup><small>r</small><sup> <b>i</b></sup><sub><u>D</u></sub></i>]] ([[User Talk:Dandorid|talk]]) 17:35, 29 July 2011 (UTC)
-::The DNS article is already huge and doesn't really mention individual record types. There is a [[List of DNS record types]] article but a list article is IMO not really the place for the prose needed to explain the A6 system. I would therefore propose that creating a new [[IPv6 addresses in the Domain Name System]] article to explain the relationship between IPv6 and DNS and the abortive idea that was A6 records is the best option unless you have a better idea. [[User:Plugwash|Plugwash]] ([[User talk:Plugwash|talk]]) 15:58, 1 August 2011 (UTC)
-:::I think it might be a good idea to move the section to a new article. It seems the easiest thing to do. If you are not comfortable in discussing this on the [[Domain Name System|DNS]] article, you could give it its own page. On the other hand, I believe that A6 records should only be mentioned as "a bad idea that some thought would solve things", without going into much detail and just referencing RFC 2874 (for the idea) and RFC 3363 (for showing it was a bad one)... That would just leave an article with the discussion of AAAA records and PTR records for IPv6, which might be just to small a topic to put into an article of itself. Anyway, I am unhappy the way it is described in the IPv6 address article, not so much the text itself, but more that an attempt is made at all to describe it here. You might blame the writers of the DNS article not to leave room for this, but that would no do them credit where credit is due. If there is no article describing the technicalities about using all kinds of DNS records, maybe there should be one; which could include the AAAA records and mention the existence of A6 records. —— [[User: dandorid|<i><sub><u>D</u></sub><sup><b>a</b></sup><small>n</small><sub><u>d</u></sub><sup><b>o</b></sup><small>r</small><sup> <b>i</b></sup><sub><u>D</u></sub></i>]] ([[User Talk:Dandorid|talk]]) 19:40, 2 August 2011 (UTC)
-== Unicast local address subnets ==
-The section about unique local addresses contained the following sentence: “RFC 4193 currently only define the <tt>fd00::/8</tt> prefix for locally assigned address.” Then someone [http://en.wikipedia.org/enwiki/w/index.php?title=IPv6_address&diff=527829380&oldid=522578942 changed] that to <tt>fc00::/8</tt>, which is wrong, so I [http://en.wikipedia.org/enwiki/w/index.php?title=IPv6_address&diff=536447988&oldid=535166440 changed it back]. [[User:Teapeat]] [http://en.wikipedia.org/enwiki/w/index.php?title=IPv6_address&diff=536469017&oldid=536447988 reverted] my change and eventually [http://en.wikipedia.org/enwiki/w/index.php?title=IPv6_address&diff=536689577&oldid=536469017 removed] the whole sentence after we discussed about it [[User talk:Teapeat#IPv6 page|on their talk page]]. Their opinion is that it is not obvious from the RFC that <tt>fc00::/8</tt> is not defined and <tt>fd00::/8</tt> should be used, so they want me to reference additional sources. My opinion is that it is obvious from the [http://tools.ietf.org/html/rfc4193#section-3.1 RFC] and that it is the best source to reference. It seems now that someone has added and rephrased the sentence, without citing any additional references. Does anyone have a third opinion on this? --[[User:Candid Dauth|Candid Dauth]] ([[User talk:Candid Dauth|talk]]) 21:01, 5 February 2013 (UTC)
-:The rfc clearly splits the space in half, makes rules for users to allocate themselves addresses from one half and reserves the other. It doesn't explicitly use CIDR notation to reffer to the halves but IMO converting from wordy descriptions to CIDR notation is just a form of rephrasing, not "original research". [[User:Plugwash|Plugwash]] ([[User talk:Plugwash|talk]]) 22:16, 5 February 2013 (UTC)
-== Modified EUI-64 ==
-For its example, the text uses a different address from the accompanying diagram, which seems unnecessarily complicated. I propose to change the text to match the diagram, unless anyone objects. (00:1D:BA in the text is Sony; 00:0C:29 in the diagram is Vmware.) [[User:Isidore|Isidore]] ([[User talk:Isidore|talk]]) 09:09, 24 June 2013 (UTC)