Re: [saag] [tsvwg] Fwd: Last Call: <draft-ietf-tsvwg-transport-encrypt-19.txt> (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC

[Fernando Gont <[e-mail]>]

On 12/2/21 22:53, Tom Herbert wrote:
[....]
>>> IMO, HBH is the best vehicle
>>> to express this information and there is some good work in Network
>>> tokens, FAST, and APN around this.
>>
>> RFC7872 seems to suggest otherwise.
>>
> I disagree. RFC7872 was one snapshot in time and is now coming up on
> five years since it was published; since then RFC8200 was published
> with relaxed requirements for intermediate nodes and there is a lot
> more active work on extension headers.

There's a lot of active work on EHs, yes. You can use them in limited 
domains. But you'll likely have a bitter experience otherwise.

(To share you my own: I recently replaced my IPv4-transport tunnels with 
IPv6-transport tunnels... but but some failed. Why?  Because, Linux 
employs (by default) a tunnel encapsulation limit option, which requires 
a DO header to be inserted. And such packets often get dropped)

You may get the same when trying to use ESP, too.

RFC8200 changed the processing of HBH. But there are general 
implications of EHs (in general) -- RFC8200 has changed nothing about 
that (and in fact, it couldn't have).



> Besides that, we don't need or
> expect 100% of the Internet to support EH, we can use it
> opportunistically when we know the path works (e.g. the destination is
> a server within the user's provider network that supports the
> features).

That's indeed a different scenario (a so-called "limited domain") -- 
i.e. your network, your rules.

But I believe the discussion here is about the implications on an 
Internet-wide scope.

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