Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt

From: "fan zhao" <[email-masked]>
Date: Tue, 8 Jul 2008 11:23:50 -0700

Hi,

We have submitted a draft on using IKEv2 to assign a Mobile Network
Prefix to the Mobile Router. Comments, questions and suggestions
are highly appreciated.
Thanks.

BR,
Fan

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 2008/7/6
Subject: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : IKEv2 based Mobile Network Prefix Assignment
       Author(s)       : F. Zhao, et al.
       Filename        : draft-zhao-mext-mnp-ikev2-00.txt
       Pages           : 13
       Date            : 2008-07-06

This document proposes a mechanism for the Mobile Router to
dynamically obtain the Mobile Network Prefix through IKEv2.  The
mechanisms to renew, release and update the allocated Mobile Network
Prefixes are also described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zhao-mext-mnp-ikev2-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 08 Jul 2008 21:19:43 +0200

Hi,

> Prefix to the Mobile Router. Comments, questions and suggestions

Comments inline below.

> 3.  New Attribute Format
>
>    We propose a new IKEv2 Configuration Attribute, called
>    MOBILE_NETWORK_PREFIX6.  This attribute is carried in the IKEv2
>    Configuration Payload and is used to convey an IPv6 Mobile Network
>    Prefix between the Mobile Router and the Home Agent.  Figure 1 shows
>    the format of the MOBILE_NETWORK_PREFIX6 Configuration Attribute.
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |R|      Attribute Type         |           Length              |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         Prefix Lifetime                       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        |                  IPv6 Mobile Network Prefix                   |
>        |                                                               |
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Prefix Length |
>        +-+-+-+-+-+-+-+-+
>
>        Figure 1: The format of the MOBILE_NETWORK_PREFIX6 attribute
>
>       Reserved (1 bit)
>
>          This bit MUST be set to zero and MUST be ignored on receipt.
>
>       Attribute Type (15 bits)
>
>          A unique identifier for the MOBILE_NETWORK_PREFIX6 attribute
>          (to be determined by IANA).
>
>       Length (2 octets)
>
>          Length in octets of fields, including IPv6 Mobile Network
>          Prefix, Prefix Lifetime and Prefix Length.  This can be 0 or
>          21.
>
>       Prefix Lifetime (4 octets)
>
>          The length of time period during which the Mobile Network
>          Prefix remains valid.  This should not be longer than the
>          lifetime of the IKE security association used when the Mobile
>          Network Prefix is assigned to the Mobile Router.

I have no strong opinion on this specific topic but: Why limiting the
prefix lifetime so that it is smaller than the SA lifetime? For me, the
prefix and prefix lifetime are MIPv6 related information and SA lifetime
are IKE-related information.

>       Prefix Length (1 octet)
>
>          The length in bits of the Mobile Network Prefix specified in
>          the IPv6 Mobile Network Prefix field.
>
>    When the Mobile Router requests a new Mobile Network Prefix, the
>    Mobile Router includes the MOBILE_NETWORK_PREFIX6 attribute in the
>    CFG_REQUEST payload and the value of the Length field is zero or the
>    IPv6 Mobile Network Prefix field is set as zero.  The Mobile Router
>    may indicate the preferred Mobile Network Prefix in this attribute
>    and the Home Agent should return the indicated Mobile Network Prefix,
>    if available.  The Mobile Router may explicitly request a lifetime by
>    specifying a value in the Prefix Lifetime field.  Such value must not
>    be zero if the Mobile Router specifies a preferred Mobile Network
>    Prefix and is set as 2^32-1 if the Mobile Router wants the assigned
>    Mobile Network Prefix remains valid for the lifetime of the IKEv2
>    security association.  The Mobile Router may request multiple Mobile
>    Network Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes
>    in one IKEv2 request message.

This leads to a question: who decides how many prefixes will be
configured and on which interfaces? The MR or the HA? How will the MR
decide to assign prefix1 and prefix2 to interface A and interface B (or
the reverse). This will end up being a local decision on the MR, AFAICT.

You should probably explicitly states that the MR requests the number of
prefixes it want BUT the final decision is let to the HA. The details
of how the delegated prefixes are used on the MR are outside the scope
of the specification.

More generally, I don't think the solution will be really usable in a
multiple interfaces/prefixes case (this is just an opinion).

>    If such request from the Mobile Router is valid, the Home Agent
>    includes the MOBILE_NETWORK_PREFIX6 attribute in the CFG_REPLY
>    payload and sends it back to the Mobile Router in one IKEv2 response
>    message.  The attribute contains the allocated Mobile Network Prefix
>    and the lifetime authorized by the Home Agent.  If the Mobile Router
>    requests multiple Mobile Network Prefixes in one IKEv2 request
>    message, the Home Agent should return multiple Mobile Network
>    Prefixes by using multiple MOBILE_NETWORK_PREFIX6 attributes in one
>    IKEv2 response message.
>
>    There are different mechanisms for the Home Agent to allocate the
>    Mobile Network Prefix.  For example, the Home Agent may manage a pool
>    of network prefixes by itself or communicate with a DHCP server
>    located in the home domain for this task.  The details of such
>    mechanisms are out of scope of this document.

If DHCP is used the DUID*, IA_PD, ... from the real peer (the MN) will
not be available on the HA. In the end, DHCP will only be used to
retrieve a bunch of anonymous prefixes which will then be sent to the
IKE daemon on the MN. IMHO, this difference with an end-to-end DHCPv6
solution will matter in environments with multiple prefixes/interfaces.

> 4.  Mobile Network Prefix Assignment
>
>    When the Mobile Router powers up, based on its configuration or some
>    mechanisms that are out of scope of this document, the Mobile Router
>    may choose hosted based mobility protocols, such as DSMIPv6/NEMO, to
>    set up network connectivity.  Figure 2 shows the steps performed by
>    the Mobile Router during bootstrapping.
>
>           MR                      Access network                      HA
>           |                            |                            |
>           | IP address configuration   |                            |
>           |<-------------------------->|                            |
>           |                            |                            |
>           | Home Agent discovery       |                            |
>           |<-------------------->      |                            |
>           |                            |                            |
>           | IKE_SA_INIT{...}                                        |
>           |<------------------------------------------------------->|
>           |                                                         |
>           | IKE_AUTH{CFG_REQUEST(HoA/HNP, MNP)}                     |
>           |-------------------------------------------------------->|
>           |                                                         |
>           | IKE_AUTH{CFG_REPLY(HoA/HNP, MNP)}                       |
>           |<--------------------------------------------------------|
>           |                                                         |
>           | BU/BA                                                   |
>           |<------------------------------------------------------->|
>           |                                                         |
>
>     Figure 2: The procedure of the Mobile Network Prefix assignment via
>                                    IKEv2
>
>    o  When attaching to a new link, the Mobile Router configures an IP
>       address on its interface that attaches to this link, for example,
>       by performing IP address stateless configuration using Router
>       Solicitation and Router Advertisement messages.
>
>    o  The Mobile Router discovers the IP address of the Home Agent, for
>       example, by using mechanisms defined in [6] [3] and [4].
>
>    o  The Mobile Router starts to establish an IPSec security
>       association and firstly completes the IKE_SA_INIT exchange with
>       the discovered Home Agent.

I still wonder how that negotiation is *triggered*. I will probably ask
on ipsec@ietf at some point. 

>    o  If the Mobile Router attaches to its home link (the details of the
>       home link detection mechanism is out of scope of this document),
>       the Mobile Router does not perform binding registration with the
>       Home Agent.  Otherwise, the Mobile Router follows the procedure
>       specified in the NEMO Basic Support Protocol [1] to register the
>       binding between its Care-of address and its Home Address and the
>       Mobile Network Prefix with the Home Agent.  Additionally, the
>       Mobile router may negotiate an IPSec child security association
>       with the Home Agent to protect the data traffic from itself and
>       the Mobile Network Nodes.

Because the MR needs to register its network prefix with the HA, there
is a need for the HA to be warned by IKE (or another mean) which
prefixeshave been delegated (using IKE or another solution). If it is
not defined, this cannot be implemented at all.

> 5.2.  Releasing the Mobile Network Prefix
>
>    The Mobile Network Prefix release procedure can be initiated by
>    either the Mobile Router or the Home Agent.
>
>    To release an allocated Mobile Network Prefix, the Mobile Router
>    initiates the IKEv2 Informational Exchange with the Home Agent.  In
>    the CFG_REQUEST payload carried in the IKEv2 request message, the
>    Mobile Router includes the Mobile Network Prefix to be released and
>    the lifetime set as zero in the MOBILE_NETWORK_PREFIX6 attribute.  As
>
>
>
> Zhao, et al.             Expires January 5, 2009                [Page 8]
> 
> Internet-Draft                MNP Assigment                    July 2008
>
>
>    a reply, the Home Agent returns a CFG_REPLY payload indicating the
>    released Mobile Network Prefix and the lifetime set as zero.
>
>    To release an allocated Mobile Network Prefix, the Home Agent can
>    also initiate the IKEv2 Informational Exchange with the Mobile
>    Router.  In the IKEv2 Informational Exchange message sent to the
>    Mobile Router, the Home Agent uses the CFG_REQUEST payload to carry
>    the MOBILE_NETWORK_PREFIX6 attribute that indicates the Mobile
>    Network Prefix to be released and the lifetime set as zero.  When the
>    Mobile Router receives such IKEv2 request message, it removes the
>    corresponding configuration and replies with a CFG_REPLY payload to
>    carry the MOBILE_NETWORK_PREFIX6 attribute that indicates the
>    released Mobile Network Prefix and the lifetime set as zero.  When
>    the Home Agent receives this responses, it recycles the released
>    Mobile Network Prefix.

If that happens, what are the impacts WRT MIPv6: even if it is released
at the IKE level, what is then done at MIPv6 level? How are both MIPv6
peers warned by their IKE couterparts that the prefix released has
happened?

> 5.3.  Updating the Mobile Network Prefix
>
>    The Mobile Network Prefix update procedure can be initiated by either
>    the Mobile Router or the Home Agent.
>
>    One way to perform the Mobile Router initiated Mobile Network Prefix
>    update procedure is that the Home Agent returns a different Mobile
>    Network Prefix when the Mobile Router requests to renew a Mobile
>    Network Prefix.  Another way is that the Mobile Router indicates the
>    release of the old Mobile Network Prefix and the request of a new
>    Mobile Network Prefix by using two separate MOBILE_NETWORK_PREFIX6
>    attributes in one CFG_REQUEST payload.  The Home Agent should return
>    a new Mobile Network Prefix and confirm the release of the old Mobile
>    Network Prefix by using two separate MOBILE_NETWORK_PREFIX6
>    attributes in one CFG_REPLY payload.
>
>    To perform the Home Agent initiated Prefix update procedure, the Home
>    Agent indicates the release of the old Mobile Network Prefix and the
>    assignment of a new Mobile Network Prefix by using two separate
>    MOBILE_NETWORK_PREFIX6 attributes in one CFG_REQUEST payload.  In
>    this case, the Mobile Node should confirm the assignment of the new
>    Mobile Network Prefix and the release of the old Mobile Network
>    Prefix by using two separate MOBILE_NETWORK_PREFIX6 attributes in one
>    CFG_REPLY payload.

Same questions as for previous section. Another comment: in this block,
it is quite obvious that there are no more two separate entities (IKE
and MIPv6), which obviously make the associated interface issues
disappear: you use IKE exchange payload as if they were sent by the
HA. They are not. They are sent by the IKE daemon on the HA.

>    The NEMO Basic Support protocol [1] requires that the Home Agent
>    check if a Mobile Network Prefix received in a Binding Update message
>    is authorized to be used.  To do so, the Home Agent can associate the
>    mobile node identity used in the IKEv2 authentication process with
>    the Home Network Prefix allocated.

Easy for the IKE daemon but how will the HA get the information when the
MIPv6 MNP request will come.

>    In some deployment, the Homme Agent itself manages the allocation of
>    Mobile Network Prefixes, for example, from a locally managed prefix
>    pool. it is also possible that additional back-end servers are used
>    for Mobile Network Prefix assignment.  For example, the Home Agent
>    can act as a DHCP Requesting Router and interact with a DHCP
>    Delegating Router.

In the end, this is the HA which will decide (i.e. ack or nack prefixes
in the MIPv6 message).

>                       The security mechanism protecting the interaction
>    between the Home Agent and such back-end servers could be generic
>    security mechanisms, such as IPSec, or specific to the protocols used
>    in between, such as DHCP authentication option.

Does not belong here, IMHO.

>                                                    Once allocated, the
>    Mobile Network Prefix must not be assigned to a different Mobile
>    Router until such Mobile Network Prefix is returned to the Home
>    Agent.

In you draft, this requires the prefix to be released both at IKEv2 and
MIPv6 level, doesn't it?

From a global standpoint, i think the solution could work for simple
deployments with a single delegated prefix but it lacks the specific
details of how MIPv6 and IKE need to work together on both sides.

Note that my comments are only technical: I have no opinion WRT the use
of IKEv2 to delegate prefixes to a MR. I (still) mainly wonder about the  
required interface between MIPv6 and IKE to do that ;-)

Hope that helps,

Cheers,

a+

---

From: "fan zhao" <[email-masked]>
Date: Wed, 9 Jul 2008 09:39:04 -0700

Hi Arnaud,

Sorry for the late reply and thank you for all these good comments.
Please see my reply below.

> are IKE-related information.

Fan> I agree that the prefix and prefix lifetime are more related to MIPv6
than IKE. Although the prefix lifetime is equal to or smaller than the IKE
SA lifetime, when the IKE SA lifetime expires, the MR can request the
same prefix. In reality, I do not see any particular reason that the HA
would reject the request of the same prefix from the same MR. Therefore
the protocol specified here allows the same prefix to be used for a time
period longer than the lifetime of the IKE SA.

Fan> Although very rare, the prefix may be changed before the SA expires.
We do not want to exclude such possibility and limit the capability of the
protocol, because IMO, the protocol is a tool and how to use is up to
deployment,
configuration and policy. The MR can request any lifetime of the
prefix and it is
finally decided by the HA. Also in MIPv6, the lifetime of the HoA is
also associated
with the lifetime of the SA.

> the reverse). This will end up being a local decision on the MR, AFAICT.
Fan> The final decision on how many prefixes can be configured on the
MR should be made by the HA. I agree that it is the MR's decision on
which prefix is configured on which interfaces, i.e. those interfaces
connecting to the Mobile Network.

> of how the delegated prefixes are used on the MR are outside the scope
Fan> I agree. That is a good suggestion. I will revise the draft accordingly.

> multiple interfaces/prefixes case (this is just an opinion).

Fan> Can you please elaborate it? I assume that by the multiple
interfaces/prefixes case, you mean that the MR has, for example,
two interfaces, A and B, connecting to the Mobile Network and
the MR wants to configure one unique prefix on each interface, as
you mentioned above. Do I understand correctly or I miss something.
There are many scenarios described in the NEMO multihoming analysis draft.

> solution will matter in environments with multiple prefixes/interfaces.

Fan> Firstly, I have a question regarding DUID. I checked RFC 3315, the
DUID could be a MAC address. Does this mean that a multi-interface MN
can use a different DUID in a separate DHCP session (thus, acts as a different
DHCP client)?

Fan> If so, when the MR acts a DHCP requesting router and the HA acts as
a delegating router as specified in DHCP-PD, the MR can use
different MAC addresses of the interfaces connecting to the Mobile
Network as DUID, so that the HA can assign a specific MNP to each of such
interfaces. Is my understanding correct?

Fan> Well, the protocol we proposed can be extended to carry the interface
id for the home agent to assign a specific prefix to a specific interface.
However, before going into the details of the solution, I would like
to understand
the scenario and the use case for such requirement? As far as I know, the
NEMO basic support protocol only requires the HA to verify whether the _MR_
is authorized to register certain MNPs. There is no requirement that the HA
needs to know which MNP is configured on which interface. BTW, how does
the HA make decisions based on the interfaces connecting to the mobile network.
IMHO, this should be transparent to the HA. Maybe you have a use case in mind,
can you please elaborate it?

> on ipsec@ietf at some point.

Fan> OK.

> not defined, this cannot be implemented at all.

Fan> I agree. I mentioned this issue in the security consideration
section, though the details of out of scope of this document.

> peers warned by their IKE couterparts that the prefix released has
Fan> IMO, mobility signaling messages should take care of mobility
states at the MIPv6 level, such as binding cache entries. When the MR
attaches to its home link, there is no corresponding binding cache entry
created at the home agent, thus the HA and the MR do not need to do
anything at the MIPv6 level. When the MR attaches to a foreign link, and
when the MR wants to release a MNP, it can send a mobility message, such
as the BU message, to de-reg the MNP from the binding cache entry and
then use the IKE informational exchange to release the MNP, or vice versa.

> Same questions as for previous section.
Fan> The MN can use the BU message to de-reg the old MNP and register
the new MNP with the HA.

> Another comment: in this block,

Fan> I will reword it. My impression is that the interface between the
IPSec and the MIP already needs to be defined; however, if we use
DHCP-PD, then we also need to specify another interface between
DHCP and MIP, which results in more complexity.

> MIPv6 MNP request will come.

Fan> My impression is this could be implementation specific. There
are drafts on PF_KEY extension as an interface between Mobile IPv6
and IPsec/IKE. I think this is an important issue, but may be out of scope
of this draft.

> In the end, this is the HA which will decide (i.e. ack or nack prefixes

Fan> Yes.

> Does not belong here, IMHO.

Fan> Yes.

> In you draft, this requires the prefix to be released both at IKEv2 and

Fan> Yes. Actually, to be more precise, the prefix is released at the
IKEv2 level and the mobility states related to such prefix is updated
at the MIP
level if such states exist, e.g. when the MR attaches to a foreign link.

> details of how MIPv6 and IKE need to work together on both sides.

Fan> Thanks for your comments. Your comments are very important
and helpful. We still need to discuss about the multiple prefix/interface
case and we will update the draft by providing more details on the interaction
between MIPv6 and IKE.

Thanks a lot.

Sincerely,
fan

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 14:58:52 -0400

Hello Fan,

I prefer using the Binding Update/Binding Ack exchange for assigning a
mobile network prefix to the mobile router instead of defining an IKEv2
configuration payload for this, unless there are some significant
advantages to use IKEv2. Are there any?

draft-zhao-mext-mnp-ikev2-00.txt does not talk about the advantages of
using IKEv2 configuration payloads over BU/BAck exchange.

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of fan zhao
> Sent: Tuesday, July 08, 2008 11:24 AM
> To: [email-masked]
> Subject: [MEXT] Fwd: I-D Action:draft-zhao-mext-mnp-ikev2-00.txt
> 
> Hi,
>

---

From: "fan zhao" <[email-masked]>
Date: Wed, 9 Jul 2008 12:30:54 -0700

Hi Vijay,

My understanding is that the MR does not perform the BU/BA
exchange with the HA over the home link.

Sincerely,
fan

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 20:01:55 -0400

> exchange with the HA over the home link.

Is that the only reason why you would want to use IKEv2 exchange instead
of a BU/BAck exchange?

Vijay

---

From: "fan zhao" <[email-masked]>
Date: Wed, 9 Jul 2008 17:05:29 -0700

Hi Vijay,

Also RFC 5026 specifies that the home address is assigned during IKE
signaling.

Sincerely,
fan

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 20:10:04 -0400

> Also RFC 5026 specifies that the home address is assigned during IKE

That's because you need to setup IPsec SAs based on the home address.
The home address needs to be known before the IPsec SAs are setup. Even
the binding update cannot be sent if the required SA is not in place.

There is no such dependency on configuring the mobile network prefixes. 

Vijay

---

From: "fan zhao" <[email-masked]>
Date: Wed, 9 Jul 2008 17:22:19 -0700

Hi Vijay,

Requesting the HoA/HNP during IKE_AUTH is also for
home link detection. Having said that, I agree with what
you said when the MN is on the foreign link.

The MNP is required for the MR to operate, in addtion
to the HoA/HNP. It is the most efficient way for the MR
to be configured via the IKEv2.

I am curious how the BU/BA based PD works on the home link?

Sincerely,
fan

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 21:57:30 -0400

> to be configured via the IKEv2.

Don't agree on the efficiency part. The mobile router does not advertise
the mobile network prefixes in its mobile network until the BU/BAck
exchange complete. 

> I am curious how the BU/BA based PD works on the home link?

It doesn't. This is one of the reasons I wrote
draft-devarapalli-mext-mipv6-home-link-01.txt, which allows the mobile
router to send a binding update from the home link.

Vijay

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 10 Jul 2008 08:41:10 +0200

Hi Vijay,

> the binding update cannot be sent if the required SA is not in place.

No relation with the thread: are you aware of any implementation of that
mechanism?

Cheers,

a+

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 10 Jul 2008 14:30:09 -0400

> No relation with the thread: are you aware of any 

Open source or product implementations? 

The USAGI implementation might be supporting this. Check with them. The
last time I worked on a MIPv6 implementation was back in 2005. There was
no IKEv2 spec for MIPv6 back then. 

Vijay

---

From: "fan zhao" <[email-masked]>
Date: Thu, 10 Jul 2008 16:24:52 -0700

Hi Vijay,

Sorry for my late reply. Please see below.

> the mobile network prefixes in its mobile network until the BU/BAck

You may be right, though it seems you are introducing this arbitrary
assumption.
Can you please help us understand where it is stated in RFC 3963 that
the mobile
router does not advertise the prefix before the BU/BAck exchange is completed?
To my best knowledge, advertising a prefix is for IP configuration and
local network
access, while completing the BU/BA exchange is for establishing a
bi-directional
tunnel and obtaining access to the Internet. Without such assumption, even if
the efficiency may be minimal, there would still be efficiency in
allowing the MNNs
to configure addresses as soon as the MR has the prefix available.

> router to send a binding update from the home link.

IMO, to use the BU/Back for MNP assignment, you must modify Mobile IP
to ensure the mobile router exchanges BU/Back also on the home link.
This seems an artificial and unnecessary complication, since the mobile router
anyway would perform IKEv2 even on the home link, e.g. for home link detection.
And therefore, with a minor enhancement it would be possible to deliver the
delegated prefix to the mobile router. Instead, with your proposal, the
mobile router needs to perform additional steps currently not performed
by a Mobile IP mobile node. Therefore, we argue that using IKEv2 has
much less impact and does not require modifications to the Mobile IP
behavior.

Sincerely,
fan

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 11 Jul 2008 08:15:37 +0200

Hi Vijay,

"Vijay Devarapalli" <[email-masked]> writes:

>> No relation with the thread: are you aware of any implementation of
>> that mechanism? 
>

both (but I think I already known the status for open source
implementations). One small note: i was asking about Home Address
assignment as described in 5026.

> The USAGI implementation might be supporting this. Check with them.

I know the status of USAGI implementation: it does support (with
patches) setup of IPsec SA with IKE based on the Home Address, as
expected by MIPv6 main reference documents.

- UMIP w/ patches (maintained)
- racoon w/patches (maintained)
- racoon2 w/ patches (not maintained)

For 5026, none of previous elements supports it.

> The last time I worked on a MIPv6 implementation was back in
> 2005. There was no IKEv2 spec for MIPv6 back then. 

ack.

Thanks for your reply,

a+

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 14 Jul 2008 14:24:11 -0400

Hi Arnaud,

> assignment as described in 5026.

I guess, I misunderstood your earlier email. I am not aware of any MIPv6
implementation that implements the RFC 5026 mechanism to assign a home
address. I don't see any issues, though. Yes, you would need some
interaction between the IKEv2 and MIPv6 modules to assign the address
obtained via the configuration payload as the home address.

> For 5026, none of previous elements supports it.

Maybe, it just a matter of time. (?)

Vijay