Subject: Comments on draft-voyer-6man-extension-header-insertion-00

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Jun 2017 10:12:25 +1200

Hi,

This has been on my to-do list for a long time:

1. The RFC Editor does not allow long lists of authors.
Up to 5 authors, some of whom may be tagged as Editors,
is OK. Any others should be listed in a separate Contributors
section. The difference is that authors must have written a
significant part of the text but contributors have made
a smaller contribution. (Saying "I agree" isn't a contribution...)

2. The consensus text in rfc2460bis is quite clear:

  "Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

  "The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,..."

So the challenge for draft-voyer- is to craft a careful exception
to that consensus. The draft will need to be a standards track
document that explicitly updates rfc2460bis.

3. The tone of the Abstract is completely wrong. It should be much more
neutral and objective, such as:

 In some circumstances there is value in inserting extension
 headers into an existing IPv6 packet at any point along its path,
 as long the entire journey of the packet is certain to remain in
 its source domain and the extended packet is certain not to exceed
 the maximum transmission unit (MTU) of its path. This document
 updates RFCxxxx accordingly.

(Also see comment 12 below.)

4. The Introduction needs to introduce the topic: a longer version
of the Abstract.

5. As well as defining "domain" the Introduction needs to define
and explain the path MTU within the domain. There's some loose
wording about this later on, but we need some precision: I suggest
formally defining the path MTU assumed by a source node (let's
say sPMTU), and the actual path MTU provided by the infrastructure
(let's say iPMTU) and then the rule that inserted headers MUST NOT
exceed (iPMTU - sPMTU) in length.

How all nodes become aware of the domain-wide values of iPMTU and
sPMTU needs to be defined. (By the way, TRILL has a solution to a
very similar problem.)

6. The Introduction (or possibly section 4) needs to specify
more precisely how a domain and its edges are defined and
identified. Is a domain a set of address ranges, for example?
Is it defined by (manual) configuration? Can its extent change
dynamically? 

7. "2.  Source Domain and Packet Journey"

This section is very strange. Is it an example, the main use case,
or what? Its presence needs some explanation.

8."Obviously, this FRR service increases the size of the packet during
   its journey within domain D.  This is well-known to operators.  Well-
   known mitigation techniques have been deployed for more than 15 years
   for the MPLS-based FRR service and the numerous VPN services.  The
   same exact technique can be used which consists of deploying an
   infrastructure capable of an MTU value higher in the core than at the
   ingress edge."

Again, this has completely the wrong tone. There is no need to shout.
By introducing sPMTU and iPMTU as suggested above, you can make this
question purely technical.

9. "2.1.  Example: 6PE"

I don't understand the relevance of this example. Yes, MPLS
stacks its headers. That's MPLS. In the context of IPv6 header
insertion, this is irrelevant.

10."3.  Transit through a Source Domain"

I don't understand the relevance of this example. It doesn't
discuss header insertion. 

11."4.  SRH insertion in Source Domain

   This document reminds that for a packet whose journey is completely
   contained within its source domain, it does not matter where the IPv6
   extension header insertion is done.

   It could be at the source or at the first-hop router or at any node
   of the source domain.

   The source domain owns the packet and decides the location, which
   suits it best."

Again the tone of this text is simply wrong (and defensive). Also,
too many words to say something simple:

   As mentioned above, an IPv6 header may be inserted at any point
   along a packet's path within its source domain, for example
   at the first-hop router.

12."During the packet journey in the source domain, any node in the
   source domain may insert an SRH and the egress node MUST remove both
   the outer IPv6 header and inserted SRH."

That is contradictory with the earlier statement that header insertion
applies when "the entire journey of the packet remains in its source
domain."

So, if that is what you intend, the Abstract and Introduction need to
be changed to make it clear that packets MAY leave the domain but
if so the inserted headers MUST be removed. And you need to specify
how the egress routers know that certain headers are to be removed,
but not others.

13."In conclusion, in a context of a controlled/trusted domain, the
   insertion of SRHs in packets that are sourced within the domain is
   useful, required and also harmless.  Hence, a context-less ban of
   IPv6 extension header insertion does not make sense."

Just delete this. It adds nothing.

What you *do* need to say here is something like:

 SRH insertion and removal as described here update the restriction
 in Section 4 of [rfc2460bis].

Regards
    Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Jun 2017 08:26:28 +0300

> document that explicitly updates rfc2460bis.

Procedurally-speaking, it would seem to me that the I-D would need to do
two things:

1) Change the is_to/must to "should"

2) Explain why an exception should be made for this particular case

Rationale: the current text in rfc2460bi is a "must", hence there's not
much room for exceptions with the current text -- without the text being
relaxed first (possibly in the same I-D).

>  updates RFCxxxx accordingly.

In which case, I'd expect that the proposal explains why they don't do
tunneling -- which, by definition, would guarantee that such packets
don't escape the intended domain.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492