Subject: [nemo] FYI [Mip6] General comments/questions on MIPv6 bootstrapping

From: Thierry Ernst <[email-masked]>
Date: Thu, 27 Oct 2005 10:24:28 +0900

Dear all,

In case you are not on the MIP6 ML, I think this thread is interesting
for the NEMO WG. 

Thierry.

Subject: Re: [Mip6] General comments/questions on MIPv6 bootstrapping
From: Francis Dupont <[email-masked]>
To: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
Cc: [email-masked]
Date: Wed, 26 Oct 2005 14:13:53 +0200
List-Id: mip6.ietf.org

 In your previous mail you wrote:

   I have 2 main comments/questions.
   
   The first one is regarding the fact that we have two (very) different
   mechanisms for only one functionality (on one side DNS+IKEv2, on the
   other side PANA+AAA+DCHP). So, personally, I am a little afraid how all

=> PANA is not in the I-D, i.e., the protocol between the MN and
the NAS is not specified (but it can be PANA).

   this will be managed in the user's terminal and in the MSP's network.
   E.g., what will be the trigger in the terminal to know which is the
   bootstrapping mechanism the terminal has to use?
   
=> I don't believe it is a real issue, or to use another argument,
you have already the issue for the network access control itself.

   My second comment is regarding the interoperability with NEMO. I believe
   that if MIPv6 is deployed soon, NEMO will be deployed at the same time
   because the protocol is as mature as MIPv6. So I would like to know if
   the bootstrapping mechanisms working for MIPv6, will work with NEMO too.
   I would like to avoid to add new mechanisms again and so increase the
   complexity in a deployement architecture.
   
=> we can classify mechanisms into mechanisms with a NEMO flag (ICMP-based
DHAAD for instance) or NEMO knowledge (HA-switch for instance), and
zero-knowledge mechanisms where the NEMO knowledge has to be out of band.
I believe it is the case today for DHCP (but it can be easily fixed)
and IKEv2 HA-assignment (where IMHO it is harder without another anycast
address). I can't see a reason to get really different mechanisms for
MIPv6 and NEMO.

Regards

[email-masked]

PS: I'll do a second answer with my comments about the draft (i.e.,
I'll keep the subject and the subject header).

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Oct 2005 11:08:08 +0200

=> BTW I have a question for the NEMO WG. The current HA-assignement
by IKEv2 (which is being validated by the IPsec people, at least I expect :-)
cf http://msgs.securepoint.com/cgi-bin/get/ipsec-0510/26.html
could need a second anycast address for HAs supporting NEMO on the link.
Is it a problem?

Regards

PS: note the new anycast address matters only for:
 - HA configuration (in case the anycast address is wired in the code)
 - MN configuration (same)
 - IANA
With the DNS-based service or address discovery, it is fully flexible
and transparent. Same for the current ICMP-based DHAAD, the HA-switch,
etc.
In conclusion I can't see a problem if nobody has wired the address
in its code, something which can be considered as pretty wrong in
any case (but I am old enough to know some did this :-).

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Oct 2005 14:46:21 +0200

Francis Dupont wrote:
> In case you are not on the MIP6 ML, I think this thread is
> interesting for the NEMO WG.
> 
> by IKEv2 (which is being validated by the IPsec people, at least I
> expect :-) cf
> http://msgs.securepoint.com/cgi-bin/get/ipsec-0510/26.html could need
> a second anycast address for HAs supporting NEMO on the link. Is it a
> problem?

Probably not a problem, but something that concerns NEMO, since HAs that
support MRs need to tell that to MR.

If IKEv2 could be used instead of DHAAD to help MR populate its HA list
then yes, good.

Probably the effect of assigning two anycast addresses for HAs could be
obtained otherwise: just extend the IKEv2 message containing the HA list
to tell it it's a HA that supports MR (instead of MN).  Or similar?

> PS: note the new anycast address matters only for: - HA configuration
> (in case the anycast address is wired in the code) - MN configuration
> (same) - IANA With the DNS-based service or address discovery, it is
> fully flexible and transparent. Same for the current ICMP-based
> DHAAD, the HA-switch, etc.

I agree.

> in its code, something which can be considered as pretty wrong in any
> case (but I am old enough to know some did this :-).

I do hardcode stuff now and then, especially with specs that change -
it's quicker to hardcode and then delete than trying to write re-usable
code in a world where specs are hardcoded and then deleted.

Alex

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Oct 2005 15:54:31 +0200

=> I am strongly against the idea to add a notification to IKEv2
or something like that. A new anycast address is in phase with
the general idea of anycast: it selects one of the members of a
group, here we have two groups so should have two addresses!

I summary your position: not a problem but a question in the scope
of NEMO (i.e., NEMO has to decide). I agree.

Thanks