Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt

[Lorenzo Colitti <[e-mail]>]

DNS servers don't differ between cell towers. The thing that differs is the
/64 assigned to the device.

The phone announces its address in that /64 as the DNS server. When the
phone's /64 prefix changes, the old address is no longer valid and
potentially belongs to another customer of the network. But with stateless
DHCPv6, there's no way for the phone to tell clients not to use it any more.

On Mon, Mar 5, 2018 at 3:51 PM, Mark Andrews <[e-mail]> wrote:

>
> > On 5 Mar 2018, at 5:44 pm, Lorenzo Colitti <[e-mail]> wrote:
> >
> > On Mon, Mar 5, 2018 at 3:35 PM, Mark Andrews <[e-mail]> wrote:
> > > Saying that mobile phones must support DHCPv6 is harmful, because:
> > >       • If DHCPv6 is enabled, it's harmful to users for the reasons
> explained in https://www.ietf.org/mail-archive/web/v6ops/current/
> msg26286.html .
> >
> > The phone can advertise itself as a DNS server.  It needs to do this
> anyway to properly service reverse DNS for the address ranges it is
> adverting in the RA.
> >
> > The phone does this already. Please read the email again.
>
> Where is the text below does it state that it is advertising itself as a
> DNS server?  The scenario only fails when it is re-advertising the TELCO’s
> DNS servers and when they differ between cell towers.
>
> Mark
>
> The Android phone in my pocket is a router when I go to the coffee shop
> every morning and turn on tethering. As the maintainer of that code, I
> absolutely do not want to spend software engineering time writing a DHCPv6
> server that is not only less capable than the RDNSS implementation that we
> have now, but also degrades functionality.
>
> The reason it is degrades functionality is that with stateless DHCPv6 it
> is impossible to implement even such basic things as "tell the client that
> its DNS server is now gone because the cellular network went down and came
> back up with a different prefix when you temporarily lost cell coverage".
> This works today using RDNSS, but if we implement DHCPv6, this will stop
> working for clients that support DHCPv6, even if they also support RDNSS.
>         • Client gets DNS addresses from both RDNSS and DHCPv6, and
> prefers DHCPv6 due to RFC 8106.
>         • Upstream goes down. We deprecate the prefix (we can't make it
> invalid because of the 2-hour rule), and declare the DNS servers invalid.
> We can't do anything about DHCPv6.
>         • The upstream comes back with a new prefix. We announce the new
> DNS servers using RDNSS. But the client still uses the out-of-date
> DHCPv6-provided DNS servers, because RFC 8106 says it should prefer DHCPv6
> over RDNSS.
> I cannot live with breaking user experience like this.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [e-mail]
>
>