<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 20, 2016 at 11:16 PM, Bernhard Schmidt <span dir="ltr"><<a href="mailto:berni@birkenwald.de" target="_blank">berni@birkenwald.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I assume<br>
this triggers some sort of spoofing protection on the iPad, since the<br>
source address of the NS is global and (according to the routing table)<br>
not on-link.<br>
<br>
I'm not sure who is at fault here (the RFC editors, me, Cisco or Apple),<br>
but changing to the more standard on-link=1 RA fixed the issue for us.<br></blockquote><div><br></div><div>Hmm. It seems that it would be useful to find out if the RFCs are at fault. On the face of it this seems like a bug in the iPad's IPv6 stack - if the NS came in with a TTL of 255 it seems reasonable to reply on-link. But it does seem to be a bit of a grey area - I suppose you could argue that the device shouldn't reply because the route back to the NS sender is not directly-connected (though that seems like a weak argument).</div><div><br></div><div>If you remove the global address from the first-hop router, such that the NSes always come from link-local addresses, do things work?</div></div></div></div>