Add a requirement for extensibility

[chris-wood]

During IETF 109, @tfpauly suggested that an extension be added that allow deployments to negotiate that the "full" version of IP proxying not be implemented. Such an extension might negotiate the use of IP header compression, for example. It might be worth adding this to the requirements document.

[tfpauly]

I don't think it would negotiate not implementing to the full IP proxying. I think full IP proxying can always be the baseline, but rather than it must allow extensions to negotiate doing compression or other performance optimizations.

[chris-wood]

Poor choice of words on my part (lateness of the hour). Your phrasing is basically what I was after.

[DavidSchinazi]

What does "full IP proxying" mean here? Not compressing the IP header?

[gloinul]

If you are keeping all the IP header then its tunneling and not proxying. Because you are encapsulating the packet in QUIC and then decapsulating it.

[DavidSchinazi]

I think this is backwards. The requirement is for a protocol that can send encapsulated unmodified IP packets. Compressing IP headers sounds like a very useful extension, but you always need to be able to send uncompressed packets when compression fails.

[gloinul]

I do think calling it full proxying is wrong. However, I think we are running into an issue in that we don't have definitions for what is tunneling, and what is proxying.

To me tunneling is only encapsulation and then decapsulation. This implies no rewrite of any of the inner headers by the MASQUE client or server. I think the network to network use cases are aiming for pure tunneling as the source IP address of packet the MASQUE server decapsulate will not be rewritten.

IP Proxying could be to encapsualte the complete header but have the MASQUE server rewrite the source IP address after decapsulation and then forward it towards the target address. Due to this I think the single client to network use case can be proxying.

If we contrast this with the UDP proxying (CONNECT-UDP) where an inner UDP payload destined to the target from the MASQUE client gets it IP + UDP headers generated by the MASQUE Server (proxy) before the packet being forward towards target.

So I hope you see that there might be some mismatch in expectations between parties here.

[SpencerDawkins]

This was discussed during chartering, so it's not a new point of confusion, and it's confused people in both IETF and 3GPP within the past 7 days, so @gloinul and I aren't the only ones who are still confused.

I agree with @gloinul about tunneling being encapsulation and decapsulation (and I'm pretty sure that's almost a universal understanding in the INT area).

If you're talking about rewriting an IP source address (and, I suppose, related translations), but nothing else, I'm not sure how this is NOT a Network Address Translator.

To me, proxying is doing more than network address translation - there are obviously a lot of things that would fall under the category of "more", like CONNECT-UDP, but what CONNECT-UDP does isn't the only possible thing proxies do.

Do The Right Thing, of course.

[DavidSchinazi]

I agree that "full proxying" is not defined, and I'd prefer to not use that term at all.

Regardless of terminology, I personally think that the minimum viable product here is a system that transfers IP packets unmodified. There is a clear use case for that, and any modification to IP headers or payloads should be left to extensions (to be clear, these extensions will be incredibly useful to the performance of the overall system).

[DavidSchinazi]

We wrote text in draft-ietf-masque-ip-proxy-reqs-01 that should address this issue.