Hi,
On 11/05/12 00:57, Tobias Heer wrote:
Hi,
Am 10.05.2012 um 10:56 schrieb Xin Gu:
Hi everyone,
I am a developer from HIPL project and working on HIPv2 related functionalities
under Miika's instruction. We have found some gaps in the transition process
from HIPv1 to HIPv2. My question is: do we expect a smooth transition from
HIPv1 to HIPv2 or we simply want to wipe out HIPv1?
No matter what the answer it will be, we think it is still worthwhile to
describe those gaps we met, because we might face similar transition problems
again when HIPv3 comes out. Below is the description:
In order to provide a smooth transition from HIPv1 to HIPv2, we start to
prototype a dual version support HIPL, which aims to handle HIPv1 and HIPv2
association at the same time. If the version of the inbound I1 is one, the HIPL
host continues a HIPv1 BEX; If the version of the inbound I1 is two, the host
goes with a HIPv2 BEX.
However the new OGA bits in HIPv2 adds new gaps to this approach. The
introduction of OGA bits changes the presentation of a key in HIPv1 HIT and
HIPv2 HIT and a host cannot tell a HIT contains OGA bits or not solely
(although there is a very low possibility that v1 HIT and v2 HIT for a same key
are identical).
As far as I remember, we discussed a new prefix for the new version of the
ORCHID. This would make the distinction trivial.
Will this solve your problem?
A new prefix will be a great help. I was wondering why the new version
of the ORCHID is still not available? In recent RFC5201-bis-08 there is
no hints about a new prefix.
Best regards,
Xin Gu
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
