Hello Alexey, Dave, everyone,
We are resending our code for kernel inclusion consideration. I hope
with this submission we have addressed all the concerns raised on the
list (i.e. draft revision) as well as offline (splitting the patch to
smaller chunks).
To Pekka and Hideaki,
Intermediate revision of the specification "Draft 18++" appeared a few
days ago, which addressed most of the issues with earlier drafts (16,
17, 18). This made it possible to update our code to something usable
(later than 15). This patch set has support for most of it.
To Alexey, (and everyone else)
The patch has been split for easier reading as follows:
ipv6_tunnel.patch 6over6 tunneling
network_mods.patch Modifications to network code and hooks
mipv6_cn_support.patch Correspondent node support (+common code)
mipv6_mn_support.patch Mobile node support (+common code with HA)
mipv6_ha_support.patch Home agent support
The patches are incremental, so they must be applied in this order.
Patches are not included in this mail, but you can find them at:
http://www.mipl.mediapoli.com/patches/ipv6_tunnel.patch
http://www.mipl.mediapoli.com/patches/network_mods.patch
http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch
http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch
http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch
Userspace tools are available at:
http://www.mipl.mediapoli.com/download/mipv6-tools/
Regards,
Antti
--
Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland.
Research assistant, Institute of Digital Communications at HUT
work: [email protected]; home: [email protected]
In article <[email protected]> (at Thu, 17 Oct 2002 19:26:25 +0300), Antti Tuominen <[email protected]> says:
> The patch has been split for easier reading as follows:
>
> ipv6_tunnel.patch 6over6 tunneling
> network_mods.patch Modifications to network code and hooks
Several comments.
[ipv6_tunnel]
I think this is almost ok.
1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/.
2. Please put outer address to hardware address in dev.
Note: you need to modify SIOxxx ioctls too not to overrun!
[network_mods etc.]
1. Too many hooks,
and many duplicate codes in ipv6 stack and mipv6 stack.
(prefix handler, header parser, ndisc handler etc...)
more comment will come later...
> http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch
> http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch
> http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch
Well, I can't find them. I hope they'll be available when I wake up
tomorrow...
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
> > http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch
> > http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch
> > http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch
>
> Well, I can't find them. I hope they'll be available when I wake up
> tomorrow...
Just replace "_" with "-".
- KK
YOSHIFUJI Hideaki
/ $B5HF#1QL@(B To: [email protected]
<yoshfuji@linux-i cc: [email protected], [email protected], [email protected],
pv6.org> [email protected], [email protected], [email protected], Venkata
Sent by: Jagana/Beaverton/IBM@IBMUS, [email protected]
netdev-bounce@oss Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43
.sgi.com
10/17/2002 10:18
AM
In article <[email protected]> (at Thu, 17 Oct
2002 19:26:25 +0300), Antti Tuominen <[email protected]> says:
> The patch has been split for easier reading as follows:
>
> ipv6_tunnel.patch 6over6 tunneling
> network_mods.patch Modifications to network code and hooks
Several comments.
[ipv6_tunnel]
I think this is almost ok.
1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/.
2. Please put outer address to hardware address in dev.
Note: you need to modify SIOxxx ioctls too not to overrun!
[network_mods etc.]
1. Too many hooks,
and many duplicate codes in ipv6 stack and mipv6 stack.
(prefix handler, header parser, ndisc handler etc...)
more comment will come later...
> http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch
> http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch
> http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch
Well, I can't find them. I hope they'll be available when I wake up
tomorrow...
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
Hi yoshifuji,
> [network_mods etc.]
>
> 1. Too many hooks,
> and many duplicate codes in ipv6 stack and mipv6 stack.
> (prefix handler, header parser, ndisc handler etc...)
What do you mean about having too many hooks ? Eg. prefix handler, you need
to have a hook in the receive of router advertisement to do this. This is
minimum hooks :-). Also, some of the ndisc handlers evaluate to NULL code
for both regular IPv6 code (unless you have configured mobility) as well as
some components of Mobile IPv6. Eg ndisc_mipv6_mn_solicit_ha() evaluates to
NULL on HA and CN, but is a function call on every MN node. So I don't
understand your concern here.
Thanks,
- KK
YOSHIFUJI Hideaki
/ $B5HF#1QL@(B To: [email protected]
<yoshfuji@linux-i cc: [email protected], [email protected], [email protected],
pv6.org> [email protected], [email protected], [email protected], Venkata
Sent by: Jagana/Beaverton/IBM@IBMUS, [email protected]
netdev-bounce@oss Subject: Re: [PATCHSET] Mobile IPv6 for 2.5.43
.sgi.com
10/17/2002 10:18
AM
In article <[email protected]> (at Thu, 17 Oct
2002 19:26:25 +0300), Antti Tuominen <[email protected]> says:
> The patch has been split for easier reading as follows:
>
> ipv6_tunnel.patch 6over6 tunneling
> network_mods.patch Modifications to network code and hooks
Several comments.
[ipv6_tunnel]
I think this is almost ok.
1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/.
2. Please put outer address to hardware address in dev.
Note: you need to modify SIOxxx ioctls too not to overrun!
[network_mods etc.]
1. Too many hooks,
and many duplicate codes in ipv6 stack and mipv6 stack.
(prefix handler, header parser, ndisc handler etc...)
more comment will come later...
> http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch
> http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch
> http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch
Well, I can't find them. I hope they'll be available when I wake up
tomorrow...
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
> > The patch has been split for easier reading as follows:
> >
> > ipv6_tunnel.patch 6over6 tunneling
> > network_mods.patch Modifications to network code and hooks
>
> Several comments.
>
> [ipv6_tunnel]
>
> I think this is almost ok.
I think so.
I know ipv6_tunnel is stable as I use.
>
> 1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/.
> 2. Please put outer address to hardware address in dev.
> Note: you need to modify SIOxxx ioctls too not to overrun!
plus:
(maybe not whole kernel issue)
It is important to integrate your ipv6tunnel command into ifconfig(8) and/or ip(8).
Regards,
-mk
On Thu, 17 Oct 2002, Antti Tuominen wrote:
> Intermediate revision of the specification "Draft 18++" appeared a few
> days ago, which addressed most of the issues with earlier drafts (16,
> 17, 18). This made it possible to update our code to something usable
> (later than 15). This patch set has support for most of it.
Sounds great. Hopefully it slows down a bit from being a moving target.
> To Alexey, (and everyone else)
>
> The patch has been split for easier reading as follows:
>
> ipv6_tunnel.patch 6over6 tunneling
> network_mods.patch Modifications to network code and hooks
> mipv6_cn_support.patch Correspondent node support (+common code)
> mipv6_mn_support.patch Mobile node support (+common code with HA)
> mipv6_ha_support.patch Home agent support
I didn't look at these that much, but I'll make two generic observations:
1) current tunneling (including sanity checks which are, I believe, a bit
non-existant at the moment) should be generalized to handle v6-in-v6 and
v6-in-v4 tunneling anyway. Not sure if this is the right way, but that's
IMO one priority item.
2) without IPSEC, there is no way to secure MN-HA traffic. Therefore I
think the first priority is being able to support Correspondent Node
behaviour.
I belive Alexey, Davem et al are best to justify whether this feels like a
right approach.
Having IPSEC + MIPv6 in 2.6 series would be Really Cool, though :-)
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
On Thu, 17 Oct 2002, Krishna Kumar wrote:
>
> > > http://www.mipl.mediapoli.com/patches/mipv6_cn_support.patch
> > > http://www.mipl.mediapoli.com/patches/mipv6_mn_support.patch
> > > http://www.mipl.mediapoli.com/patches/mipv6_ha_support.patch
> >
> > Well, I can't find them. I hope they'll be available when I wake up
> > tomorrow...
>
> Just replace "_" with "-".
>
> - KK
Thanks Krishna and yoshifuji!
The files are now renamed properly.
- Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: [email protected], phone: +358 (0)9 451 5257
On Thu, 17 Oct 2002, Antti Tuominen wrote:
> Userspace tools are available at:
> http://www.mipl.mediapoli.com/download/mipv6-tools/
There was a file missing from the original package, so please download
the updated version.
-Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: [email protected], phone: +358 (0)9 451 5257
On Fri, 18 Oct 2002, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:
> In article <[email protected]> (at Thu, 17 Oct 2002 19:26:25 +0300), Antti Tuominen <[email protected]> says:
>
> [ipv6_tunnel]
>
> I think this is almost ok.
>
> 1. I believe s/ARPHRD_IPV6_IPV6_TUNNEL/ARPHRD_TUNNEL6/.
Ok by me! The comment of course says IPIP6 tunnel at the moment, but the
constant itself doesn't appear to be used anywhere.
> 2. Please put outer address to hardware address in dev.
The reason I haven't done this is that MAX_ADDR_LEN is just 8. Does anyone
have any objections against changing the value to 16?
> Note: you need to modify SIOxxx ioctls too not to overrun!
Sorry, I'm not that familiar with ioctls, I just copied the basic
functionality from sit.c. Could you explain it a bit more thoroughly, so
even I with my thick skull understand what the problem is?
-Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: [email protected], phone: +358 (0)9 451 5257
In article <[email protected]> (at Fri, 18 Oct 2002 02:52:48 +0300 (EEST)), Ville Nuorvala <[email protected]> says:
> > 2. Please put outer address to hardware address in dev.
>
> The reason I haven't done this is that MAX_ADDR_LEN is just 8. Does anyone
> have any objections against changing the value to 16?
>
> > Note: you need to modify SIOxxx ioctls too not to overrun!
>
> Sorry, I'm not that familiar with ioctls, I just copied the basic
> functionality from sit.c. Could you explain it a bit more thoroughly, so
> even I with my thick skull understand what the problem is?
in net/core/dev.c, there're codes to copy between dev->dev_{addr,broadcast}
and ifr_hwaddr.sa_data (points sockaddr{} sized 16).
Well, we have code for it. :-)
Please look at
<http://www2.linux-ipv6.org/cvsweb/usagi/kernel/linux24/net/core/dev.c.diff?r1=1.1.1.12&r2=1.4>
BTW, why don't we have SIOCGIFHWBROADCAST??
--
Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
On Thu, Oct 17, 2002 at 11:14:32PM +0300, Pekka Savola wrote:
> On Thu, 17 Oct 2002, Antti Tuominen wrote:
> > Intermediate revision of the specification "Draft 18++" appeared a few
> > days ago, which addressed most of the issues with earlier drafts (16,
>
> Sounds great. Hopefully it slows down a bit from being a moving target.
I heard Draft 19 should be out next week, so that should consolidate
the MIPv6 effort even further.
> 1) current tunneling (including sanity checks which are, I believe, a bit
> non-existant at the moment) should be generalized to handle v6-in-v6 and
> v6-in-v4 tunneling anyway. Not sure if this is the right way, but that's
> IMO one priority item.
I'm sure we can improve the v6-in-v6 tunnel. We had some discussion
with USAGI people about doing anything-in-v6 general tunnel, but since
that is somewhat beyond our project scope, v6-in-v6 is all we can
offer at this time. I don't know about the USAGI folks' status on
this.
> 2) without IPSEC, there is no way to secure MN-HA traffic. Therefore I
> think the first priority is being able to support Correspondent Node
> behaviour.
Right. We've had our own IPSec AH support in all the previous
releases, but as everyone probably knows the USAGI guys have
implemented IPv6 IPSec. This is why we dropped the IPSec stuff in our
code. There is no point doing the same work again. If (or when)
USAGI IPSec gets accepted to the kernel, we will be sure to modify our
code to support it.
> Having IPSEC + MIPv6 in 2.6 series would be Really Cool, though :-)
This is something we're hoping for too.
Regards,
Antti
--
Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland.
Research assistant, Institute of Digital Communications at HUT
work: [email protected]; home: [email protected]
On Fri, Oct 18, 2002 at 02:56:33AM +0900, Mitsuru KANDA wrote:
> > [ipv6_tunnel]
> >
> > I think this is almost ok.
> I think so.
> I know ipv6_tunnel is stable as I use.
Thanks for the vote of confidence :)
> plus:
> (maybe not whole kernel issue)
> It is important to integrate your ipv6tunnel command into
> ifconfig(8) and/or ip(8).
Obviously we will provide patches to add that functionality to ip (and
maybe also ifconfig), if the code goes into the kernel.
Regards,
Antti
--
Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland.
Research assistant, Institute of Digital Communications at HUT
work: [email protected]; home: [email protected]
In article <[email protected]> (at Thu, 31 Oct 2002 10:55:56 +0200 (EET)), Pekka Savola <[email protected]> says:
> > (7) Source Address Selection of MN
> > When host acts as MN, your implementation always select HoA as the
> > source address. The source address should be a CoA.
>
> No, draft-ietf-ipv6-default-addr-select-09.txt Rule 4 says home addresses
> should be preferred, except via a possible API interaction.
Yes, we know.
What we meant was there are some cases that we need to use actual
address on the device, not HoA.
---yoshfuji
On Thu, 31 Oct 2002, Noriaki Takamiya wrote:
> (2) Avoiding Netfilter Hooks
> In your imprementation HA uses netfilter to intercept packets
> sent to MN. We think it is costy so we have a suggestion to
> use FIB structure to forward packets to MN. Bacause we think
> forwarding packets from HA to MN is FORWARDING, not FILTERING.
> We think the kernel maintainers may prefer such a manner using
> FIB structure for forwarding.
Sounds sensible.
> (7) Source Address Selection of MN
> When host acts as MN, your implementation always select HoA as the
> source address. The source address should be a CoA.
No, draft-ietf-ipv6-default-addr-select-09.txt Rule 4 says home addresses
should be preferred, except via a possible API interaction.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Hi,
This is Takamiya, a member of USAGI Project.
Your work is very cool. However, we believe there are several
issues on direction / design and behavior in your implementation.
Please note that we're preparing for checking to what extent this
patch is compliant to the Internet draft of MIPv6.
So we may comment other things later.
(1) About MIPV6CALLFUNC and MIPV6CALLPROC
It is reasonable to use these macros for modularized
functions. But the current your implementation needs to select
HA or MN when compiling the kernel. So, it doesn't seems to be
needed this macros, and the real function may be called
directly. How about this?
Rather, how about using sysctl and so on to switch the
functionality?
(2) Avoiding Netfilter Hooks
In your imprementation HA uses netfilter to intercept packets
sent to MN. We think it is costy so we have a suggestion to
use FIB structure to forward packets to MN. Bacause we think
forwarding packets from HA to MN is FORWARDING, not FILTERING.
We think the kernel maintainers may prefer such a manner using
FIB structure for forwarding.
(3) Binding Cache
We think it is reasonable way to use FIB structure to holding
Binding Cache Entries if you us FIB structure for forwarding
packets from HA to MN as we suggested (4).
(4) Processing Mobility Header
How about using ip6_txoptions and hdrproc_lst?
Because Mobility header is an extension header, we think it is
reasonable way to handle it in ipv6_parse_exthdrs().
(5) How about using CryptoAPI?
CryptoAPI is merged to mainline.
We believe we can use the CryptoAPI for caluculating cookies
of RR. How do you think about this?
(6) Order of HAO and Routing header
When MN acts also as CN, the order doesn't seems to be
compliant to ID-18 in the implementation. The order will be
the following:
[IPv6][HAO][RT2]
I-D says:
[IPv6][RT2][HAO]
(7) Source Address Selection of MN
When host acts as MN, your implementation always select HoA as the
source address. The source address should be a CoA.
Regards,
--
Noriaki Takamiya
Hi Noriaki,
On Thu, 31 Oct 2002, Noriaki Takamiya wrote:
> Hi,
>
> This is Takamiya, a member of USAGI Project.
> Your work is very cool.
Thanks.
>
> Please note that we're preparing for checking to what extent this
> patch is compliant to the Internet draft of MIPv6.
We are interested in seeing the results, especially if the tests are based
on the draft19, which ought to be published soon based on the discussions
in the mobile-ip mailing list.
>
> (2) Avoiding Netfilter Hooks
> In your imprementation HA uses netfilter to intercept packets
> sent to MN. We think it is costy so we have a suggestion to
> use FIB structure to forward packets to MN. Bacause we think
> forwarding packets from HA to MN is FORWARDING, not FILTERING.
> We think the kernel maintainers may prefer such a manner using
> FIB structure for forwarding.
We are using standard routing in HA to route packets intercepted by HA to
MN through a tunnel device. However, HA needs to also act as a neighbor
discovery proxy for MN and not tunnel any ND packets destined to MN, but
reply to them on the bahalf of MN. We use the netfilter hook to check for
ND packets with global addresses that would be otherwise tunneled and feed
them directly to the local processing code.
Thanks,
Henrik Petander
----------------------------------
Henrik Petander
Helsinki University of Technology,
GO/Core Project
[email protected]
Office: +358 (0)9 451 5846
GSM: +358 (0)40 741 5248
----------------------------------
On Thu, Oct 31, 2002 at 05:44:42PM +0900, Noriaki Takamiya wrote:
> Hi,
Hello Takamiya,
> Please note that we're preparing for checking to what extent this
> patch is compliant to the Internet draft of MIPv6.
May I ask with what? We ran all the TAHI tests last month at ETSI
IPv6 Plugtest, and know pretty much were we stand. And with all due
respect to TAHI, who checks that the test suites conform to the spec?
> (1) About MIPV6CALLFUNC and MIPV6CALLPROC
> It is reasonable to use these macros for modularized
> functions. But the current your implementation needs to select
> HA or MN when compiling the kernel. So, it doesn't seems to be
> needed this macros, and the real function may be called
> directly. How about this?
If MIPv6 is compiled as module, and is not loaded, those macros
protect against calling non-existant code. HA and MN do not need to
be compiled statically, if that is what you are implying. You must
first select CN support, which decides module or static.
> Rather, how about using sysctl and so on to switch the
> functionality?
No. Users want to be able to have only one of the capabilities loaded
at one time (i.e. CN, CN+MN or CN+HA). When you compile e.g. CN,
there is no HA or MN support compiled in, so the sysctl makes no sense.
> (4) Processing Mobility Header
> How about using ip6_txoptions and hdrproc_lst?
> Because Mobility header is an extension header, we think it is
> reasonable way to handle it in ipv6_parse_exthdrs().
No. We did this back in Draft 15, when all the mobility stuff was
destination options. Mobility Header is not an extension header, but
rather a final protocol. Only Home Address Option is an extension
header and is handled in ipv6/exthdrs.c. What is the problem with
this?
> (5) How about using CryptoAPI?
> CryptoAPI is merged to mainline.
> We believe we can use the CryptoAPI for caluculating cookies
> of RR. How do you think about this?
Yes, this will be done. But that was merged yesterday, and we are
only humans :)
> (6) Order of HAO and Routing header
> When MN acts also as CN, the order doesn't seems to be
> compliant to ID-18 in the implementation. The order will be
> the following:
>
> [IPv6][HAO][RT2]
>
> I-D says:
>
> [IPv6][RT2][HAO]
Right. We haven't changed the IPv6 code to support the third
destination option header placement (after RH, before frag/AH/ESP),
and since it introduces no compatibility problems with any other
implementation we've tested with, it has not been a priority.
Regards,
Antti
--
Antti J. Tuominen, Gyldenintie 8A 11, 00200 Helsinki, Finland.
Research assistant, Institute of Digital Communications at HUT
work: [email protected]; home: [email protected]
In article <[email protected]> (at Thu, 31 Oct 2002 12:44:00 +0200 (EET)), Henrik Petander <[email protected]> says:
> > (2) Avoiding Netfilter Hooks
> > In your imprementation HA uses netfilter to intercept packets
> > sent to MN. We think it is costy so we have a suggestion to
> > use FIB structure to forward packets to MN. Bacause we think
> > forwarding packets from HA to MN is FORWARDING, not FILTERING.
> > We think the kernel maintainers may prefer such a manner using
> > FIB structure for forwarding.
>
> We are using standard routing in HA to route packets intercepted by HA to
> MN through a tunnel device. However, HA needs to also act as a neighbor
> discovery proxy for MN and not tunnel any ND packets destined to MN, but
> reply to them on the bahalf of MN. We use the netfilter hook to check for
> ND packets with global addresses that would be otherwise tunneled and feed
> them directly to the local processing code.
I believe that netfilter is not appropriate here.
If it is protocol requirement, do it in the stack itself.
Well, HA is router.
Sending side: Make mip6_forward().
When new MN is being registered, setup proxy ndisc and
make routes to MN via mip device (which is mip tunnel),
which actually calls mip6_foward().
When packet arrives, it checks MNs and forward it to it.
Receiving side:
mipl tunnel receives packets from MN.
check source address according to the list of MNs,
then forward it.
Also, I believe that the binding information should be hold as FIB entry.
--yoshfuji
In article <[email protected]> (at Thu, 31 Oct 2002 12:41:46 +0200), Antti Tuominen <[email protected]> says:
> > (4) Processing Mobility Header
> > How about using ip6_txoptions and hdrproc_lst?
> > Because Mobility header is an extension header, we think it is
> > reasonable way to handle it in ipv6_parse_exthdrs().
>
> No. We did this back in Draft 15, when all the mobility stuff was
> destination options. Mobility Header is not an extension header, but
> rather a final protocol. Only Home Address Option is an extension
> header and is handled in ipv6/exthdrs.c. What is the problem with
> this?
This is not so strong request here at this moment.
--yoshfuji