On Fri, Feb 28, 2020 at 4:03 AM Sander Steffann <[email protected]> wrote: > > Hi, > > I have been thinking about SRv6 and the whole discussion around header > removal at one of the SR nodes. While I strongly see the current network > programming PSP function as a violation of RFC8200, one of the possible > options is of course to update RFC8200 to allow some things that are > currently not allowed. > > Before you start throwing rotten tomatoes, hear me out :) > > The most important argument against modifying a packet between the sender and > the final receiver is that it can cause surprises for the sender. ICMP errors > getting back to the sender about stuff the sender didn't do, pMTUd problems > etc. And I think this is a very strong argument, and we shouldn't cause any > surprises for the sender. > > But, what if the sender *asks* the network to do things to its packets? Like > in network programming. If the sender asks to have the network perform a > certain function, it can't come as a surprise when it gets an ICMP error > after the packet has been modified. It asked for that modification itself! > And with that in mind, we might actually allow much more than just header > removal in the network. > Sander,
Please take a look at draft-herbert-6man-eh-attrib-00, I think it is very much in line with what you're thinking. The basic idea is that we create a new "Attribution" Hop-by-Hop option. The option serves two purposes: 1) If the source host sets the option in a packet then it is giving permission to intermediate nodes to insert extensions headers (and Hop-by-Hop options which need to be handled specially). Presumably, when the source includes the option it is capable of dealing with ICMP errors with inserted extension headers. 2) The option indicates the extension headers (and Hop-by-Hop options) that have been inserted by intermediate nodes. So it's modified by intermediate nodes when insertion happens. The effect is that for any given packet at any time it is clear which data is attributed to the source node, and which is attributed to intermediate nodes. The option would also allow intermediate nodes to remove inserted headers (ones attributed to intermediate nodes) Receiver handling of inserted headers needs to be considered. For making AH work, it would be straightforward simply not include any inserted headers in the computation, the necessary information to do that is in the HBH option. In this case, the option can't be ignored so second high order bit of option type would need to be set. If AH isn't present, I believe the HBH option could safely be ignored if unknown at the receiver. Other than AH, I don't see any other cases where ignoring the HBH option and processing inserted options leads to incorrect behavior (if there are possible cases please point them out). Tom > What if we update RFC8200 to allow packet manipulation in the network if and > only if the sender of the packet explicitly asked for that? That would open > the door for a whole range of innovation (PSP, WAN optimisation, payload > compression etc), but only when requested. If the sender explicitly includes > network programming instructions then there is no need anymore to forbid the > execution of those instructions. No surprises, the possibility of smarts in > the network, while still preserving the current semantics of an end-to-end > network by default with strong rules about not messing with the packet. > > Would this be a way forward that would accommodate everyones requirements? > > Cheers, > Sander > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
