Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers

[Fernando Gont <[e-mail]>]

On 14/9/20 07:46, tom petch wrote:
> The problem that I have with this I-D is that I do not think that it
> will achieve its objectives.  It wants to raise awareness about the
> problems caused by Extension Headers so the target audience should be
> the world at large, especially those involved in setting up and
> operating IPv6 networks, but the style is, to me, rather academic, as
> if the audience was the sort of people who would be expected to be
> familiar with the literature and need little or no explanation. 

That wasn't the intent (at least half of the authors are operators).

But we do indeed assume that the reader knows what IPv6 extension 
headers are, what they are for, etc.

I wouldn't mind writing a Section that sits between the current Sections 
2 and 3 with more background on extension headers, if you think that 
would be of value.



> I
> see this strongly in s.1, about Extension Headers, yet devoid of any
> reference, any explanation.  The first reference is RFC2460, which is
> Normative, so are readers expected to be familiar with the details
> therein? 

Yes. As noted above, I don't personally mind including a section that 
introduces the topic, if you think that'd be of value.


> One reaction might be 'So Extension Headers create problems
> so don't ever use them!'

Our goal is, for the most part, for folks to make an informed decision.
My *personal* take is that you probably may use EHs somewhat freely and 
safely in a limited domain, but not on the public Internet.



> The I-D lacks any explicit explanation of what an Extension Header
> is, what they were intended for, which bits have worked and which
> have failed so eg deprecating RHT0 is not very meaningful without
> some comment about RH something else.

Well, this is somewhat implied by having RFC8200 as a normative reference.



>  Size matters as can be
> inferred from s.4 but there is no mention of the sizes involved of
> the IPv6 packet, with or without headers.  As I say, it seems that
> the reader is expected to know the literature.  There needs to be a
> page or two at the start giving the context within which the detail
> makes sense.

Fair enough. We'll work on one.



> And then there is the future; should more Extension Headers be
> allocated, should they be constrained to avoid the difficulties
> raised here?  The I-D, for me, lacks an ending, lacks a look
> forward.

This is, in a way, intentional.

My *personal* thoughts are:
+ we should *not* constrain the allocation of EHs (see below)

+ developers should be aware that usage of IPv6 EHs on the public 
Internet increases the chances of packets being dropped (* NOTE)

+ In limited domains, "your network, your rules", so it should be 
generally fine to do things like SRv6. OTOH, if you expect that to work 
reliably on the *public* Internet, it may not.

(*) e.g., I recently changed the transport of my tunnels from v4 to v6. 
When doing so, Linux implicitly added a tunnel encap limit option to 
then, which resulting in the addition of a DO header, which led to the 
corresponding packets being dropped. SO the above advice would have 
suggested that, by default, one would have refrained from adding the DO 
header.

Other than the above, other speculations and advice will most likely be 
unrealistic. "don't drop the packets" -> "I have a network to run". 
"Have your platform be able to look into the packet without performance 
penalties" -> "I will if you pay for it", etc.

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