Talk:Link-local address

Deletions

Parts of this article are wrong and I am in the process of fixing them, kbrose is making this difficult.

For example: Link Locals DO NOT have to use auto-configuration. This would be the equivalent of saying that mac addresses are permanent, people spoof them all the time. The RFC says nothing about auto-configuration except that it is an option. Most HOSTS use SLAAC (stateless address auto-configuration) for link-local addresses and most routers do, but you can also manually set them on router which is becoming popular for some network admins. It is very easy to do. read RFC 3513 and scroll down to 2.5.6 Local-Use IPv6 Unicast Addresses. Notice how it says nothing about 'having' to use auto-configuration. Point me to a different RFC if you disagree. Seanx820 (talk) 01:50, 26 October 2010 (UTC)

Perhaps you might also notice that this article does not state anywhere that IPv6 host are 'having to use autoconfiguration'. It merely states that "link-local addresses are used in stateless autoconfiguration", which is extremely similar to the description in the RFC you insist on quoting, as it states:

Link-Local addresses are designed to be used for addressing on a
single link for purposes such as automatic address configuration,
neighbor discovery, or when no routers are present.

The article further explicitly states that in IPv6 link-locals may be assigned by several methods, stateless and stateful. Perhaps a full reading and understanding of this article might help clear up your confusion.Kbrose (talk) 20:22, 26 October 2010 (UTC)

dude I definitely read the whole article, that statement can be very confusing... why don't you change it to "link-local addresses can use stateless auto-configuration" because usually auto-configuration is used for global addresses and you can manually set link-locals, you don't have to use auto-config, we also need to expand on modified EUI-64 format because you can use RFC 5214 (ISATAP) as well as RFC 4941 (Privacy Extensions). Meaning you link-local does not need to be based off your MAC at all, I want to teach people this.

I am not trying to start at argument here I was only mad because you deleted some of my stuff without any debate, I am fine with arguing out these details because we can both learn. Truce? Seanx820 (talk) 13:57, 27 October 2010 (UTC)

use of link-local addresses with respect to globally routeable addresses

The article incorrectly stated that use of the address must be discontinued once a globally routable address is available. This is incorrect per the RFC, which says the address SHOULD not be used if a better one is available, but may, as long as the application understands the implications, and gives a specific example of a host that is simultaneously on both the link-local network and a globally routable network, for printing of a web page to a printer with only a link-local address. —Preceding unsigned comment added by 15.203.233.79 (talk) 16:45, 1 February 2011 (UTC)

IPv4 address block

Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16.

The Internet Engineering Task Force has reserved the address block 169.254.1.0 through 169.254.254.255[note 1] for link-local addressing in Internet Protocol Version 4.

    Isn't one of these wrong?  (Third byte 0 vs. 1..254?)

Jmichael ll (talk) 03:16, 3 August 2011 (UTC)

As per CIDR notation, 169.254.0.0/16 corresponds to 169.254.0.0 through 169.254.255.255. There's a discrepancy here that should be fixed but it is not an outrageous one. --Kvng (talk) 14:24, 9 August 2011 (UTC)

There really is no discrepancy. It is a fact that the allowed range is in the address block 169.254/16, and the difference is already sufficiently explained. Kbrose (talk) 15:18, 9 August 2011 (UTC)

Where is the difference explained, I don't see it? It i as very subtle difference that is easily overlooked, it would be nice to have an explicit explanation to why it is not the entire range. Zpon (talk) 06:03, 5 September 2016 (UTC)

Wrong IPv6 link-local prefix size

Both RFC3513 and its successor RFC4391 (in Section 2.5.6) specifies that the bits 11-64 of a link-local should be 0, so effectively the prefix is fe80::/64 instead of fe80::/10.

Could somebody verify and correct the article? --Bill C (talk) 00:16, 11 September 2011 (UTC)

That does not mean that the first ten bits are also fixed. In theory there could be fe81::/64 too.Jasper Deng (talk) 02:57, 11 September 2011 (UTC)

I noticed this, and I did not change the article since for many times, "some other people" reverted my editing, so I usually put into talk. Gladly to see someone has already mentioned this! should be FE80::/64. Jackzhp (talk) 17:28, 26 January 2018 (UTC)

Good Apirlko786 (talk) 19:21, 22 July 2019 (UTC)

DHCPv6 for link-local addresses ???

The article stated/states that link-local IPv6 addresses may be assigned using DHCPv6. However, DHCPv6 requires (see RFC 3315, sections 1.1 and 16 in particular) that the address of the interface which is the object of the DHCPv6 transaction be used as source address in the header of the IPv6 datagram. This implies that a(nother) link-local address must be assigned to the interface using non-DHCP means, before a link-local address can be requested using DHCPv6.

To me, this seems redundant, and I wonder whether this use-case was actually intended. However, I will not exclude the possibility that there may actually be some distinct advantages. I therefore limited myself to adding a note describing this apparent (?) inconsistency.

Is there any information and/or experience at all out there assigning link-local IPv6 addresses statically, or using DHCPv6 ? Are there any implementations that actually support disabling automatic assignment of LL addresses ? A quick check on debian wheezy seems to indicate that Linux always configures an automatic link-local address, even if a static one has already been assigned. There also doesn't seem to be a way to disable it (but my search was not exhaustive, and I may have overlooked it). Is there any (software) support anywhere for invalidating non-DHCPv6 LL addresses after another LL address has been assigned using DHCPv6 ? And

Could anybody with more in-depth knowledge look into this ? — Preceding unsigned comment added by 86.93.246.90 (talk) 11:41, 3 December 2011 (UTC)

Because DHCPv6 requires a link-local address to function, to me it seems extremely unlikely that link-local addresses were ever meant to be assigned using DHCPv6. Even if it were the case, then such a use would probably be extremely uncommon. IMO, the statement that link-local addresses could be assigned using DHCPv6 is disputable at best, and, without references or explanation, it is certainly confusing to the reader.

As nobody has provided additional insight in this matter so far, I have therefore removed DHCPv6 as an example method for assigning IPv6 link-local addresses. --86.93.246.90 (talk) 11:04, 13 September 2012 (UTC)

Proposed Updates and clarifications to the description of APIPA and Auto IP

I was hoping that the below statement could be elaborated:

Microsoft refers to this address autoconfiguration method as Automatic Private IP Addressing (APIPA). It is sometimes also casually referred to as auto-IP.

I think there are details about both APIPA and AutoIP that are very important to the understanding of the usability of IPv4LL that should be included in this article, but that are missing. Below is my proposed elaboration:

Microsoft refers to this address autoconfiguration method as Automatic Private IP Addressing (APIPA). It is sometimes also referred to colloquially as auto-IP or Auto-IP. This term seems to have passed into common usage from the UPnP addressing scheme defined in its UPnP 1.0 Device Architecture specification. Previous to RFC 3927, there was ambiguity as to how a host with an address in the 169.254.0.0/16 block should interoperate with another host on the same link but that didn't have an address in that address block. The UPnP 1.0 Device Architecture specification definition of Auto-IP was ambiguous on this subject. Microsoft's definition of APIPA explicitly stated that this kind of interoperability was not supported, by design. The definition of Auto-IP in the UPnP 1.1 Device Architecture specification explicitly states that Auto-IP is defined in RFC 3927, and also defines forwarding rules that are consistent with RFC 3927 which ensure that source and destination hosts on the same link which don't both have 169.254.0.0/16 addresses can still interoperate. This distinction is important because it has been a source of trouble for systems that hoped to robustly support network communications in link-local environments using IPv4. Migrating these systems to use or favor IPv6 link-local over IPv4 link-local, if possible, seems the best way to avoid these interoperability problems.

smitty (talk) 05:31, 25 July 2012 (UTC)

That is a bit difficult to understand. Is there a way to simplify what you're saying here? --Kvng (talk) 14:40, 27 July 2012 (UTC)

Agreed, it is a bit too dense. But I did want the details captured somewhere. I will try to move a bunch of this into footnote text so that those wanting details and to see workings can do so without complicating a superficial read. --smitty (talk) 17:16, 27 July 2012 (UTC)

Here is a second draft, with much of the details moved into a large "ref" (put in the "note" group as per style convention on the rest of the page):

Microsoft refers to this address autoconfiguration method as Automatic Private IP Addressing (APIPA). It is sometimes also referred to colloquially as auto-IP or Auto-IP, which originates from UPnP. However, while APIPA and the original definition of Auto-IP were roughly the same, APIPA is NOT the same as the RFC 3927 definition, which UPnP defines as the current meaning of Auto-IP. This distinction is important because it has been a source of trouble for systems that hoped to robustly provide network communications in link-local environments using IPv4. Implementing such systems to use or at least favor IPv6 over IPv4 for link-local communications seems the best way to provide communications robustly.

--smitty (talk) 03:06, 30 July 2012 (UTC)

This is much better. "Seems to" in your note raises the question of whether this is original research. Similarly, we need a citation or citations for the last two sentences. --Kvng (talk) 05:10, 1 August 2012 (UTC)

This may well be original research currently. I will spend some time seeing if this is better documented elsewhere. If not, I will see if I can publish it myself. I was curious about the origin of "Auto IP", which is bandied about quite sloppily by some in my spheres of work. The last two sentences are conclusions from observations working in these domains. More soon.--smitty (talk) 15:51, 1 August 2012 (UTC)

Please look for reliable sources. Self-published sources are not considered reliable. --Kvng (talk) 16:19, 5 August 2012 (UTC)

References

MAC addresses

This claim is made in the lead and in Link-local address § Media access control. There is no citation. MAC addresses are globally unique so function at a higher level that what I would consider link-local function. ~Kvng (talk) 14:04, 23 October 2018 (UTC)

I have removed this material. ~Kvng (talk) 14:45, 29 January 2019 (UTC)

The character of a link-local address is not afforded by its uniqueness or lack thereof globally or a region larger than the link, but by the scope that it can be used for communication, whether limited by routing policies or by hardware constraints. MAC addresses may well be duplicated in more than one network without interference. Kbrose (talk) 16:57, 29 January 2019 (UTC)