[Swan-dev] More confusion of options to clean up regarding phase1 and phase2 options
paul at nohats.ca
Tue Apr 22 04:46:04 EEST 2014
On Sun, 20 Apr 2014, D. Hugh Redelmeier wrote:
> I'll say it again, perhaps more clearly:
> I'm willing to work on the parsing, but I'd like clear and accurate
> explanation of what we (think) the syntax is now. I don't really want
> to have to infer it from the code.
> It would be great to know what people actually use (i.e. what not to
> break). Oh, and what has been documented.
> That's the starting point.
> The next step would be a proposed rational design.
I have started to add legitimate cases into testing/lib/libpluto/algparse.c
including ones that should get rejected (marked as such)
This should be extended to cover more.
> All that is useful, but since I don't know what exists, I don't really
> understand what that list means.
> Let me emphasize: talking about it is important, especially for
> user-visible changes. And accurate documentation needs to be a higher
Agreed. the man pages _must_ match the implementation, always.
> The serious mess of natt-related options ought to be cleaned up too.
> Now, while I remember how the option handling works. But first, I
> would like to clearly know which options are actually important and
All of them? I'm not sure which you are referring to. The NAT options
were mostly added for people to work around some kind of deployment
ikev1_natt - work around bugs in RFC NATT implementation in certain Cisco firmware
nat_keepalive - people on bad links like to disable this (arguably unwise)
(bool, suggested to turn into a time field - see below)
force_keepalive - obsoleted already
nat_traversal - obsoleted already
disable_port_floating - obsoleted already
nat_ikeport - work around UDP 4500 blocks
keep_alive - should become per-connection (talk of merging with nat_keepalive)
virtual_private - required by everyone
> I'm still wondering about nat- vis natt-.
In the above the only "natt-" one is ikev1_natt. It specifically refers
to which nat-traversal payloads to send. The rest deals with nat, so
relates to natt. I'm okay with renaming it, although it makes sense as
it. (to me, but I also made the keyword up in the first place)
More information about the Swan-dev