Subject: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

From: Yungui Wang <[email-masked]>
Date: Thu, 11 Dec 2008 10:19:10 +0800

Hello

Here is one comment about using MR-HA tunnel for DHCP-PD.

In this draft, the MR registration processing needs 3 round trip between MR and HA.
i. BU to HA; (getting and binding MR_HoA)
ii. DHCPv6 message over MR-HA tunnel. (getting MNP)
iii. BU to HA; (binding MNP)
While, if PD is combined within BU, it is only 1 round trip.

>From implementation of viewpoint, the later seems well done prior of the former. Maybe I have lost something, can anyone tell me the story why we gave up the latter in the new version? Thanks.

B.R.
Yungui

----- Original Message ----- 
  From: marcelo bagnulo braun 
  To: mext ; Julien Laganier ; Ralph Droms 
  Sent: Tuesday, November 04, 2008 8:02 PM
  Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt

  Hi,

  We now start the WGLC for:

  DHCPv6 Prefix Delegation for NEMO
  draft-ietf-mext-nemo-pd-01.txt

  http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-01.txt

  Please send comments about the draft till the November 19.

  Regards, Julien and marcelo

  _______________________________________________
  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: Julien Laganier <[email-masked]>
Date: Thu, 11 Dec 2008 10:50:19 +0100

We had this discussion for a long time abd it has concluded some time 
ago already: WG consensus is to use DHCP PD. 

(w/o questioning the value of optimizing RTTs for a procedure which 
isn't in a critical path, e.g., handover)

--julien

On Thursday 11 December 2008, Yungui Wang wrote:
> In this draft, the MR registration processing needs 3 round trip
> between MR and HA. i. BU to HA; (getting and binding MR_HoA)
> From implementation of viewpoint, the later seems well done prior of
> the former. Maybe I have lost something, can anyone tell me the story
> why we gave up the latter in the new version? Thanks.
>
> B.R.
> Yungui
>
>

-- 
--julien

[ New email address: [email-masked] ]
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 11 Dec 2008 17:26:33 +0100

Hi Julien and Yungui,

Actually, it's not only 3 round trip and is not optimization problem..
This is a big issue of DHCP-PD.

Let me explain the issue clearly.

According to the NEMO-DHCP-PD spec, before receiving a prefix,
a mobile router must create a tunnel with its HA.

For this purpose, the mobile router needs to act as a RFC3775
compliant mobile host before starting DHCP-PD.  Why? If there is no
prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag set) to
its Home Agent. If there is no valid prefix for the mobile router, HA
returns BA with "Invalid Prefix" status value which is treated as the
fatal error in RFC3963.

Well, RFC3963 allows for a mobile router to act as a mobile host, but
we didn't assume that a mobile router switches its mode between
RFC3775-mobile-host and RFC3963-mobile-router dynamically.

For instance, RFC3963 said in section 6.2,
"If the Home Agent has a valid binding cache entry for the Mobile
Router, and if the Binding Update has the Mobile Router Flag (R) set
to a value different from that in the existing binding cache entry,
then the Home Agent MUST reject the Binding Update and send a Binding
Acknowledgement with status set to 139 (Registration type change
disallowed). However, if the Binding Update is a de-registration
Binding Update, the Home Agent ignores the value of the Mobile Router
Flag (R)."

At the end, how the boostrapping goes?

1. MR acts as a MN and sends MIP6-BU (Rflag unset) to establish a
    tunnel for DHCP-PD
2. MR starting DHCP-PD
3. After DHCP-PD completion, MR de-registers the RFC3775-binding
4. MR sends NEMO-BU (R-flag finally set) for its mobile network prefix
    acquired by DHCP-PD

I don't think this is right way to go....

I now changed my mind that the use of BU/BA is more straightforward
for NEMO prefix delegation.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 11 Dec 2008 17:45:33 +0100

On 2008/12/11, at 17:36, Romain KUNTZ wrote:

> Hi Ryuji,
>
> On 2008/12/11, at 17:26, Ryuji Wakikawa wrote:
> I'd say the MR still sends a BU with the R-flag set and without the  
> MNP option, which will be considered as registration in Implicit  
> mode by the HA.

Implicit mode requires some mapping between a mobile network prefix  
and a mobile router.

       Implicit:

          In this mode, the Mobile Router does not include a Mobile
          Network Prefix Option in the Binding Update.  The Home Agent
          can use any mechanism (not defined in this document) to
          determine the Mobile Network Prefix(es) owned by the Mobile
          Router and to set up forwarding for the Mobile Network.  One
          example would be manual configuration at the Home Agent  
mapping
          the Mobile Router's Home Address to the information required
          for setting up forwarding for the Mobile Network.

In RFC3963, we didn't consider a MR who doesn't  have any mobile  
network prefix sends BU with R-flag set.
In implicit mode, if there is no  prefix for the MR, HA will reject  
the BU.

regards,
ryuji

> Cheers,
> romain

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 11 Dec 2008 17:49:02 +0100

Romain

One more comment.

The implicit and explicit modes cannot be switched dynamically, neither.

Section 5.2
    A Mobile Router MUST implement at least one mode and MAY implement
    both.  In the latter case, local configuration on the Mobile Router
    decides which mode to use.  This is out of scope for this document.

    If the Mobile Router Flag is set, the Home Registration Flag (H)  
MUST
    be set.

    If the Mobile Router has a valid binding cache entry at the Home
    Agent, subsequent Binding Updates for the same Home Address should
    have the same value as the value in the binding cache for the Mobile
    Router Flag (R).  In explicit mode, the Mobile Router MUST include
    prefix information in all Binding Updates, including those sent to
    refresh existing binding cache entries, if it wants forwarding
    enabled for the corresponding Mobile Network Prefixes.

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Dec 2008 18:30:42 +0100

> a mobile router must create a tunnel with its HA.

Not sure about this necessity?  Where does this nemo-dhcp-pd draft say so?

If one considers the MR to co-locate a DHCP Relay with a DHCP Client 
(section 3.3) then the Relay would unicast non-tunnelled with the 
HA-DHCPServer (not multicast, and not tunnel) the DHCP messages.

> its Home Agent.

Well the MR can send a BU with R-flag set without having a prefix 
allocated to it via DHCP-PD, by considering the NEMO implicit mode.  IT 
is sufficient for the HA to know the prefix it is allocated to that MR.

It is obvious that we disagree on the sequence of the exchanged messages 
(DHCP, BU/BAck) and I think we need to draw a diagram with the message 
exchanges that we consider.  I could draw mine.

Alex

  If there is no valid prefix for the mobile router, HA
>>>  Regards, Julien and marcelo

______________________________________________________________________
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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Dec 2008 18:34:45 +0100

> between MR and HA. i. BU to HA; (getting and binding MR_HoA)

I think there's an error.  RFC3775 MN and RFC3963 MR will not get any
HoA with the BU, but yes indeed will bind that HoA to its current CoA,
at the HA.

> ii. DHCPv6 message over MR-HA tunnel. (getting MNP)

I'm not sure the DHCPv6 messages need to happen through the tunnel, or
maybe straight one-header DHCP messages.

> iii. BU to HA; (binding MNP) While, if PD is combined within BU, it
> is only 1 round trip.

I see the optimization necessity, but as Julien and others already said
I agree this would not need an optimization perspective since it happens
at the beginning ('bootstrapping') unique phase, not upon each handover,
thus not on a supposedly critical path.

>  the former. Maybe I have lost something, can anyone tell me the
> story why we gave up the latter in the new version? Thanks.

I'm interested in implementation.  Any implementation experience one may
have of running DHCPv6 PD and Mobile IPv6/NEMOv6 is great to be reported
here, please do so - what would your (someone's) implementation suggests?

Alex

> B.R. Yungui
> *From:* marcelo bagnulo braun <mailto:[email-masked]> *To:* mext
> <mailto:[email-masked]> ; Julien Laganier 
> <mailto:[email-masked]> ; Ralph Droms 
> <mailto:[email-masked]> *Sent:* Tuesday, November 04, 2008 8:02 PM 
> *Subject:* [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt
> 
> Hi,
> 
> DHCPv6 Prefix Delegation for NEMO draft-ietf-mext-nemo-pd-01.txt
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] <mailto:[email-masked]> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mext

---

From: "fan zhao" <[email-masked]>
Date: Thu, 11 Dec 2008 18:30:03 -0800

Hi Alex,

Please see below.

> Not sure about this necessity?  Where does this nemo-dhcp-pd draft say so?
Please see section 3.2.  Use of MR-HA tunnel for DHCPv6 messages.

> Well the MR can send a BU with R-flag set without having a prefix allocated
> to it via DHCP-PD, by considering the NEMO implicit mode.  IT is sufficient
> for the HA to know the prefix it is allocated to that MR.
I think Ryuji has addressed this in his previous emails.

> exchanges that we consider.  I could draw mine.
Please do. Thanks a lot.

Sincerely,
fan

---

From: Yungui Wang <[email-masked]>
Date: Fri, 12 Dec 2008 10:43:24 +0800

Hi Ryuji and all

Thanks for your detailed explanation.

My concern is MNP and MR_HoA can be assigned to MR at the same time, special for the aggregated prefix. While, in the mip-split case, the HoA is assigned to MR through BU/BA procedure.  Thus, the MNP assigned through BU/BA procedure can be supported too. That's my simple logic. 
Complying with rfc3775 which allows the HoA assignment via either split or integrated bootstrapping,  maybe we could consider to fix rfc3963 and let it more open - not limit which mechanism used for PD. 

B.R.
Yungui

----- Original Message ----- 
  From: Ryuji Wakikawa 
  To: Julien Laganier 
  Cc: Yungui Wang ; mext ; Sri Gundavelli ; Vijay Devarapalli 
  Sent: Friday, December 12, 2008 12:26 AM
  Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

  Hi Julien and Yungui,

  ryuji

---

From: "fan zhao" <[email-masked]>
Date: Thu, 11 Dec 2008 18:49:19 -0800

Hi Yungui,

The HoA is assigned to the mobile node during the IPsec
SA establishment procedure. Please see RFC 4877 and
RFC 5026. I agree with you that it is logical to assign
the MNP and MR_HoA to MR at the same time.

Sincerely,
fan

On Thu, Dec 11, 2008 at 6:43 PM, Yungui Wang <[email-masked]> wrote:
> My concern is MNP and MR_HoA can be assigned to MR at the same time, special
> for the aggregated prefix. While, in the mip-split case, the HoA is assigned
> to MR through BU/BA procedure.  Thus, the MNP assigned through BU/BA
> procedure can be supported too. That's my simple logic.
> Complying with rfc3775 which allows the HoA assignment via either split or
> integrated bootstrapping,  maybe we could consider to fix rfc3963 and let it
> more open - not limit which mechanism used for PD.
>
>
> B.R.
> Yungui
>

---

From: Yungui Wang <[email-masked]>
Date: Fri, 12 Dec 2008 11:39:19 +0800

Thanks for your pointed error and welcome your clear PD information flow w/o tunnel.

B.R.
Yungui

  ----- Original Message ----- 
  From: Alexandru Petrescu 
  To: Yungui Wang 
  Cc: marcelo bagnulo braun ; mext ; Julien Laganier ; Ralph Droms 
  Sent: Friday, December 12, 2008 1:34 AM
  Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

  Alex

---

From: Julien Laganier <[email-masked]>
Date: Fri, 12 Dec 2008 11:52:03 +0100

Hello Ryuji,

On Thursday 11 December 2008, Ryuji Wakikawa wrote:
>
> Actually, it's not only 3 round trip and is not optimization
> problem.. This is a big issue of DHCP-PD.
>

There would be no issue at all with the MR being configured as both a 
DHCP client and relay, and the HA as a DHCP server: the DHCP messages 
would be unicasted bewteen MR and HA without tunneling.

I thought that was what we agreed on and I'm seeing now the draft still 
talks about multicasting into the tunnel...

I think the tunneling story (Sec. 3.2) should be removed from the draft, 
and the DHCP relay configuration mode made the mandatory method for a 
NEMO MR to obtain a prefix dynamically, i.e. put a couple of SHOULD 
words here and there in Sec. 3.3.

--julien

---

From: Romain KUNTZ <[email-masked]>
Date: Fri, 12 Dec 2008 13:25:16 +0100

Hi,

> would be unicasted bewteen MR and HA without tunneling.

Do you then suggest to do the prefix delegation procedure before the  
NEMO registration? I think this raises multiple issues.

First the DHCP relay would use the CoA as source address of the  
message, but the DHCPv6 server may need to know the MR's HoA if it is  
configured with static assignment of the MNP.

Furthermore, once the MR registers its allocated MNP to the HA, the HA  
cannot verify that the MNP that is in the BU was the one that the DHCP  
server allocated to that MR. To do so, the DHCP server would need to  
give the HoA/MNP pair to the HA, so that it can perform a check at  
registration.

By using the MR-HA tunnel, the relay message is sent using the HoA.  
Also, the use of an IPsec tunnel will secure the message exchange  
between the MR and the HA.

As for the issues raised by Ryuji, I'll reply in another mail.

Cheers,
romain

---

From: Romain KUNTZ <[email-masked]>
Date: Fri, 12 Dec 2008 13:41:02 +0100

Hi Ryuji,

>         Router and to set up forwarding for the Mobile Network.  One

We have an implementation of NEMO+DHCPv6PD, and here the "mechanism to  
determine the Mobile Network Prefix(es) owned by the Mobile Router" is  
a simple message from the DHCPv6 server to the HA that advertises the  
MNP/HoA pair to the HA.

This paragraph does not say that such information must be retrieved at  
the home registration (but actually this is stated later in the  
RFC :-) see below)

>         for setting up forwarding for the Mobile Network.

As stated in the sentence, This is an example so it does not exclude  
DHCPv6PD.

> the BU

 From section 6.2:

[...]
   -  If there is no option in the Binding Update carrying prefix
       information, the Home Agent uses manual pre-configured  
information
       to determine the prefixes assigned to the Mobile Router and to  
set
       up forwarding for the Mobile Network.  If there is no information
       that the Home Agent can use, it MUST reject the Binding Update  
and
       send a Binding Acknowledgement with status set to 143 (Forwarding
       Setup failed).
[...]

In our implementation, at home registration the HA checks with the  
DHCP server if a prefix is available for this HoA. If so, registration  
is done (but not forwarding). Once the DHCPv6 server has delegated a  
prefix to the MR, it informs the HA that it can setup forwarding for  
the delegated MNP.

The RFC does not explicitely says that forwarding must be setup at  
home registration, but it says that the HA must check wether such  
information is available.

What is really missing in the NEMO DHCPv6PD draft is IMHO details on  
what (and how) the HA and DHCPv6 server need to agree.

Cheers,
romain

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 12 Dec 2008 10:34:44 -0800 (PST)

Hi Romain,

________________________________
From: Romain KUNTZ <[email-masked]>
To: Ryuji Wakikawa <[email-masked]>
Cc: Julien Laganier <[email-masked]>; mext <[email-masked]>
Sent: Friday, December 12, 2008 6:41:02 AM
Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

Hi Ryuji,

On 2008/12/11, at 17:45, Ryuji Wakikawa wrote:
>> I'd say the MR still sends a BU with the R-flag set and without the MNP option, which will be considered as registration in Implicit mode by the HA.
> 
> Implicit mode requires some mapping between a mobile network prefix and a mobile router.

>         Router and to set up forwarding for the Mobile Network.  One

We have an implementation of NEMO+DHCPv6PD, and here the "mechanism to determine the Mobile Network Prefix(es) owned by the Mobile Router" is a simple message from the DHCPv6 server to the HA that advertises the MNP/HoA pair to the HA.

[behcet] I am curious what is this message? Can you please give more details?

This paragraph does not say that such information must be retrieved at the home registration (but actually this is stated later in the RFC :-) see below)

>         example would be manual configuration at the Home Agent mapping

As stated in the sentence, This is an example so it does not exclude DHCPv6PD.

> In RFC3963, we didn't consider a MR who doesn't  have any mobile network prefix sends BU with R-flag set.
> In implicit mode, if there is no  prefix for the MR, HA will reject the BU

[...]
  -  If there is no option in the Binding Update carrying prefix
      information, the Home Agent uses manual pre-configured information
      to determine the prefixes assigned to the Mobile Router and to set
      up forwarding for the Mobile Network.  If there is no information
      that the Home Agent can use, it MUST reject the Binding Update and
      send a Binding Acknowledgement with status set to 143 (Forwarding
      Setup failed).
[...]

In our implementation, at home registration the HA checks with the DHCP server if a prefix is available for this HoA. If so, registration is done (but not forwarding). Once the DHCPv6 server has delegated a prefix to the MR, it informs the HA that it can setup forwarding for the delegated MNP.

[behcet] I
have a question: If HA were a requesting router (not a delegating
router as in Nemo-pd draft), how would you change your implementation
architecture? 
I have a feeling that you are using HA as a requesting
router . If HA is a requesting router, all you need at the HA is DHCP Client (and possibly colocated with relay if the delegating router is not on-link) 
So I believe, in fact you are agreeing with Ryuji.

Regards,

Behcet

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 15 Dec 2008 10:45:58 +0100

Hi Behcet,

On 2008/12/12, at 19:34, Behcet Sarikaya wrote:
> We have an implementation of NEMO+DHCPv6PD, and here the "mechanism  
> to determine the Mobile Network Prefix(es) owned by the Mobile  
> Router" is a simple message from the DHCPv6 server to the HA that  
> advertises the MNP/HoA pair to the HA.
>

The DHCPv6 server is co-located with the HA on the same computer. I  
use a UNIX socket for inter-processus communication with a simple TLV  
message.

> DHCP server if a prefix is available for this HoA. If so,  
> registration is done (but not forwarding). Once the DHCPv6 server  
> has delegated a prefix to the MR, it informs the HA that it can  
> setup forwarding for the delegated MNP.
>
> [behcet] I have a question: If HA were a requesting router (not a  
> delegating router as in Nemo-pd draft), how would you change your  
> implementation architecture?
> I have a feeling that you are using HA as a requesting router .

In our testbed, the HA is a delegating router, and the client & relay  
are located at the HA. DHCP messages are exchanged through the MR-HA  
tunnel.

If the HA were a requesting router, I guess the testbed,  
implementation and interaction with the mobility daemon would be  
completely different, so I can't really tell how I would change the  
current one.

> If HA is a requesting router, all you need at the HA is DHCP Client  
> (and possibly colocated with relay if the delegating router is not  
> on-link)

I guess you refer to the solution exposed in draft-sarikaya-mext- 
prefix-delegation? This one suppose that the prefix delegation at the  
MR happens with BU/BAck messages, which is not the case in our  
implementation.

Note that I do not discuss here which solution is the best, but only  
present feedback from implementation of one of the solution. If I had  
chosen the delegation through the BU/BAck, I would certainly have  
coupled it with a DHCP server as you describe in your draft.

> So I believe, in fact you are agreeing with Ryuji.

Agreeing on what point ?

Regards,
-- 
Romain KUNTZ
[email-masked]
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Dec 2008 12:28:12 +0100

Ryuji Wakikawa wrote:
>>> compliant mobile host before starting DHCP-PD.  Why? If there is
>>> no prefix, the mobile router cannot sends a NEMO-BU (i.e. R-flag
>>> set) to its Home Agent. If there is no valid prefix for the
>>> mobile router, HA returns BA with "Invalid Prefix" status value
>>> which is treated as the fatal error in RFC3963.
>> 

For clarification: yes the Implicit mode requires a mapping between the
Mobile Network Prefix and the Home Address of the Mobile Router.  This
mapping exists already in the routing table of (at least) the HA,
otherwise HA can't reach the MR when MR at home.

It is not a mapping that should be found or created, it exists already.

Alex

> 
> Implicit:
> 
> In this mode, the Mobile Router does not include a Mobile Network
> Prefix Option in the Binding Update.  The Home Agent can use any
> mechanism (not defined in this document) to determine the Mobile
> Network Prefix(es) owned by the Mobile Router and to set up
> forwarding for the Mobile Network.  One example would be manual
> configuration at the Home Agent mapping the Mobile Router's Home
> Address to the information required for setting up forwarding for the
> Mobile Network.
> 
> 
> network prefix sends BU with R-flag set. In implicit mode, if there
> is no  prefix for the MR, HA will reject the BU.
> 
> regards, ryuji
> 
> 
>> 
>> 
>> Cheers, romain
>> 
>> 
>> 
>>>> We had this discussion for a long time abd it has concluded
>>>> some time ago already: WG consensus is to use DHCP PD.
>>>> 
>>>> (w/o questioning the value of optimizing RTTs for a procedure
>>>> which isn't in a critical path, e.g., handover)
>>>> 
>>>> --julien
>>>> 
>>>>> In this draft, the MR registration processing needs 3 round
>>>>> trip between MR and HA. i. BU to HA; (getting and binding
>>>>> MR_HoA) ii. DHCPv6 message over MR-HA tunnel. (getting MNP) 
>>>>> iii. BU to HA; (binding MNP) While, if PD is combined within
>>>>> BU, it is only 1 round trip.
>>>>> 
>>>>> From implementation of viewpoint, the later seems well done
>>>>> prior of the former. Maybe I have lost something, can anyone
>>>>> tell me the story why we gave up the latter in the new
>>>>> version? Thanks.
>>>>> 
>>>>> B.R. Yungui
>>>>> 
>>>>> 
>>>>> ----- Original Message ----- From: marcelo bagnulo braun To:
>>>>> mext ; Julien Laganier ; Ralph Droms Sent: Tuesday, November
>>>>> 04, 2008 8:02 PM Subject: [MEXT] WGLC for
>>>>> _______________________________________________ MEXT mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- --julien
>>>> 
>>>> _______________________________________________ MEXT mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Dec 2008 12:28:40 +0100

> The implicit and explicit modes cannot be switched dynamically, neither.

Yes, I fully agree. (just for clarification).

Alex

>    If the Mobile Router Flag is set, the Home Registration Flag (H) MUST
>    be set.
> 
>> MNP option, which will be considered as registration in Implicit mode 
>> by the HA.
>>
>> Cheers,
>> romain
>>
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Dec 2008 12:52:54 +0100

> Please see section 3.2.  Use of MR-HA tunnel for DHCPv6 messages.

Well, yes in a sense, but it depends.

The DHCPv6 messages that have dst a multicast address are actually only 
one - the DHCPv6 Solicit I believe.  It is multicasted when the DHCP 
Client doesn't know the address of the DHCP Server.  Or, if we consider 
the HA to be the DHCP Server, and if the MR has already discovered the 
address of the HA (maybe with DHAAD) then this multicasted Solicit isn't 
necessary - DHCPv6 Request/Reply exchanges are sufficient, and they're 
unicasted.

[...]

>> exchanges that we consider.  I could draw mine.

HEre's a diagram of messages exchanged for MR and HA, for prefix 
delegation, which I believe makes some sense at least to me.  If you 
think DHAAD/MPD shouldn't be used then I may agree, but I don't know the 
names of the DNS messages.

If somebody else agrees please say so, or otherwise say why not, or draw 
a separate diagrap - we hopefully could join them together.

Problem: MR needs to find out its HoA and its Mobile Network Prefix.

            MR                               HA
             |     DHAAD Address Request      |
             |-------------------------------o| (anycast'ed)
             |         DHAAD Reply            |
             |<------------------------------ |
             |     Mobile Prefix Solicitation |
             |------------------------------->|
             |   Mobile Prefix Advertisement  |
             |<-------------------------------|
  (MR forms  |                                |
   its HoA)  |        DHCPv6 Request          |
             |------------------------------->| (unicast'ed,
             |    DHCPv6 Reply (contains MNP) |  non-tunneled)
             |<-------------------------------|
  (MR knows  |                                |
   its MNP)  |    BU R-flag (eventually MNP)  |
             |------------------------------->|
             |      BAck                      |
             |<------------------------------ |
             |                                |
             | ------------------------------ |
             |<..............................>| (tunnelled traffic)
             | ------------------------------ |
             |                                |
             |                                |
             |                                |
             |                                |
             |                                |
             |                                |
             |                                |
             |                                |
             |                                |

Thanks,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Dec 2008 12:57:23 +0100

Yungui Wang wrote:
> My concern is MNP and MR_HoA can be assigned to MR at the same time, 
> special for the aggregated prefix. While, in the mip-split case, the 
> HoA is assigned to MR through BU/BA procedure.

Just for clarification, I don't think the mip-split bootstrapping
procedure (rfc5026) assigns a HoA through BU/BAck exchanges - I think it
uses IKEv2 messages, or CGA 'auto' configuration.

> Thus, the MNP assigned through BU/BA procedure can be supported too. 
> That's my simple logic.

For better understanding, one would draw a diagram of message exchanges
to see how the HoA and MNP are assigned, and see the constraints, etc.
We could discuss with it.

> Complying with rfc3775 which allows the HoA assignment via either
> split or integrated bootstrapping,  maybe we could consider to fix
> rfc3963 and let it more open - not limit which mechanism used for PD.

Hmmm... maybe...

Alex

> *From:* Ryuji Wakikawa <mailto:[email-masked]> *To:* Julien
>  Laganier <mailto:[email-masked]> *Cc:* Yungui 
> Wang <mailto:[email-masked]> ; mext <mailto:[email-masked]> ; Sri 
> Gundavelli <mailto:[email-masked]> ; Vijay Devarapalli 
> <mailto:[email-masked]> *Sent:* Friday, December 12, 2008 12:26 
> AM *Subject:* Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: 
> WGLC for draft-ietf-mext-nemo-pd-01.txt
> 
> Hi Julien and Yungui,
> 
> According to the NEMO-DHCP-PD spec, before receiving a prefix, a 
> mobile router must create a tunnel with its HA.
> 
>  its Home Agent. If there is no valid prefix for the mobile router, 
> HA returns BA with "Invalid Prefix" status value which is treated as 
> the fatal error in RFC3963.
> 
> For instance, RFC3963 said in section 6.2, "If the Home Agent has a 
> valid binding cache entry for the Mobile Router, and if the Binding 
> Update has the Mobile Router Flag (R) set to a value different from 
> that in the existing binding cache entry, then the Home Agent MUST 
> reject the Binding Update and send a Binding Acknowledgement with 
> status set to 139 (Registration type change disallowed). However, if 
> the Binding Update is a de-registration Binding Update, the Home 
> Agent ignores the value of the Mobile Router Flag (R)."
> 
> tunnel for DHCP-PD 2. MR starting DHCP-PD 3. After DHCP-PD 
> completion, MR de-registers the RFC3775-binding 4. MR sends NEMO-BU 
> (R-flag finally set) for its mobile network prefix acquired by 
> DHCP-PD
> 
>> We had this discussion for a long time abd it has concluded some 
>> time ago already: WG consensus is to use DHCP PD.
>> 
>>>  between MR and HA. i. BU to HA; (getting and binding MR_HoA) ii.
>>>  DHCPv6 message over MR-HA tunnel. (getting MNP) iii. BU to HA; 
>>> (binding MNP) While, if PD is combined within BU, it is only 1 
>>> round trip.
>>> 
>>> From implementation of viewpoint, the later seems well done prior
>>>  of the former. Maybe I have lost something, can anyone tell me 
>>> the
> story
>>> ----- Original Message ----- From: marcelo bagnulo braun To: mext
>>>  ; Julien Laganier ; Ralph Droms Sent: Tuesday, November 04, 2008
>>>  8:02 PM Subject: [MEXT] WGLC for draft-ietf-mext-nemo-pd-01.txt
>>> 
>>> 
>>> Hi,
>>> 
>> [ New email address: [email-masked]
> <mailto:[email-masked]> ]

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Dec 2008 13:00:43 +0100

Julien Laganier wrote:
>  DHCP client and relay, and the HA as a DHCP server: the DHCP
> messages would be unicasted bewteen MR and HA without tunneling.

I somehow agree.  Just to say that if the goal is to have DHCP unicasted
messages (avoid the DHCP Solicit) then it is sufficient for the MR to
know the address of the DHCP Server in advance (presumably the HA) and
send it a straight unicast DHCP Request.  I doubt the necessity of
having a DHCP Relay co-located with the DHCP Client (although I agree it
is a suggestive illustration).

> I thought that was what we agreed on and I'm seeing now the draft
> still talks about multicasting into the tunnel...

I agree, I have the same surprise.

> I think the tunneling story (Sec. 3.2) should be removed from the
> draft, and the DHCP relay configuration mode made the mandatory
> method for a NEMO MR to obtain a prefix dynamically, i.e. put a
> couple of SHOULD words here and there in Sec. 3.3.

I agree to have unicast DHCP exchanges but not sure about the
co-location Relay/Client.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 15 Dec 2008 13:07:59 +0100

Romain KUNTZ wrote:
>> There would be no issue at all with the MR being configured as both
>> a DHCP client and relay, and the HA as a DHCP server: the DHCP

I see indeed a potential worry.  But in a DHCP deployment the DHCP
Server is not configured with the address of the Relay (nor of the
Client) - it simply replies to the address received as src field in the
Request - that could be the CoA.

Should be tried first I believe.

> Furthermore, once the MR registers its allocated MNP to the HA, the
> HA cannot verify that the MNP that is in the BU was the one that the
> DHCP server allocated to that MR. To do so, the DHCP server would
> need to give the HoA/MNP pair to the HA, so that it can perform a
> check at registration.

Why would the HA need to verify the received MNP in the BU is the same
as the MNP sent in the DHCP Reply?

Is there anything wrong with a security model?

> between the MR and the HA.

I'm not sure about the security model (or threat analysis) here.  We
don't know the security analysis of the very first steps - the
bootstrapping.  If we use rfc5026 'split' bootstrapping with DNS then we
may have a flawed security chain prior to this DHCP PD exchange.

There may also be possible to say that if bootstrapping is used with 
IKEv2 and the HoA is assigned with it, then the MNP could too.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 16 Dec 2008 14:03:03 -0800 (PST)

________________________________
From: Romain KUNTZ <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: mext <[email-masked]>
Sent: Monday, December 15, 2008 3:45:58 AM
Subject: Re: [MEXT] using MR-HA tunnel vs. combining BU // Re: WGLC for draft-ietf-mext-nemo-pd-01.txt

Hi Behcet,

[behcet] I am curious what is this message? Can you please give more details?
The DHCPv6 server is co-located with the HA on the same computer. I use a UNIX socket for inter-processus communication with a simple TLV message. 

[behcet] I have a question: If HA were a requesting router (not a delegating router as in Nemo-pd draft), how would you change your implementation architecture? 
I have a feeling that you are using HA as a requesting router . 

In our testbed, the HA is a delegating router, and the client & relay are located at the HA. DHCP messages are exchanged through the MR-HA tunnel.

If the HA were a requesting router, I guess the testbed, implementation and interaction with the mobility daemon would be completely different, so I can't really tell how I would change the current one.

If HA is a requesting router, all you need at the HA is DHCP Client (and possibly colocated with relay if the delegating router is not on-link) 

I guess you refer to the solution exposed in draft-sarikaya-mext-prefix-delegation? This one suppose that the prefix delegation at the MR happens with BU/BAck messages, which is not the case in our implementation.

Note that I do not discuss here which solution is the best, but only present feedback from implementation of one of the solution. If I had chosen the delegation through the BU/BAck, I would certainly have coupled it with a DHCP server as you describe in your draft.
[behcet] and that would be much simpler implementation on HA simply requiring DHCP Client with PD capability. Such an implementation has other applications as well such as PMIP, so it could be reused. MR would be much simpler too.

Regards,

Behcet

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 16:53:44 +0900

Julien and Alex,

> I agree, I have the same surprise.

I guess the reason of using tunnel is security.
We don't have any secured mechanism for protecting DHCP unicast message.
In NEMO nor MIP, IPsec SA is not created for DHCP-unicast messages.

MR cannot trust the unprotected DHCP message for its MNP..

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Dec 2008 10:04:18 +0100

Ryuji Wakikawa wrote:
>>> Hello Ryuji, On Thursday 11 December 2008, Ryuji Wakikawa wrote:
>>>> problem.. This is a big issue of DHCP-PD. Let me explain the 
>>>> issue clearly. According to the NEMO-DHCP-PD spec, before 
>>>> receiving a prefix, a mobile router must create a tunnel with 
>>>> its HA.
>>> There would be no issue at all with the MR being configured as 
>>> both a DHCP client and relay, and the HA as a DHCP server: the 
>>> DHCP messages would be unicasted bewteen MR and HA without 
>>> tunneling.
>> 
>> I somehow agree.  Just to say that if the goal is to have DHCP 
>> unicasted messages (avoid the DHCP Solicit) then it is sufficient 
>> for the MR to know the address of the DHCP Server in advance 
>> (presumably the HA) and send it a straight unicast DHCP Request.  I
>>  doubt the necessity of having a DHCP Relay co-located with the
>> DHCP Client (although I agree it is a suggestive illustration).
>> 
> I guess the reason of using tunnel is security. We don't have any 
> secured mechanism for protecting DHCP unicast message.

We have two choices: (1) an authentication option for DHCP messages
(RFC3118) carried in the payload and (2) if IKE is run prior to the DHCP
exchanges then they could be protected by transport ESP I believe.

Alex

>>  This email has been scanned by the MessageLabs Email Security 
>> System. For more information please visit 
>> http://www.messagelabs.com/email

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 18:11:08 +0900

> exchanges then they could be protected by transport ESP I believe.

The authentication option is just for authentication and not  
encryption. It might not be strong enough for MNP delegation compared  
to other signaling protection.

When MN obtains HoA by IKE (before DHCP), SA for DHCP can be also  
established at that time. We should avoid running multiple IKEs for  
NEMO signaling.
This comes back to the same issue of the use of tunneling. (i.e.  # of  
round trip time).
btw, we should not mandate IKE for NEMO-PD..

regards,
ryuji

>>> I agree to have unicast DHCP exchanges but not sure about the co- 
>>> location Relay/Client.
>>> Alex
>>> System. For more information please visit http://www.messagelabs.com/email 
>>>

---

From: Julien Laganier <[email-masked]>
Date: Wed, 17 Dec 2008 10:22:05 +0100

Ryuji,

On Wednesday 17 December 2008, Ryuji Wakikawa wrote:
> We don't have any secured mechanism for protecting DHCP unicast
> message. In NEMO nor MIP, IPsec SA is not created for DHCP-unicast
> messages.
>

With MIPv6 there's already the requirement that a certain number of 
IPsec SAs are cinfigured between the MN and the HA, thus I don't see 
any problem with requiring a few more to protect DHCP signaling 
exchanged between the MR and HA.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Dec 2008 11:00:29 +0100

Ryuji Wakikawa wrote:
>>>>>> problem.. This is a big issue of DHCP-PD. Let me explain the issue 
>>>>>> clearly. According to the NEMO-DHCP-PD spec, before receiving a 
>>>>>> prefix, a mobile router must create a tunnel with its HA.
> The authentication option is just for authentication and not encryption. 
> It might not be strong enough for MNP delegation compared to other 
> signaling protection.

We may need to specifically point out the needs of hiding the MNP, 
rather than needing encryption just because it's better in a sense (and 
worse in another).

> established at that time. We should avoid running multiple IKEs for NEMO 
> signaling.

I agree the IKE prior to DHCP could be used to further protect DHCP 
exchanges.

> btw, we should not mandate IKE for NEMO-PD..

I think I personally wouldn't mandate IKE either, make it more as an option.

[I also think the entire picture of bootstrapping for MIP6 (HoA, HA
  address, MNP, SAs) is all very unclear from the standpoint of
  requirements and of threat analysis; but that's another point.]

Alex

>>>> http://www.messagelabs.com/email ______________________________________________________________________ 
>>>>
>>
>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 19 Dec 2008 18:50:13 +0900

Julien,

> exchanged between the MR and HA.

I answered to Alex's mail about IPsec protection.

Again, I think the use of BU/BA for prefix delegation is much simpler  
and easier.
We now have an example to delegate a prefix to a mobile host by PBU/PBA.

ryuji