Re: [v6ops] [Last-Call] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05

["Pascal Thubert (pthubert)" <[e-mail]>]

> > Certainly this is not what my pc or my phone do. They reach a dell
> > known address from the OS vendor. Still there is no IETF spec /
> > blessing / study about that behavior.
> 
> There is: RFC 7710 (Captive-Portal Identification Using DHCP or Router
> Advertisements (RAs)).
> 

It's not. We are talking about what the OSes do today to detect the portals. 
What they do is some proprietary game going through a server of theirs in the internet (e.g., MSN).

> However, that doesn't address the political problems surrounding this issue.
> 
> > One reason is that we did not specify a better way.
> 
> We did.

Granted

> 
> > > Even the well-known address may cause operational problems for
> > > disconnected operation.
> >
> > This is listed as a cons already.
> 
> Should be a good reason to not do it.

But the OS still does the above magic; So they found it was not.

> 
> > Actually I was pondering pinging the newly formed global address from
> > an already formed link local one, passing ping the packet to the
> > router at L2...
> 
> That would certainly be an interesting trick. From a standards perspective that
> is almost the same as pinging the router directly, but from an operational
> perspecitive it might be different.
> 
> Though I wonder, if this is just to work around waiting for DAD to finish. It may
> fail to achieve its desired effect.

Regardless, the NCE in the router must still be installed before the first packet comes in.
But this is a lot more fun when using ODAD.