Talk:Unique local address

	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 Low-importance).

Internet Low‑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 articles
Low	This article has been rated as Low-importance on the project's importance scale.

It is requested that a photograph be included in this article to improve its quality.
The external tool WordPress Openverse may be able to locate suitable images on Flickr and other web sites.

Upload

Vague wording about address blocks[edit]

I cannot figure out if fc00::/7 includes fd00::/8. The wording in the article is vague. Artem-S-Tashkinov (talk) 08:17, 14 June 2015 (UTC)[reply]

Which wording? The statement "The address block fc00::/7 is divided into two /8 groups: The block fc00::/8 [...] The block fd00::/8" seems clear to me. —80.192.177.23 (talk) 18:29, 4 September 2015 (UTC)[reply]

Not Vague wording, it’s incorrect information[edit]

RFC 4193 specifically states that the group is FC00:/7. It is never referred to as FC00::/8 or FD00::/8. The reason being is that the first 7 bits are reserved as 1111 110. These 7 bits are the prefix to the address that indicate to any router or software IP stack that the address is a an RFC 4193 locally assigned address. The 8th bit is the ‘L’ bit or the ‘local’ bit that indicates that the address was assigned locally. Per the RFC this bit should always be set to 1; 0 has yet to be defined with a meaning. But this bit is not part of the prefix that cannot be changed. As a result you end up with 1111 110/X which is FC00::/7 plus the ‘L’ bit (replacing the ‘X’ above) making all Unique Local Addresses FD00::/7. But even though the 8th bit must always be a 1 that doesn’t mean the address block is FD00::/8 or FC00::/8. It is always FC00::/7 or FD00::/7 because the first 7 bit are what is reserved for the prefix, not the first 8 bits. The document should be changed to reflect this fact even if it means adding an explanation like this one. For reference, here is an excerpt from the RFC 4193 document:

      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
      +--------+-+------------+-----------+----------------------------+
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
      +--------+-+------------+-----------+----------------------------+

   Where:

      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
                        addresses.

      L                 Set to 1 if the prefix is locally assigned.
                        Set to 0 may be defined in the future.  See
                        Section 3.2 for additional information.

      Global ID         40-bit global identifier used to create a
                        globally unique prefix.  See Section 3.2 for
                        additional information.

      Subnet ID         16-bit Subnet ID is an identifier of a subnet
                        within the site.

      Interface ID      64-bit Interface ID as defined in [ADDARCH].

Here you can clearly see that the first 7 bits are the prefix and the 8th bit serves a separate function and therefore should not be included in the reserved space as indicated by the use of FC00::/8 or FD00::/8 asa is currently in the document. — Preceding unsigned comment added by Dhummel77 (talk • contribs) 06:40, 29 August 2019 (UTC)[reply]

@Dhummel77: Thanks but I don't see where the current article is wrong. I am not very familiar with IPv6 but I can see that talking about fc00::/7 with L = 0 or 1 is equivalent to discussing fc00::/8 and fd00::/8. Please quote some text from the article that you feel is incorrect or misleading and briefly mention why. Johnuniq (talk) 07:08, 29 August 2019 (UTC)[reply]

RFC 4193 clearly states: L is set to 1 if the prefix is locally assigned. Set to 0 may be defined in the future.See Section 3.2 for additional information.

This means it is mandatory to use L = 1 with the consequence of having fd... but never ever fc... Even IT teachers mis sthis important point. In fact fc00::/7 = fd00::/8 by definition of "L" in RFC 4193. 2A01:C23:6D39:DBFF:0:0:0:3D7 (talk) 11:50, 27 June 2022 (UTC)[reply]

Dated statement?[edit]

Article says:

The block with L=0, fc00::/8 is currently not defined.

Shouldn't that use {{as of}}?

79.178.188.184 (talk) 10:48, 14 August 2022 (UTC)[reply]

It's a borderline case, I think it's OK without {{as of}}. I add {{as of}} to articles all the time, citing MOS:RELTIME, but it isn't necessary if the statement is unlikely to become out of date. In this case, if there is ever any movement towards defining that block, networking enthusiasts will be updating this article within hours. The statement won't become out of date. Indefatigable (talk) 20:02, 15 August 2022 (UTC)[reply]

History is unclear[edit]

The sequencing in the History section is confusing. In the second paragraph it talks about the special behavoour being lifted in 2006, and then the next paragraph talks about October 2005 and it being reserved (again??). So it is unclear what is the current state. Sejtam (talk) 03:16, 9 March 2023 (UTC)[reply]