[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 RH (was Re: SPD issues)
At 19:39 26/10/2003 -0500, Stephen Kent wrote:
>At 17:09 +0200 10/23/03, Eric Vyncke wrote:
>We did overlook this in 2401, and we ought to be more precise in 2401bis.
>The IPv6 destination is what I expect folks would use for selector checking, for both outbound and inbound traffic.
It does make sense to ignore the RH (43 type 1) and only base the SPD on source and destination.
>We might add a flag that explicitly disallows traffic with routing headers, as a local admin control for SPD entries. In the IPv4 case, we could to do the same re the source route option.
I would leave this as an implementation detail.
But, as it has been pointed by someone else, with mobile IPv6 there are two different IPv6 headers:
- Destination Option (60) which is used by a mobile node to indicate its 'permanent' (= home) address (as opposed to its care-of-address which is in the source address field of the IPv6 header)
- Routing Header (53 type 2) of second kind which is used by packets sent to the mobile node to indicate the 'permanent' address of the mobile node (as opposed to the care-of address which is in the destination address field of the IPv6 header)
This is very close to yet another tunnel in disguise. And there are good arguments to apply the SPD on two points:
- plain source and destination field of the IPv6 address: e.g., to protect the payload during the transit over the public network at the expense of a new IKE renegotiation during roaming
- permanent addresses (i.e. DO for packets sent by the mobile node and RH for packets sent to the mobile node): end to end protection
I'm mostly ignorant regarding MIPv6... and it would probably be safer and easier to state in RFC2401bis that the SPD for MIP (v4 and v6) will be defined in the framework of MIP4 and MIP6 WG. This means that the processing of RH type 2 and DO are explicitly not defined in rfc2401bis.