<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>Hi,<br class=""><br class=""><blockquote type="cite" class=""><div class="">On 26 Mar 2015, at 16:53, Roman Mamedov <<a href="mailto:rm@romanrm.net" class="">rm@romanrm.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><fieldset style="padding-top:10px; border:0px; border: 3px solid #CCC; padding-left: 20px;" class=""><legend style="font-weight:bold" class="">Signed PGP part</legend><div style="padding-left:3px;" class="">On Thu, 26 Mar 2015 14:26:14 +0100<br class="">Philip Homburg <<a href="mailto:philip.homburg@ripe.net" class="">philip.homburg@ripe.net</a>> wrote:<br class=""><br class="">> > Nothing really surprising about this. There is simply no IPv6<br class="">> > offered by the ISP, and many ISPs still do not begin to deploy IPv6<br class="">> > and only promise (if even that) for months and years.<br class="">><br class="">> But is that a good reason for a CPE to start announcing IPv6 prefixes?<br class=""><br class="">Sure, why not. Nobody is surprised when a CPE with no Internet uplinks<br class="">configured or operating still provides DHCPv4 server to the LAN, giving out<br class="">RFC-1918 IPs.<br class=""><br class="">> > And imagine some future IPv6-only client device. With ULA it could<br class="">> > access local services of the user's LAN (for example files shared<br class="">> > from a NAS), if there is no need for it to access anything on the<br class="">> > Internet.<span class="Apple-converted-space"> </span> Trying to use LLs for this and lugging around<br class="">> > "%interface" everywhere is not an acceptable answer.<br class="">><br class="">> Link local was supposed to solve the 'dentist office' problem where<br class="">> there is no router.<br class=""><br class="">They really don't. Barely any (if any at all) client software supports<br class="">explicitly specifying the interface identifier along with the IP or hostname,<br class="">or does so in a consistent manner. LL IPs are not usable in any form by the<br class="">user, aside from pinging from the command line (and even then, it's bothersome<br class="">to not forget to specify the interface all the time).<br class=""></div></fieldset></div></blockquote><div><br class=""></div>Indeed.</div><div><br class=""><blockquote type="cite" class=""><div class=""><fieldset style="padding-top:10px; border:0px; border: 3px solid #CCC; padding-left: 20px;" class=""><div style="padding-left:3px;" class=""><br class="">Even if there's some mDNS in operation, the proverbial dentist still can't be<br class="">expected to be typing "<a href="http://printer.local%eth0/" class="">http://printer.local%eth0/</a>" into their web browser<br class="">(assuming that would have been supported in the first place…)<br class=""></div></fieldset></div></blockquote><div><br class=""></div>With the work in the IETF dnssd WG, such service discovery may happen over a wider scope (multi-link), see <a href="https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00" class="">https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00</a>.</div><div>But the address advertised would then be greater scope too.</div><div><br class=""></div><div>Tim</div><br class=""></body></html>