ipv6 source address selection

[Ignatios Souvatzis]

How can I influence the source address used on a socket if the application
doesn't set one?

(I'm playing with a multicast ipv6-in-ipv6 tunnel; and the address used
for that gets preferred to the 'real' address so that I can't connect
to work any longer...)

OS is 3.0 currently; moving to 4.0 soon.

-is

[JINMEI Tatuya / 神明達哉]

At Fri, 21 Sep 2007 14:21:19 +0200,

Post by Ignatios Souvatzis
How can I influence the source address used on a socket if the application
doesn't set one?
(I'm playing with a multicast ipv6-in-ipv6 tunnel; and the address used
for that gets preferred to the 'real' address so that I can't connect
to work any longer...)
OS is 3.0 currently; moving to 4.0 soon.

I don't understand the question. Could you be more specific?

JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
***@isl.rdc.toshiba.co.jp

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

[Pavel Cahyna]

Post by Ignatios Souvatzis
How can I influence the source address used on a socket if the application
doesn't set one?
(I'm playing with a multicast ipv6-in-ipv6 tunnel; and the address used
for that gets preferred to the 'real' address so that I can't connect
to work any longer...)
OS is 3.0 currently; moving to 4.0 soon.

Would the "deprecated" keyword of ifconfig help you?

Pavel

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

[Michael van Elst]

Post by Pavel Cahyna

Post by Ignatios Souvatzis
How can I influence the source address used on a socket if the application
doesn't set one?

Would the "deprecated" keyword of ifconfig help you?

He is probably looking for the IPSELSRC equivalent for IPv6.

[Alan Barrett]

Post by JINMEI Tatuya / 神明達哉

Post by Ignatios Souvatzis
How can I influence the source address used on a socket if the application
doesn't set one?

I don't understand the question. Could you be more specific?

I think he's looking for NetBSD's nonexistent implementation of RFC 3484,
and the associated policy table.

--apb (Alan Barrett)

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

[Ignatios Souvatzis]

Post by Pavel Cahyna

Post by Ignatios Souvatzis
How can I influence the source address used on a socket if the application
doesn't set one?
(I'm playing with a multicast ipv6-in-ipv6 tunnel; and the address used
for that gets preferred to the 'real' address so that I can't connect
to work any longer...)
OS is 3.0 currently; moving to 4.0 soon.

Would the "deprecated" keyword of ifconfig help you?

To a certain degree - it passes the quick test (don't know why it didn't
work the first time). Lets see whether it's enough for the real application.

-is

[Ignatios Souvatzis]

Post by Michael van Elst

Post by Pavel Cahyna

Post by Ignatios Souvatzis
How can I influence the source address used on a socket if the application
doesn't set one?

Would the "deprecated" keyword of ifconfig help you?

He is probably looking for the IPSELSRC equivalent for IPv6.

Hm.... right.

-is

[Michael van Elst]

At Mon, 24 Sep 2007 11:45:55 +0200,

Post by Ignatios Souvatzis

Post by Michael van Elst

Post by Pavel Cahyna

Post by Ignatios Souvatzis
How can I influence the source address used on a socket if the application
doesn't set one?

Would the "deprecated" keyword of ifconfig help you?

He is probably looking for the IPSELSRC equivalent for IPv6.

Hm.... right.

I didn't know IPSELSRC, but does the source address selection
mechanism based on RFC3484 satisfy your need? The (current) NetBSD
kernel already supports the framework, although the configuration tool
(called ip6addrctl in FreeBSD) seems to be missing.

If I read RFC3484 correctly you can configure a 'policy table'
with a best precedence value assigned to the single IP address
that you want to use when talking to some network by giving the
single address and the network the same distinguished label.

That seems to be sufficient.

Is the RFC3484 support implemented for KAME and for FAST_IPSEC?

Greetings,

[David Young]

Post by Michael van Elst

At Mon, 24 Sep 2007 11:45:55 +0200,

Post by Ignatios Souvatzis

Post by Michael van Elst

Post by Pavel Cahyna

Post by Ignatios Souvatzis
How can I influence the source address used on a socket if the application
doesn't set one?

Would the "deprecated" keyword of ifconfig help you?

He is probably looking for the IPSELSRC equivalent for IPv6.

Hm.... right.

I didn't know IPSELSRC, but does the source address selection
mechanism based on RFC3484 satisfy your need? The (current) NetBSD
kernel already supports the framework, although the configuration tool
(called ip6addrctl in FreeBSD) seems to be missing.

If I read RFC3484 correctly you can configure a 'policy table'
with a best precedence value assigned to the single IP address
that you want to use when talking to some network by giving the
single address and the network the same distinguished label.
That seems to be sufficient.
Is the RFC3484 support implemented for KAME and for FAST_IPSEC?

IMO the best way to provide RFC3484 support is to adapt IPSELSRC for the
purpose, so that we do not have two entirely different policy mechanisms
for source selection, and all of the kernel bloat and operator confusion
that entails.

Conceptually, IPSELSRC is at least powerful enough to express
RFC3484-style source-selection rules, which is all that the RFC requires.

Dave

[Michael van Elst]

I don't understand how the (FAST_)IPSEC implementation relates to
RFC3484, but I don't know the answer anyway.

There shouldn't be any relation. I was just asking because I
don't know how much FAST_IPSEC interferes with the IPv6 code.

[Michael van Elst]

Perhaps you meant to say you don't know how much FAST_IPSEC interferes
with the *KAME* IPv6 code.

Is there any other IPv6 code in the kernel?

I wanted to know wether the NetBSD kernel supports RFC3484 when I
build it with the FAST_IPSEC option.

Currently FAST_IPSEC supports IPv6, but I don't know what part
of KAME IPv6 it interferes with. The source suggests that it
only replaces the IPSEC related parts.

[Stone]

[...]

Post by Michael van Elst
I wanted to know wether the NetBSD kernel supports RFC3484 when I
build it with the FAST_IPSEC option.

I have no idea. The FAST_IPSEC in released versions of NetBSD
used to not work with IPv6 at all. If you try to configure
Ipv6 and FAST_IPSEC, you used to get a panic.

I beleive the NetSBD-4 branch contains some small kludges which
allows FAST_IPSEC and IPv6 to coexist at compile-time. But the
last time I remember trying, sending an IPsec'ed IPv6 packe to
such a kernel would cause a panic.

Post by Michael van Elst
Currently FAST_IPSEC supports IPv6, but I don't know what part
of KAME IPv6 it interferes with. The source suggests that it
only replaces the IPSEC related parts.

The intent was to replace only the IPsec portions of KAME's Ipv6.
But I have no idea what heppens in -current with IPv6 and FAST_IPSEC.

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

[Arnaud Degroote]

Post by Stone
[...]

Post by Michael van Elst
I wanted to know wether the NetBSD kernel supports RFC3484 when I
build it with the FAST_IPSEC option.

I have no idea. The FAST_IPSEC in released versions of NetBSD
used to not work with IPv6 at all. If you try to configure
Ipv6 and FAST_IPSEC, you used to get a panic.
I beleive the NetSBD-4 branch contains some small kludges which
allows FAST_IPSEC and IPv6 to coexist at compile-time. But the
last time I remember trying, sending an IPsec'ed IPv6 packe to
such a kernel would cause a panic.

In NetBSD-4, you can use FAST_IPSEC and IPv6. I have pullup most of the
current change into NetBSD-4 a long time ago. There are still some
issues in the implementation (the implementation doesn't work correctly
with extension header in transport mode). Of course, the code needs to
be tested, tested and retested in real configuration and I wait for any
feedback good or bad :).

[j***@dsg.stanford.edu]

Post by Arnaud Degroote
In NetBSD-4, you can use FAST_IPSEC and IPv6. I have pullup most of the
current change into NetBSD-4 a long time ago. There are still some
issues in the implementation (the implementation doesn't work correctly
with extension header in transport mode). Of course, the code needs to
be tested, tested and retested in real configuration and I wait for any
feedback good or bad :).

Thanks for the update and correction.

Are there other known gotchas besides the extension header in
transport mode? Any Big/little endian issues? I ask because one way
to get the testing would be to get people turning on FAST_IPSEC in
-current.

There has also been talk of turning on FAST_IPSEC by default. But the
consensus was that before doing that, we should measure send and
receive packet rates both with and without IPsec configured; and make
sure there's negligible difference in packet rates. (On a CPU-limited
or memory-limited system, needless to say. send/receive rates on
10GbE would be one interesting way to measure :-))


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

[Arnaud Degroote]

Post by j***@dsg.stanford.edu

Post by Arnaud Degroote
In NetBSD-4, you can use FAST_IPSEC and IPv6. I have pullup most of the
current change into NetBSD-4 a long time ago. There are still some
issues in the implementation (the implementation doesn't work correctly
with extension header in transport mode). Of course, the code needs to
be tested, tested and retested in real configuration and I wait for any
feedback good or bad :).

Thanks for the update and correction.
Are there other known gotchas besides the extension header in
transport mode? Any Big/little endian issues? I ask because one way
to get the testing would be to get people turning on FAST_IPSEC in
-current.

For moment, I only have tested on le boxes. I will try to find a sparc64
box to test FAST_IPSEC. There are still some pr about FAST_IPSEC but I
hope that I can fix most of them before NetBSD-4.

I think we will get more feedback when NetBSD-4 will be released (and it
is the reason why I pulled the IPv6 changes in NetBSD-4). I don't think
IPSEC is really used by developpers on current.

Post by j***@dsg.stanford.edu
There has also been talk of turning on FAST_IPSEC by default. But the
consensus was that before doing that, we should measure send and
receive packet rates both with and without IPsec configured; and make
sure there's negligible difference in packet rates. (On a CPU-limited
or memory-limited system, needless to say. send/receive rates on
10GbE would be one interesting way to measure :-))

There are two questions :
- can we replace Kame IPSEC by FAST_IPSEC (and so drop Kame IPSEC from
src). I think FAST_IPSEC is not far from Kame IPSEC about features
(-current has IPSEC_NAT_T support for FAST_IPSEC for example). But
the FAST_IPSEC stack need to be more used/tested for that.

- can we enable FAST_IPSEC in GENERIC ? What is the impact on kernel
size and on the performance of network stack. I will do some
benchmarks later but for moment, I prefer focussing on bug fixes.
We have time before 5.0 ... :)

Bests,

[Christos Zoulas]

Post by Arnaud Degroote

Post by j***@dsg.stanford.edu

Post by Arnaud Degroote
In NetBSD-4, you can use FAST_IPSEC and IPv6. I have pullup most of the
current change into NetBSD-4 a long time ago. There are still some
issues in the implementation (the implementation doesn't work correctly
with extension header in transport mode). Of course, the code needs to
be tested, tested and retested in real configuration and I wait for any
feedback good or bad :).

Thanks for the update and correction.
Are there other known gotchas besides the extension header in
transport mode? Any Big/little endian issues? I ask because one way
to get the testing would be to get people turning on FAST_IPSEC in
-current.

For moment, I only have tested on le boxes. I will try to find a sparc64
box to test FAST_IPSEC. There are still some pr about FAST_IPSEC but I
hope that I can fix most of them before NetBSD-4.
I think we will get more feedback when NetBSD-4 will be released (and it
is the reason why I pulled the IPv6 changes in NetBSD-4). I don't think
IPSEC is really used by developpers on current.

Post by j***@dsg.stanford.edu
There has also been talk of turning on FAST_IPSEC by default. But the
consensus was that before doing that, we should measure send and
receive packet rates both with and without IPsec configured; and make
sure there's negligible difference in packet rates. (On a CPU-limited
or memory-limited system, needless to say. send/receive rates on
10GbE would be one interesting way to measure :-))

- can we replace Kame IPSEC by FAST_IPSEC (and so drop Kame IPSEC from
src). I think FAST_IPSEC is not far from Kame IPSEC about features
(-current has IPSEC_NAT_T support for FAST_IPSEC for example). But
the FAST_IPSEC stack need to be more used/tested for that.

I think that we should. There is little to gain by supporting 2 different
IPSEC stacks and there is the cost of maintaining them.

Post by Arnaud Degroote
- can we enable FAST_IPSEC in GENERIC ? What is the impact on kernel
size and on the performance of network stack. I will do some
benchmarks later but for moment, I prefer focussing on bug fixes.
We have time before 5.0 ... :)

There were two reasons for not enabling IPSEC in generic.
1. performance. It would be nice to have a flag to globally enable or disable
it, so that the ip path does not slow down a lot when IPSEC is enabled but
there are no IPSEC policies.
2. the crypto/export issues. I don't think that this is an issue anymore.

christos


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

[Geert Hendrickx]

Post by Christos Zoulas
There were two reasons for not enabling IPSEC in generic.
1. performance. It would be nice to have a flag to globally enable or
disable it, so that the ip path does not slow down a lot when IPSEC is
enabled but there are no IPSEC policies.
2. the crypto/export issues. I don't think that this is an issue anymore.

3. (not really a big issue) it breaks userland IPSec implementations like
for example pkgsrc/net/vpnc.

Geert



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

[Jonathan Stone]

Post by Michael van Elst

I don't understand how the (FAST_)IPSEC implementation relates to
RFC3484, but I don't know the answer anyway.

There shouldn't be any relation. I was just asking because I
don't know how much FAST_IPSEC interferes with the IPv6 code.

Perhaps you meant to say you don't know how much FAST_IPSEC interferes
with the *KAME* IPv6 code.

In practice, the choice is a config-time choice between one or the
other. NetBSD's stated plan is that the KAME code will be deprecated
once FAST_IPSEC supports IPv6 and can functionally replace the KAME
Ipv6 code. I don't use IPv6, so can't speak to where the SoC project
reached that milestone or not.

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

[JINMEI Tatuya / 神明達哉]

At Tue, 25 Sep 2007 13:55:26 -0700,

Post by Michael van Elst

I don't understand how the (FAST_)IPSEC implementation relates to
RFC3484, but I don't know the answer anyway.

There shouldn't be any relation. I was just asking because I
don't know how much FAST_IPSEC interferes with the IPv6 code.

Perhaps you meant to say you don't know how much FAST_IPSEC interferes
with the *KAME* IPv6 code.
In practice, the choice is a config-time choice between one or the
other. NetBSD's stated plan is that the KAME code will be deprecated
once FAST_IPSEC supports IPv6 and can functionally replace the KAME
Ipv6 code. I don't use IPv6, so can't speak to where the SoC project
reached that milestone or not.

For what it's worth, FreeBSD has adapted its FAST_IPSEC for KAME-based
IPv6 stack and effectively deprecated the KAME-based IPsec
implementation. It may be of interest for NetBSD developers.

JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
***@isl.rdc.toshiba.co.jp

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

[JINMEI Tatuya / 神明達哉]

At Mon, 24 Sep 2007 11:45:55 +0200,

Post by Ignatios Souvatzis

Post by Michael van Elst

Post by Pavel Cahyna

Post by Ignatios Souvatzis
How can I influence the source address used on a socket if the application
doesn't set one?

Would the "deprecated" keyword of ifconfig help you?

He is probably looking for the IPSELSRC equivalent for IPv6.

Hm.... right.

I didn't know IPSELSRC, but does the source address selection
mechanism based on RFC3484 satisfy your need? The (current) NetBSD
kernel already supports the framework, although the configuration tool
(called ip6addrctl in FreeBSD) seems to be missing.

JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
***@isl.rdc.toshiba.co.jp

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

[JINMEI Tatuya / 神明達哉]

At Tue, 25 Sep 2007 07:21:29 +0200,

Post by Michael van Elst

I didn't know IPSELSRC, but does the source address selection
mechanism based on RFC3484 satisfy your need? The (current) NetBSD
kernel already supports the framework, although the configuration tool
(called ip6addrctl in FreeBSD) seems to be missing.

If I read RFC3484 correctly you can configure a 'policy table'
with a best precedence value assigned to the single IP address
that you want to use when talking to some network by giving the
single address and the network the same distinguished label.

That's correct.

Post by Michael van Elst
That seems to be sufficient.
Is the RFC3484 support implemented for KAME and for FAST_IPSEC?

For KAME, yes. And as I explained in the previous message, the kernel
part implementation has already been incorporated to the NetBSD kernel.
The only missing part is the userland utility (ip6addrctl), which is
available in KAME snapshots and should be easily merged to NetBSD.

I don't understand how the (FAST_)IPSEC implementation relates to
RFC3484, but I don't know the answer anyway.


JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
***@isl.rdc.toshiba.co.jp

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