Subject: Re: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 May 2010 09:31:42 -0700 (PDT)

Hi Alex,

  Sorry for my late reply.

> Hi Behcet and thanks for the pointer.

>IMHO.

>It is not clear to me 
> whether the 2007 draft you cited
(draft-ietf-nemo-prefix-delegation-02) 
> addresses the problems listed in
> the recent discussion.

> That draft 
> uses BU extensions (new BU bit) as part of the MIPv6
protocol.  I 
> disagree with it, because DHCPv6-PD is better than DHCPv6
at allocating 
> prefixes, and already implemented, and already used.  I do
not see why 
> extending MIPv6 to allocate prefixes.

> To me (IMHO) a good solution would 
> use DHCPv6-PD non-encapsulated,
> between MR and AR-Relay.

Absolutely. This was missing in draft-ietf-nemo-prefix-delegation-02. That is the reason why we redesigned it using DHCPv6 PD, but using it from HA as RR to the delegating router 
as in 
http://tools.ietf.org/html/draft-sarikaya-mext-bu-prefixdelegation-02

> Generally 
> speaking, if I had to describe the need:

>-need to allocate dynamically an 
> MNP to the MR.
-need to perform it securely: some of the risks are: (1) an MR 
> could
  falsely request a prefix prior to having identified itself to HA 
> using
  its MIP6 keys, (2) the HA may miss the allocated MNP from its 
> Prefix
  Table and thus couldn't ensure the MNP in the explicit mode BU 
> is
  legitimate.
>-need to reuse the NEMOv6 MIP6 protocol 
> unmodified.
>-need to reuse existing protocols naturally fit for prefix 
> allocation.
>-reliability: need to allocate a prefix to MR even when the 
> MIPv6
 > implementation fails; this is good in order to allow in-mobile 
> network
  communication between LFNs; MIP6 may fail when the MR is 
> disconnected,
  and when MIP traffic blocked by firewalls in the access 
> networks.
-need to inform the HA about the MNP allocated to the mobile 
> network,
  such that NEMOv6 MIP6 implementation works unmodified, and is 
> able to
  check the presence of the prefix in the NEMOv6 Prefix 
> Table.

I think we need a fresh look into this problem and what you have above could be a good starting point.

It is a difficult problem.

Regards,

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 May 2010 18:42:46 +0200

Le 05/05/2010 18:31, Behcet Sarikaya a écrit :
>> It is not clear to me whether the 2007 draft you cited
>> addresses the problems listed in the recent discussion.
>
>> That draft uses BU extensions (new BU bit) as part of the MIPv6
> protocol.  I
>> To me (IMHO) a good solution would use DHCPv6-PD non-encapsulated,
>> between MR and AR-Relay.
>
>
> Absolutely. This was missing in draft-ietf-nemo-prefix-delegation-02.
> That is the reason why we redesigned it using DHCPv6 PD, but using it
> from HA as RR to the delegating router as in

But this draft still extends BU/BAck to do PD on MR (it's in the title),
instead of using DHCPv6. I do not agree with this.

This draft does use DHCPv6-PD for HA as RR (DHCP Requesting Router, not
"Return Routability" nor "Resource Records" :-)  I agree with this in
general, although not sure whether HA could be RR if MR were too -
better have a single RR in the picture.

>> Generally speaking, if I had to describe the need:
>
>> -need to allocate dynamically an MNP to the MR.
>> -need to reuse the NEMOv6 MIP6 protocol unmodified. -need to reuse
>>  existing protocols naturally fit for prefix allocation.
>> -reliability: need to allocate a prefix to MR even when the MIPv6
>> implementation fails; this is good in order to allow in-mobile
>> network

WEll we have a WG item, suffices it to change it according to remarks on
the WG list.  Or according to its consensus which should yet to be found.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 May 2010 09:58:35 -0700 (PDT)

> That is the reason why we 
> redesigned it using DHCPv6 PD, but using it
> from HA as RR to the 
> delegating router as in
> 

>But 
> this draft still extends BU/BAck to do PD on MR (it's in the title),
instead 
> of using DHCPv6. I do not agree with this.

This draft does use DHCPv6-PD 
> for HA as RR (DHCP Requesting Router, not
"Return Routability" nor "Resource 
> Records" :-)  I agree with this in
general, although not sure whether HA 
> could be RR if MR were too -
better have a single RR in the 
> picture.

Sorry, I misunderstood your comments. I was under the impression that the main problem with the nemopd draft is because MR which is a moving node is RR. I think such an architecture intrinsically creates lots of problems that you mentioned in your mails. 
If you don't agree with this then we don't need to argue more.

Regarding extending BU/BA for DHCPv6 PD, actually no, the extension needed has already been defined in RFC 5213.

> WEll we have a WG 
> item, suffices it to change it according to remarks on
the WG list.  Or 
> according to its consensus which should yet to be 
> found.

Good luck!

Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 May 2010 19:14:17 +0200

Le 05/05/2010 18:58, Behcet Sarikaya a écrit :
>
>
>
>
>> Absolutely. This was missing in
>> draft-ietf-nemo-prefix-delegation-02. That is the reason why we
>> redesigned it using DHCPv6 PD, but using it from HA as RR to the
>> delegating router as in
>>
But this draft still extends BU/BAck to do PD on MR (it's in the
>> title),
> Sorry, I misunderstood your comments. I was under the impression
> that the main problem with the nemopd draft is because MR which is a
> moving node is RR. I think such an architecture intrinsically
> creates lots of problems that you mentioned in your mails. If you
> don't agree with this then we don't need to argue more.
>
> Regarding extending BU/BA for DHCPv6 PD, actually no, the extension
> needed has already been defined in RFC 5213.

Strange, PMIPv6...

I am not sure the intention of using "prefix-per-MN" of PMIPv6 could
qualify as assigning an MNP to an MR...

>> WEll we have a WG item, suffices it to change it according to
>> remarks on the WG list.  Or according to its consensus which should
>> yet to be found.
>
> Good luck!

Sure let's see :-)

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 May 2010 11:30:52 -0700 (PDT)

----- Original Message ----
> From: Alexandru Petrescu <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: Behcet Sarikaya <[email-masked]>; "Laganier, Julien" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wed, May 5, 2010 12:14:17 PM
> Subject: Re: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO
> 
But 
> this draft still extends BU/BAck to do PD on MR (it's in the
>> 
> title),
> instead
> Sorry, I 
> misunderstood your comments. I was under the impression
> that the main 
> problem with the nemopd draft is because MR which is a
> moving node is 
> RR. I think such an architecture intrinsically
> creates lots of problems 

> "prefix-per-MN" of PMIPv6 could
qualify as assigning an MNP to an 
> MR...

Alex, pls read the draft. It is using HNP option defined in 5213 to carry MNPs. I defined a few flags for HNP to facilitate the PD.

Of course some extensions are needed :-).

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 5 May 2010 12:32:22 -0700

Behcet,

<WG chair hat on>

Behcet Sarikaya wrote:
> [...] 

First of all, as you can see from the subject line, this thread was specifically started (by Carlos IIRC) to resolve the issue of "DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO" when DHCPv6 PD is used by a MR, as described in draft-ietf-mext-nemo-pd, a draft for which we are currently in WGLC.

You seems to be discussing something different, so I'd be grateful if you could kindly change the subject line when taking an ongoing discussion towards a different topic, especially when that discussion is trying to close an issue that was brought on during a WGLC.

> [...]

Second, while I can agree with you that it is a difficult problem, I'd like to highlight the fact that suggesting to take a fresh look at a problem for which the WG has had a documented solution under discussion for the last two years and which is currently in WGLC is not helpful for this WG to solve this difficult problem.

So to be clear, we are NOT taking a fresh look at this.

If you have constructive comments to contribute as part of the WGLC, you are very welcome to do so.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 5 May 2010 13:06:03 -0700

Alex, all,

<WG chair hat on>

Alexandru Petrescu wrote:
> Well we have a WG item, suffices it to change it according to remarks
> on the WG list.  Or according to its consensus which should yet to be
> found.

Just to make sure we are all on the same page here and we have no misunderstanding: 

The current WG document, draft-ietf-nemo-pd is a WG item and as such the standing proposal that has rough consensus, until proven otherwise.

We are now in WGLC where we are trying to address final comments before the draft is sent to IESG.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 May 2010 09:41:47 +0200

Hello Julien,

Le 05/05/2010 22:06, Laganier, Julien a écrit :
>> Well we have a WG item, suffices it to change it according to
>> remarks on the WG list.  Or according to its consensus which
>> should yet to be found.
>
> The current WG document, draft-ietf-nemo-pd is a WG item and as such
> the standing proposal that has rough consensus, until proven
> otherwise.
>

I have sent previously substantive comments to this draft.  I disagree
with MR running both a DHCP Relay _and_ a DHCP Client.  There are
several issues with this, I exposed in previous emails: impossibility to
inform HA about the allocated MNP (HA needs it for NEMO protocol),
insecurity of the protocol, more.

I proposed an alternative solution where the MR is only a DHCP Client
(Requesting Router) and not a Relay.  This may have the inconvenient
that the AR does not know the DHCP Server address.  Or it could.

I hope these issues solved during WGLC.

Alex

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 6 May 2010 16:42:43 -0700

Alex,

I was not commenting on your WGLC comments, just highlighting that we do not take a fresh look since the approach that we have is the one that has rough consensus until proven otherwise.

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 May 2010 12:29:52 -0700 (PDT)

Julien,
 First of all I was responding to the comments made by Alex and then the discussions took us to this path :-).

Myself and some other people like Arnaud have been expressing similar concerns on ML and as you said the consensus was very rough. 

You should also take into account the fact that previously both approaches were given WG draft status. 

Maybe Mext should have taken DT approach to resolve this difficult problem. My 2 cents.

Regards,

Behcet

----- Original Message ----
> From: "Laganier, Julien" <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>; Alexandru Petrescu <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Wed, May 5, 2010 2:32:22 PM
> Subject: RE: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO
> 
> Behcet,

<WG chair hat on>

Behcet Sarikaya wrote:
> from HA as RR to the 
> delegating router

First 
> of all, as you can see from the subject line, this thread was specifically 
> started (by Carlos IIRC) to resolve the issue of "DHCPv6 relay co-located with 
> the DHCPv6 client at the MR for DHCPv6PD in NEMO" when DHCPv6 PD is used by a 
> MR, as described in draft-ietf-mext-nemo-pd, a draft for which we are currently 
> in WGLC.

You seems to be discussing something different, so I'd be 
> grateful if you could kindly change the subject line when taking an ongoing 
> discussion towards a different topic, especially when that discussion is trying 
> to close an issue that was brought on during a WGLC.

> 
> [...]
>  
> I think we need a fresh look into this problem 
> and what you have
> above could be a good starting point.
> 
> 

Second, while I can agree with you that it is 
> a difficult problem, I'd like to highlight the fact that suggesting to take a 
> fresh look at a problem for which the WG has had a documented solution under 
> discussion for the last two years and which is currently in WGLC is not helpful 
> for this WG to solve this difficult problem.

So to be clear, we are NOT 
> taking a fresh look at this.

If you have constructive comments to 
> contribute as part of the WGLC, you are very welcome to do so.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 7 May 2010 14:41:00 -0700

Behcet,

Behcet Sarikaya wrote:
> 
> Julien,
>  First of all I was responding to the comments made by Alex and then
> the discussions took us to this path :-).
> 
> Myself and some other people like Arnaud have been expressing similar
> concerns on ML and as you said the consensus was very rough.

I did not say that. 

There was rough consensus to develop only one solution, and rough consensus was to base that solution on the use of DHCPv6 Prefix Delegation, and that solution has been on the table for two years. 
 
> approaches were given WG draft status.

No I should not -- see above.

> Maybe Mext should have taken DT approach to resolve this difficult

I do not understand how this is relevant to this WGLC. Thank you.

--julien