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

From: [email-masked]
Date: Sun, 04 Mar 2018 18:15:52 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Requirements for IPv6 Routers
        Authors         : Zaid Ali Kahn
                          John Brzozowski
                          Russ White
	Filename        : draft-ietf-v6ops-ipv6rtr-reqs-02.txt
	Pages           : 32
	Date            : 2018-03-04

Abstract:
   The Internet is not one network, but rather a collection of networks.
   The interconnected nature of these networks, and the nature of the
   interconnected systems that make up these networks, is often more
   fragile than it appears.  Perhaps "robust but fragile" is an
   overstatement, but the actions of each vendor, implementor, and
   operator in such an interconnected environment can have a major
   impact on the stability of the overall Internet (as a system).  The
   widespread adoption of IPv6 could, particularly, disrupt network
   operations, in a way that impacts the entire system.

   This time of transition is an opportune time to take stock of lessons
   learned through the operation of large scale networks on IPv4, and
   consider how to apply these lessons to IPv6.  This document provides
   an overview of the design and architectural decisions that attend
   IPv6 deployment, and a set of IPv6 requirements for routers,
   switches, and middleboxes deployed in IPv6 networks.  The hope of the
   editors and contributors is to provide the necessary background to
   guide equipment manufacturers, protocol implementors, and network
   operators in effective IPv6 deployment.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6rtr-reqs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-02
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6rtr-reqs-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Mar 2018 14:08:04 +0900

>         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 .
   - 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?)

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 5 Mar 2018 18:54:01 +1300

On 05/03/2018 18:08, Lorenzo Colitti wrote:
> document. 

I think the problem starts with the title.

"Requirements for Enterprise IPv6 Routers"
or
"Requirements for Fully Featured IPv6 Routers"
would be more like it. I expected to see much more text about
scoping added at the start of the document.

Probably, looking ahead to a network of 10^12 nodes with massive
amounts of mesh networking, the large majority of devices that
forward IP packets will not require most of these features.

    Brian

> Here are two examples of how that leads to harmful outcomes.
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Mar 2018 17:35:22 +1100

> On 5 Mar 2018, at 4:08 pm, Lorenzo Colitti <[email-masked]> wrote:
> 
> 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).
> 
> 	• 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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Mar 2018 15:44:58 +0900

On Mon, Mar 5, 2018 at 3:35 PM, Mark Andrews <[email-masked]> wrote:

> >       • 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.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Mar 2018 17:51:51 +1100

> On 5 Mar 2018, at 5:44 pm, Lorenzo Colitti <[email-masked]> wrote:
> 

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.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Mar 2018 15:54:49 +0900

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 <[email-masked]> wrote:

> 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.
>         • 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.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Mar 2018 18:00:36 +1100

> On 5 Mar 2018, at 5:54 pm, Lorenzo Colitti <[email-masked]> wrote:
> 
> 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.

So you are tearing down the network too fast in the phone.  The point to “deprecating” the prefix is to keep stuff like this working for a while using the deprecated addresses.  If the stateless DHCPv6 is adverting resources with TTLs longer than the RA timers then you as a developer of the phone have build a broken product.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 5 Mar 2018 08:42:14 +0100

* Mark Andrews <[email-masked]>

> > 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.  
> 
> So you are tearing down the network too fast in the phone.  The point
> to “deprecating” the prefix is to keep stuff like this working for a
> while using the deprecated addresses.  If the stateless DHCPv6 is
> adverting resources with TTLs longer than the RA timers then you as a
> developer of the phone have build a broken product.

You're forgetting that the network could be torn down for all sorts of
reasons outside the phone's control, like driving through a tunnel.
When you emerge from the tunnel 10 seconds later, the phone might
receive a new /64.

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Mar 2018 16:50:33 +0900

On Mon, Mar 5, 2018 at 4:00 PM, Mark Andrews <[email-masked]> wrote:

> So you are tearing down the network too fast in the phone.  The point to
> “deprecating” the prefix is to keep stuff like this working for a while
> using the deprecated addresses.

We tear the network down when the network tears it down. Per 3GPP
standards, the prefix lifetime in the RA is infinite and the prefix is
current for as long as the link is up.

The bottom line is if you want end-to-end connectivity, a configuration
protocol that does not allow push updates is broken.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Mar 2018 18:55:41 +1100

> On 5 Mar 2018, at 6:42 pm, Tore Anderson <[email-masked]> wrote:
> 

So?  The existing /64 is STILL valid. You just have 2 prefixes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Mar 2018 16:56:32 +0900

> So?  The existing /64 is STILL valid. You just have 2 prefixes.

No you don't, the network is free to assign the old one to someone else.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Mar 2018 19:00:36 +1100

> On 5 Mar 2018, at 6:56 pm, Lorenzo Colitti <[email-masked]> wrote:
> 

Again there is NOTHING stopping the phone advertising itself over a ULA
prefix even if it is tearing down the prefixes from upstream.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Mar 2018 17:07:04 +0900

"Let's add another IPv6 address range because our configuration protocols
can't update the one we have."

Seems like the wrong solution.

---

From: Pablo Alvarez <[email-masked]>
Date: Mon, 5 Mar 2018 10:28:00 -0500

I am happy with the updates to section 5.4, ICMP considerations.

Thanks

Pablo Alvarez

---

From: <[email-masked]>
Date: Sat, 10 Mar 2018 06:11:14 -0500

> Saying that mobile phones must support DHCPv6 is harmful, because:

Saying that a mobile phone is a router _designed_ to forward IPv6 packets, when it clearly only forwards these packets incidentally, seems like a stretch, however.  

> 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.

If you can write such an applicability statement, beyond what is already in there, that does not essentially make the document pointless, please suggest text. What is there, at this point, already makes the draft non-normative, as there is apparently no possible way to write a normative set of requirements for anything relating to IPv6 -- every deployment is apparently a special snowflake with nothing in common other than the number of bits in the address.

😊 /r

---

From: <[email-masked]>
Date: Sat, 10 Mar 2018 06:13:28 -0500

> I am happy with the updates to section 5.4, ICMP considerations.

Thanks!

😊 /r