Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Jun 2008 12:18:41 -0700 (PDT)

Hi Vijay,
  Pls. see inline.

Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: fan zhao <[email-masked]>; Alexandru Petrescu <[email-masked]>
Cc: Julien Laganier <[email-masked]>; [email-masked]
Sent: Tuesday, June 10, 2008 1:22:20 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hello Fan,

*If* we are not going to be using DCHP for the mobile router to obtain
mobile network prefix(es) from the home agent, I would prefer the
BU/BAck exchange rather than modifying/extending IKEv2. 

[behcet] You mean other than RFC 5026?

The mobile
router could just request for the mobile network prefix(es) in the BU
and get the information in the BAck. 

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of fan zhao
> Sent: Tuesday, June 10, 2008 2:48 AM
> To: Alexandru Petrescu
> Cc: [email-masked]; Julien Laganier
> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
> 
> Hi Alex,
> 
> Thanks for your reply. Sorry I could not reply you earlier.
> 
> On Tue, Jun 10, 2008 at 2:05 AM, Alexandru Petrescu
> <[email-masked]> wrote:
> > Hi Fan and thank you for the other private email, I take 
> advantage of this
> > to reply publicly.
> >
> > fan zhao wrote:
> >>
> >> Hi Julien, Marcelo et al,
> >>
> >>> The question at this stage is whether we want to make the only
> >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft.
> >
> > WEll I agree in principle, provided authors are open to 
> feedback from
> > implementation and ready to modify it further.
> >
> >> IMHO, the DHCP-PD solution leads to additional signaling overhead;
> >> furthermore, using the DHCP Authentication Option 
> introduces another
> >> layer of overhead/redundancy. Therefore, my oponion is 
> DHCP-PD should
> >> not be the only solution.
> >
> > Well DHCP-PD through the secured MR-HA tunnel wouldn't use 
> DHCP auth option.
> I agree. The secured MR-HA tunnel relies on the IPSec SA. The IPSec SA
> is established
> when the MR powers up.
> During the IPSec SA establishment with the HA, the MR can request its
> home address and the
> MNP using the configuration payload.
> 
> >
> >> RFC 5026 describes the procedure for the MN to dynamically 
> obtain the
> >>  home address from the network using the IKEv2. As defined in RFC
> >> 3753, a MN could be either a MR or MH. Therefore it is natural to
> >> define extensions in the IKEv2 for the MR to request the MNP, which
> >> is more efficient and secure.
> >
> > I'm not sure using IKEv2 to obtain MNP is more efficient 
> than DHCP, at least
> > because IKEv2 has much more roundtrips than DHCP, so it 
> could be considered
> > heavier (or less efficient).
> 
> Alex, the following is the comparison between the DHCP-PD and 
> the IKE-PD.
> 
> DHCP-PD:
> Assume that the MR is not at the home link, when the MR 
> powers up using CMIP,
> it follows the bootstrapping procedure as a MN: first, it obtains a
> local IP address as CoA;
> second, it obtains the IP address of the HA; third, it establishes the
> IPSec SA with the HA,
> during this procedure, the MR obtains a HoA; fourth, the MR compares
> the HoA with
> the previously configured IP address, i.e CoA and the MR determines
> that it is not at home;
> therefore it sends a BU to the HA to reg the binding between HoA and
> CoA and receives a BA; fifth,
> based on its configuration, the MR realizes it should act as a MR and
> obtain a MNP. With the
> DHCP based approach, the MR sends a DHCP solicit message to the HA and
> the MR receives
> a DHCP reply message. Now the PD is completed.
> 
> IKE-PD:
> Assume that the MR is not at home link, ... first, it obtains a local
> IP address as CoA;
> second, it obtains the IP address of the HA; third, it establishes the
> IPSec SA with the HA,
> during this procedure, the MR obtains a HoA and a MNP based its
> configuration; fourth, the MR compares the HoA with
> the previously configured IP address, i.e CoA and the MR determines
> that it is not at home;
> therefore it sends a BU to the HA to register the binding between HoA
> and MNP and CoA and receives a BA.
> 
> Note that we conclude before the home link detection is based on the
> IKE. Therefore, the MN also
> performs 1) to 4) when it is on its home link. So with the IKE-PD, the
> MN does not need to send and
> receive the DHCP messages.
> 
> It is also not as simple as saving two messages.
> Consider this case: the MN needs to set up an additional IPSec child
> SA to protect the data traffic.
> This is done after the IPSec SA is performed. With the DHCP-PD, if the
> MN performs the Child SA
> establishment for the traffic from/to itself before the DHCP-PD, then
> after DHCP-PD, the MN needs to
> set up another child SA to protect the traffic to/from the MNNs. If
> the MN performs the Child SA
> establishment for the traffic from/to itself after the DHCP-PD, this
> means the commnucation between
> MN and CN is delayed. therefore, when the MN handovers from a PMIP
> domain to a target access network
> using CMIP. DHCP-PD would result in more delay.
> With the IKE-PD, since the MN knows its HoA and MNP at the same time,
> it can immediately set
> up one Child SA to protect the traffic from/to itself and the MNNs.
> 
> Do I miss something? Thanks.
> 
> Sincerely,
> fan
> 
> >
> > Alex
> >
> >>
> >> Thanks.
> >>
> >> Sincerely, fan
> >>
> >>
> >>
> >>
> >> On Tue, Jun 10, 2008 at 12:11 AM, Julien Laganier
> >> <[email-masked]> wrote:
> >>>
> >>> On Friday 06 June 2008, Frank Xia wrote:
> >>>>
> >>>> Hi Fan, Ryuji and other colleagues.
> >>>>
> >>>> Agreed.
> >>>>
> >>>> IMHO,There are two ways for prefix delegation in Nemo, that is,
> >>>> overlay and integrated modes.
> >>>>
> >>>> DHCP based PD is a overlay solution which introduce 
> redundancy while
> >>>> trying to reduce impact on NEMO itself.
> >>>>
> >>>> I favor the integrated mode in which Prefix Delegation is
> >>>> integrated into NEMO operations because prefix management is an
> >>>> integrated part of NEMO.   PMIPv6 follow the same philosophy.
> >>>
> >>> Hello Frank et. al.
> >>>
> >>> <WG chair hat ON>
> >>>
> >>> We are not going to challenge your technical arguments. We have a
> >>> WG consensus on developing *one* solution based on *DHCPv6 PD*, so
> >>> this is discussion is in our opinion out of scope since there are
> >>> no reasons to revert the WG consensus.
> >>>
> >>> The question at this stage is whether we want to make the only
> >>> proposal on NEMO prefix delegation based on DHCPv6 PD a WG draft.
> >>>
> >>> Thanks in advance for your understanding.
> >>>
> >>> Regards,
> >>>
> >>> -- julien & marcelo, MEXT chairs
> >>>
> >>>
> >> _______________________________________________ MEXT mailing list
> >> [email-masked] https://www.ietf.org/mailman/listinfo/mext
> >>
> >
> >
> > 
> ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email 
> Security System.
> > For more information please visit http://www.messagelabs.com/email
> > 
> ______________________________________________________________________
> >
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Jun 2008 11:59:34 +0200

Hi Behcet:

I think we really have to serialize: at the moment the consensus is one and only one draft, that is based on DHCP-PD. I would not play on words on what that consensus means in a lawyer fashion. Honestly I think it's pretty clear. 

In this thread, Vijay is referring to the NEMO based solution, and I agree with him that it would be the proper alternate. NEMO had reached a consensus of supporting both ways but having 2 solutions seemed to cause delay to the advancement of any solution. 

Once the DHCP based solution is advanced enough, I hope we consider deployements that require a different or simpler solution, and at that time, we might want to couple your work on the back end with http://tools.ietf.org/id/draft-ietf-nemo-prefix-delegation-02.txt. That would make a lot of sense to me.

But for the time being, we need to answer the chairs about supporting a proposed draft for WG doc.

Pascal
________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: mardi 10 juin 2008 21:19
To: Vijay Devarapalli
Cc: [email-masked]
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hi Vijay,
  Pls. see inline.

Regards,

Behcet
----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: fan zhao <[email-masked]>; Alexandru Petrescu <[email-masked]>
Cc: Julien Laganier <[email-masked]>; [email-masked]
Sent: Tuesday, June 10, 2008 1:22:20 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

Hello Fan,

The mobile

Vijay