Re: SRH insertion vs SRH insertion + encapsulation

[Mark Smith <[e-mail]>]

On Sun, 8 Sep 2019, 12:32 Ole Troan, <[e-mail]> wrote:

> Ron,
>
> IMHO, EH insertion modifies the semantics of the IPv6 source address.
> Today, the IPv6 source address indicates the source of an IP packet and *
> *ALL** of its contents. If transit routers are allowed to insert
> extension headers, downstream routers can no longer identify the source of
> a packet and all of its contents.
>
>
>
> Granted, in some cases, transit routers are allowed to modify a packet
> (e.g., Hop Count, DHCP, mutable options). But there is a big difference
> between changing a field whose value is know to me mutable and inserting a
> new option.
>
>
> 6296?
>

I don't agree with RFC 6296 and NAT in general because of the operational
problems it causes and has caused me.*

The caveat with RFC 6296 is that it is Experimental, not Standards Track. I
don't think people should use it, however with that RFC they will hopefully
consistently do something they shouldn't do.

In comparison to anonymous EH insertion, at least the NPT box overstamps
the packet source address in the inside to outside direction, so in one
direction it isn't anonymous. If you're troubleshooting from that side
there is no ambiguity, because the NPT box will look like the packet's
original source host.

If you're troubleshooting from the inside, the location of the NPT box is
going to known, likely at the network/Internet edge.

EH insertion is far worse, because it's entirely anonymous.


* "The Trouble With NAT", using a set of operational Network Critical
Success Factors as criteria.
https://blog.apnic.net/author/mark-smith/


> And I am pointing that out because of what feels like moral righteousness
> and hypocrisy to me, not because I think header insertion is a good idea or
> even doable.
>
> Ole
>