* Tore Anderson > Now, my own mobile provider (or probably more correctly, the GGSN vendor > used by my mobile provider) does assume that mobile nodes adhere to the > spec. Because of this, it will unicast the RAs it emits to the > link-local address it expects the mobile node to have configured (i.e. > fe80::a:b:c:d in this case). Now, if the mobile node has played fast and > loose with the standards and skipped configuring this link-local > address, its IP stack will discard the inbound ICMPv6 RA packets as "not > addressed to me". Therefore, it will never see the Prefix Information > Option in the RA, which is the *only* way global addresses is signaled > to the nodes in 3GPP mobile networks. So the node will end up without > any IPv6 address at all (neither global nor link-local), and thus > without any usable connectivity.
I'm no 3GPP expert either. You're right that it's pretty clear that the autoconfiguration standard requires link-local addresses for unicast configuration discovery (I hesitate to call it router discovery when you know you're already talking to the router). How complicated a way to convey a coulpe of configuration parameters. Another reason why I understand the IPv6 critics. > I am not disputing that you've seen a working PPP connection without > link-locals. There are probably many situations where IPv6 will work > just hunky-dory without any link-local addresses configured. But that's > besides the point I'm trying to make; just because it works in one place > doesn't mean it will work in another. My point was that in specific cases, link-local addresses may not be needed. Nothing more than that. It looks like you actually agree with that so there's not much more to discuss in this area. > So a piece of software like NM, > which will be used all over the place, ought to adhere to the specs as > closely as possible, Basically I stated that NetworkManager doesn't support some working configurations. I provided at least one example of another tool using such a working configuration that's not 100% compliant given that the requirements in the RFC are apparently intended for fully locally interoperable (physical) nodes but it's not explicitly stated in the document. I didn't even say that NetworkManager must support those configurations, I just guessed it would be useful. And it indeed would, just imagine a running NetworkManager instance in OpenVZ just providing the connection information to the applications. It shouldn't actually treat a missing link-local address as fatal in that case, as it doesn't impact global communication. I believe we actually agree from the beginning, as the *defaults* must be as compliant as possible while still not causing trouble (that's why we pad DNS lifetimes even though it's not explicitly allowed by the standard). I'm talking about further possibilities, not defaults. Those further possibilities don't even need to be accessible via GUI tools, so that ordinary users don't mess with them. I don't see a conflict between our common desire to provide a 99% compliant implementation (or 100% if the standards get fixed) and my intention to provide also a little bit more. You've seen in the past that our intentions are usually pretty much compatible ;). And you must know from our past conversations that I do like link-local addresses for not just setting up the infrastructure setup. Remember the glibc getaddrinfo issues. Cheers, Pavel _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
