setkey(8): NAT-T manual configuration support

[bz]

Can you please add details (a proposed commit message) as that might shed light onto why you may think this is needed/useful?

sbin/setkey/parse.y

794

Please also hide IPv4. Way more important to be able to phase it out than hiding IPv6 these days ;-) I know the code doesn't always do it but when we move it we could clean that up.

1147

Those probably should be resolved or removed?

sbin/setkey/setkey.8

32 ↗

(On Diff #122510)

.Dd update before commit

[kib]

In D40300#917678, @bz wrote:

Can you please add details (a proposed commit message) as that might shed light onto why you may think this is needed/useful?

This is needed to properly test IPSEC+NAT-T hardware offload. (I do not think that mentioning this in commit message is too useful).

[kib]

Handle bz' comments.

[bz]

In D40300#917683, @kib wrote:

In D40300#917678, @bz wrote:

Can you please add details (a proposed commit message) as that might shed light onto why you may think this is needed/useful?

This is needed to properly test IPSEC+NAT-T hardware offload. (I do not think that mentioning this in commit message is too useful).

I think the reason WHY a change is done is super useful in a commit message. And thanks for explaining as "testing" was literally the only thing I could think off why this change could be needed. I'll try and see if I can do a more thorough review if noone else beats me to it.

In general I am fine adding the functionality.

[ae]

LGTM. Do you plan to implement NAT_T_FRAG in kernel somehow?

[kib]

In D40300#917875, @ae wrote:

LGTM. Do you plan to implement NAT_T_FRAG in kernel somehow?

Somehow, might be. So far it was a possibility that we need this for our offload work, so I implemented it in advance.