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

> On 5 Mar 2018, at 4:08 pm, Lorenzo Colitti <lorenzo@google.com> wrote:
> 
> On Mon, Mar 5, 2018 at 11:15 AM, <internet-drafts@ietf.org> wrote:
>         Title           : Requirements for IPv6 Routers
>         Authors         : Zaid Ali Kahn
>                           John Brzozowski
>                           Russ White
>         Filename        : draft-ietf-v6ops-ipv6rtr-reqs-02.txt
> 
> I continue to object to the one-size-fits all approach taken in the document. Here are two examples of how that leads to harmful outcomes.
> 
> Saying that mobile phones (which forward IPv6 packets when the user desires them to) should support YANG, SNMP, and syslog would just be ridiculous if it wasn't harmful (because it creates the potential for a security vulnerability - the more remote management code running on the device, the greater the risk of vulnerability).
> 
> 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.

> 	• If DHCPv6 is disabled, it's harmful to users because somebody wrote code for something that's never enabled.
> 	• I don't think there will ever be any other choices than the above two, since no popular OS will provide a configuration mechanism for the user to enable/disable DHCPv6 on the mobile hotspot. (If you don't agree with that assertion then consider: those OSes don't even allow the user to enable/disable IPv6. Why would they allow the user to enable/disable DHCPv6?)

Well most home routers for last 10 years didn’t have a option to disable IPv4 but had options to enable/disable DHCP.

> Authors: the last time v6ops dealt with a "kitchen sink shopping list" document of this sort was RFC 7849. That document generated a lot of noise on the mailing lists, went back and forth for many months, and ended up being withdrawn as a WG document and published as individual submission which has zero normative value. I assume that's not your desired goal for this document? If so, I would suggest adding an applicability statement that clarifies that not every piece of equipment under the sun that ever happens to forward an IPv6 packet must meet these requirements.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org