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

From: [email-masked]
Date: Tue, 02 Jan 2018 10:49:54 -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-01.txt
	Pages           : 30
	Date            : 2018-01-02

Abstract:
   The Internet is not one network, but rather a collection of networks.
   The interconnected nature of these networks, and the nature of the
   interconneted 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 interconneted 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 neccessary background to
   guide equipment manufacturers, protocol implemenetors, 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-01
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6rtr-reqs-01

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

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: <[email-masked]>
Date: Tue, 2 Jan 2018 13:52:39 -0500

>         Title           : Requirements for IPv6 Routers

I've addressed all of the comments I had notes for except --

- Should PVD be included?
- Add a redirects section -- I don't remember what this was in reference to.
- The suggestion for an appendix containing a plain list of the requirements.

The first needs on list discussion, I think. For the second, I need to find the context. For the third -- I may add an appendix if we get to a version with no comments, if folks think it's useful.

😊 /r

---

From: Fred Baker <[email-masked]>
Date: Tue, 2 Jan 2018 13:29:29 -0800

> I've addressed all of the comments I had notes for except --

Thanks for this. You will have seen, by now, my request for online discussion of the draft.

If I have one comment, it would be this:

The document is developed in comparison to RFC 1812, which I know a little about. RFCs 1122, 1123, and 1812 were developed by the community (I came in late in the game) to update and address a variety of small issues that had been identified and sorted out. Today, if we were doing this, we might start with an "erratum", such as "let's clarify: subnet broadcast address has a host part that is all ones, not all zeroes", and we would address the issue in some subsequent update to the relevant RFC. In the late 1980's, there was a perception that "OMG, updating each RFC would be a huge job". I think Bob Braden might agree with me when I say "updating them all in a single omnibus document, so big it became three, was a huge job".

The major advantage that RFC 1812 had was that it was edited when CIDR was being agreed to and worked on in a number of working groups, and we could address CIDR in one broad document. It was also at a time when the behavior of several routing protocols (RIPv1, which made non-CIDR assumptions, OSPF with TOS-Based-Routing, and IS-IS with TOS-Base-Routing) needed to be described so that networks could deploy them interoperably. The practical objective was to "finish" work that had been going on for some time and lost its way; the theoretical objective (stated with the benefit of 20/20 hindsight) was to describe a new commercial Internet that was just coming into being.

The huge benefit that RFCs 1122, 1123, and 1812 brought to the community was not WHAT they indicated had been decided. It was WHY, among several possible solutions, they had been selected. The three documents gave vendors, open source, and other developers a view into operational experience regarding what worked, what didn't, and WHY some solutions were better than others.

If there is one thing I want to find in this document, it is WHY, backed by operational experience.

Let me put this in a specific request to the authors. I would like to hear from multiple networks - LinkedIn, yes and of course, but also others - what you would like to mention by reference in your RFPs. How do you intend to build your networks? What requirements does that impose on each bit of equipment?

As a transition mechanism, I can imagine that you have micro-services that are IPv4-only, at your ingress that it might be load balancers serving a web-based service, and in the back end it might be "simple" translation such as proposed in IVI or SIIT-DC. Your network therefore looks something like:

       ,-.               ,---.                ,---.
      /   \             /     \              /     \
     /     \          ,'       `.          ,'       `.
    /       \        ;           :        ;           :
   ;         :       ;           :        ;           :
   ;         :      ;             :      ;             :
  ;           :     ;             :      ;             :
  |           |    ;               :    ;               :
  | The Great +----+   IPv6-only   +----+  IPv4-only    |
  | Unwashed  |XLAT|  Data Center  |XLAT|  Back End     |
  |           +----+               +----+ Microservices |
  |           |    :               ;    :               ;
  :           ;     :             ;      :             ;
   :         ;      :             ;      :             ;
   :         ;       :           ;        :           ;
    \       /        :           ;        :           ;
     \     /          `.       ,'          `.       ,'
      \   /             \     /              \     /
       `-'               `---'                `---'

Tell me what you require of those equipments, and more specifically, why? Is HTML the waist of your hourglass? Tell me about that?

---

From: Tim Chown <[email-masked]>
Date: Wed, 3 Jan 2018 15:47:52 +0000

Hi Russ,

> On 2 Jan 2018, at 18:52, [email-masked] wrote:
> 
> 

I forwarded you the context of the redirects separately.

One thing we should do, as RFC6434-bis is now being wrapped up, is a sanity check of the two documents to look for any conflicts. We did this a couple of versions ago and nothing major sprung out (I think I emailed you a couple, which were resolved), but it would be useful to repeat the exercise.  Tim and I are in the process of a - hopefully final - 6434bis update in the next week or two, so it’s timely.

Best wishes,
Tim

---

From: Pablo Alvarez <[email-masked]>
Date: Fri, 5 Jan 2018 11:34:59 -0500

Comments on section 5.4 ICMP Considerations

1. Thanks for adding the new text in the fifth bullet ("SHOULD NOT
filter Destination Unreachable or Packet..."). It was intended to
clarify and supersede the text in the first bullet ("SHOULD NOT filter
ICMP unreachables..."), so I do not think the first bullet is needed any
longer.

2. I believe the statement in the second bullet ("SHOULD filter ICMP
echo and echo response by default, to prevent the discovery of reachable
hosts and topology") is too strong. There are valid business and
research reasons to discover reachable hosts and topology. I understand
that obscurity is a valid security layer. However, it is not clear to me
that the security risks of that discovery or of ICMP based attacks are
high enough that we should recommend ICMP filtering by default.

Moreover, the text does not specify whether the filtering refers to all
echo and echo reply packets traversing the router (which I believe would
clearly be excessive) or only those intended for the router (which I
still would argue is too strong).

I propose the following. By default:

- ICMP echo request/reply packets not intended for the router should be
forwarded like any other packet

- ICMP echo request packets directed at the router should be
rate-limited to protect the router CPU (in a similar way to the error
packet generation described in the third bullet point).

- I have no strong opinion on ICMP echo reply packets directed at the
router. Pinging from a router can be a useful tool so we want to be able
to see those. Maybe blocking them by default unless the ping tool is in
use would work, but that adds complexity.

Pablo Alvarez

On 01/02/18 13:52, [email-masked] wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: <[email-masked]>
Date: Fri, 19 Jan 2018 19:52:59 -0500

> Comments on section 5.4 ICMP Considerations

Thanks! I'll modify the text as suggested.

😊

Russ

---

From: Pablo Alvarez <[email-masked]>
Date: Mon, 22 Jan 2018 13:47:33 -0500

Thanks!

Pablo