IPSEC_NAT_T for FAST_IPSEC

[d***@netbsd.org]

Hi

I have finished to add support of IPSEC_NAT_T for FAST_IPSEC. Tke key
management part is more or less directly taken from manu@ work so most of
congrats is for him :D

Can you review the following patch and if possible test it on a real
configuration (I have done some tests but only on virtual networks).

If nobody object, I will commit it next week.

[Izumi Tsutsui]

Post by d***@netbsd.org
Can you review the following patch

Just only cosmetic part:
- ANSI style function declarations are better
- no need __P() at least for new functions
- memset() rather than bzero()
- IPSEC_NAT_T option should be defflag'ed in files.netipsec?
- I wonder if some pointer casts might cause problems
on gcc -fstrict-aliasing

---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Izumi Tsutsui]

Post by Izumi Tsutsui
- ANSI style function declarations are better
- no need __P() at least for new functions
- memset() rather than bzero()

I tried to stay coherent with the current code. In a secund time, I plan to
ansify all the key management code.

Okay, I'll leave them to maintainers.

Post by Izumi Tsutsui
- IPSEC_NAT_T option should be defflag'ed in files.netipsec?

It is already defflag'ed in files.ipsec so I can't defined another time in
files.netipsec.

Ah, I didn't notice netinet6/files.ipsec...
(BTW, can options IPSEC_NAT_T be defined without options INET6?)

Post by Izumi Tsutsui
- I wonder if some pointer casts might cause problems
on gcc -fstrict-aliasing

I have ran my test with kernel compiled with -O2. From the documentation,
-O2 enables -fstrict-aliasing and I didn't notice any strange things.

src/sys/conf/Makefile.kern.inc has "CFLAGS+= -fno-strict-aliasing"
so currently we won't have any problem on our kernel, but it might
be better to confirm C99 restriction in newer code.
(though other our code might have the similar problems anyway)
---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[d***@netbsd.org]

Post by Izumi Tsutsui

- ANSI style function declarations are better - no need __P() at
least for new functions - memset() rather than bzero()

I tried to stay coherent with the current code. In a secund time, I
plan to ansify all the key management code.

Okay, I'll leave them to maintainers.

- IPSEC_NAT_T option should be defflag'ed in files.netipsec?

It is already defflag'ed in files.ipsec so I can't defined another time
in files.netipsec.

Ah, I didn't notice netinet6/files.ipsec... (BTW, can options
IPSEC_NAT_T be defined without options INET6?)

Of course, we can use IPSEC_NAT_T (and IPSEC) without INET6. IPSEC
implementation comes from KAME and I suppose they added all their files
into netinet6.

[d***@netbsd.org]

Post by Izumi Tsutsui

Post by d***@netbsd.org
Can you review the following patch

- ANSI style function declarations are better
- no need __P() at least for new functions
- memset() rather than bzero()

I tried to stay coherent with the current code. In a secund time, I plan to
ansify all the key management code.

Post by Izumi Tsutsui
- IPSEC_NAT_T option should be defflag'ed in files.netipsec?

It is already defflag'ed in files.ipsec so I can't defined another time in
files.netipsec.

Post by Izumi Tsutsui
- I wonder if some pointer casts might cause problems
on gcc -fstrict-aliasing

I have ran my test with kernel compiled with -O2. From the documentation,
-O2 enables -fstrict-aliasing and I didn't notice any strange things.