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

From: [email-masked] (Arnaud Ebalard)
Date: Sun, 01 Jun 2008 14:23:07 +0200

Hi George,

"George Tsirtsis" <[email-masked]> writes:

>> That been said, it's not because I consider that the document deserves
>> to be WG item for that part of the audience that I think it will provide
>> a "one size fits all" solution for NEMO PD, for instance for very small
>> devices like PDA or Phones. I was basically wondering if I will ever
>> have to install and configure a DHCPv6 server with Relay and PD support
>> on my Phone or PDA just for the purpose of getting a prefix from my
>> HA. But considering what you write below (hiring DHCP for the job is
>> the consensus), this will be the case.
>>
>
> Arnaud,
>
> This maybe simply a misunderstanding but draft-droms does not require
> you to do this. The Mobile Router, is a Requesting Router (RR) i.e., a
> DHCP-PD client. So no server functionality is required in you small
> devices.

You are correct, the terms I used were not precise: I thought "daemon"
but used "server". I should have said "DHCPv6 relay and/or DHCPv6 client
with PD support". My point was that DHCPv6 is in all cases not a light
requirement for small devices just for providing a prefix.

Anyway, the use of DHCPv6 is the consensus, so I will not argue anymore.

Regards,

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

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 2 Jun 2008 00:49:47 +0200

Hi,

I'm in favor of accepting this document as WG doc.
I have however one major concern: it proposes to use DHAAD to discover  
DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping documents does  
not rely on DHAAD at all. More relationship should be considered  
between MIPv6 and NEMO bootstrapping, to enable the selection of a  
DHCPv6PD-enabled HA when the HA selection is performed during the  
MIPv6 bootstrapping time (e.g. by extending the DNS SRV lookup).

About the text itself, for clarity I think that the section about to  
the home link (3.4) should be merged with section 3.1 ("When the MR  
uses DHCPv6").

Regards,
-- 
Romain KUNTZ
[email-masked]
Louis Pasteur University - Networks and Protocols Team

On 2008/05/30, at 16:51, marcelo bagnulo braun wrote:

> Hi,
>
> We would like to ask the WG what is their opinion about accepting  
> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD  
> deliverable included in our charter.
>
> Please provide comments so we cna make some progress on this long  
> overdue deliverable
>
> thanks, Julien and marcelo
> -------- Mensaje original --------
> Asunto: 	I-D Action:draft-droms-mext-nemo-pd-00.txt
> Fecha: 	Fri, 30 May 2008 05:45:01 -0700 (PDT)
> De: 	[email-masked]
> Responder a: 	[email-masked]
> Para: 	[email-masked]
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : DHCPv6 Prefix Delegation for NEMO
> 	Author(s)       : R. Droms, et al.
> 	Filename        : draft-droms-mext-nemo-pd-00.txt
> 	Pages           : 12
> 	Date            : 2008-05-30
>
> One aspect of network mobility support is the assignment of a prefix
> or prefixes to a Mobile Router (MR) for use on the links in the
> Mobile Network.  DHCPv6 prefix delegation can be used for this
> configuration task.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-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.
>
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
>
> 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
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sun, 1 Jun 2008 21:45:00 -0400

Hi Roamin and others,

IMO, we should remove the extensions to DHAAD from this document. It's a
bad idea to keep extending DHAAD every time we add an extension to
MIPv6.

We could extend DNS-based HA lookup for discovering a home agent that is
capable of NEMO prefix delegation. But I think this is also unnecessary.
The mobile router can always try the next home agent in the list of the
home agents if the first one does not respond to DHCPv6 messages. If
none of the home agents are capable of prefix delegation, then there is
nothing the mobile router can do about it, maybe use some static mobile
network prefixes.

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Romain KUNTZ
> Sent: Sunday, June 01, 2008 3:50 PM
> To: marcelo bagnulo braun
> Cc: Julien Laganier; [email-masked]
> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?
> 
> Hi,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Jun 2008 11:51:59 +0200

> bad idea to keep extending DHAAD every time we add an extension to

It's a bad  idea to not extend DHAAD.

> capable of NEMO prefix delegation.

It's a bad idea to extend DNS for discovering stuff.  DNS is not for 
discovery.

Alex

  But I think this is also unnecessary.
>> the home link (3.4) should be merged with section 3.1 ("When the MR  

______________________________________________________________________
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: Mon, 02 Jun 2008 11:53:57 +0200

> requirement for small devices just for providing a prefix.

That sounds reasonable, but what do you mean by small devices?  Most if 
not all such small devices first things they do when they come alive is 
DHCP and then TCP and then HTTP.

DHCP PD is not heavier than DHCP tout court in terms of message numbers 
and size.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Jun 2008 12:01:45 +0200

Arnaud Ebalard wrote:
> Hi,
> 
> marcelo bagnulo braun <[email-masked]> writes:
> 
> The document is short and easy to read (good point). On one side, I
> think that DHCPv6 makes some sense for Nemo PD for devices with some
> capabilities. On the other side, I wonder if it is not overkill
> (complexity, roundtrips, ...) for a use in small devices (phone?, PDA?)
> that will serve a single subnet with IPv6 stateless @ autoconf 
> 
> In practice (as a HA and MR administrator), I'd like to be able to
> simply configure the prefixes for my MR in the HA configuration section
> for this MR and that those prefixes be sent to the MR during the
> initial binding if it ask for prefix(es). In a sense considering the
> an initial static configuration of a MR, switching to PD would mean:
> 
>   - changing a knob in the MR config to switch to prefix delegation
>   - giving the prefix in the HA config, indicating PD for that MR

I agree.  Remark that HA must already know the prefixes of MR, because 
it must have them in the Prefix Table; regardless of HA using or not PD. 
  It's for security reasons (make sure a certain MR doesn't claim 
somebody else's prefix in a BU).

> i.e. no need for IDs, specific keys for auth, or additional relay and
> associated IPsec credentials config.
> 
> I also have some comments on the "Security Considerations" section of
> the document. Don't hesitate to tell me if I missed sth or if it is out
> of scope.
> 
> IMHO, this is a bit simplistic to delegate the security of NEMO PD to
> the Security Considerations sections of DHCPv6 and DHCPv6 PD documents.

I mostly agree.

It's true however that DHCPv6 PD security is bound to DHCPv6 security 
overall.  If one attacks DHCPv6 then one can attack DHCPv6 PD too.

> There are good chances that the environments where MR will operate may
> be a bit more hostile than those where more common routers are expected
> to operate (in operators or corporate networks). 
> 
> Some initial thoughts:
> 
> - What are the hypothesis behind 3315 and 3633 design decisions that do
>   not hold anymore in MIPv6 environments (if any)?

One such hypothesis is that the DHCPv6 Solicit happens between close 
entities: CLient and Server are usually near each other, often same 
subnet.  With NEMO the MR would be far from its HA.

> - "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST"?

Maybe because HA and MR would MUST ESP and DHCPv6 auth would be through 
that ESP.

> - how do the security mechanisms of both protocols interact?
> - In the simple mode (no relay), how will the use of multicast interact
>   with IPsec protection of traffic if it is in place?
> - HMAC-MD5-based authentication method is the only one defined in
>   3315. Is it sufficient?

Now, SHA-256 should too rfc4868 "Using HMAC-SHA-256, HMAC-SHA-384, and 
HMAC-SHA-512 with IPsec".

> - What is the impact of the assignment of new prefixes in a dynamic
>   fashion w.r.t. the SPD and SADB or IKE daemons? How should that be
>   handled.

There may be some indeed.

What is the available implementation of DHCPv6 PD that one could 
configure on a NEMOv6 MR?

Alex

> - ...
> 
> Regards,
> 
> a+
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 2 Jun 2008 12:45:48 +0200

Hi,

> It's a bad  idea to not extend DHAAD.

The DHAAD extension would still be useful in the case the MIPv6  
bootstrapping is not used when the MR starts. But in that case, I  
would tend to agree with Vijay on the way to proceed (try the next HA  
on the list if it does not reply to DHCPv6 messages).

> It's a bad idea to extend DNS for discovering stuff.  DNS is not for  

Not discovering, but resolving a HA+DHCPv6 address through a DNS  
lookup by service name.

Romain

>>> I have however one major concern: it proposes to use DHAAD to  
>>> discover  DHCPv6PD-enabled HA. However, the MIPv6 bootstrapping  
>>> documents does  not rely on DHAAD at all. More relationship should  
>>> be considered  between MIPv6 and NEMO bootstrapping, to enable the  
>>> selection of a  DHCPv6PD-enabled HA when the HA selection is  
>>> performed during the  MIPv6 bootstrapping time (e.g. by extending  
>>> the DNS SRV lookup).
>>>
>>> About the text itself, for clarity I think that the section about  
>>> to  the home link (3.4) should be merged with section 3.1 ("When  
>>> the MR  uses DHCPv6").
>>>
>>> Regards,
>>> -- 
>>> Romain KUNTZ
>>> [email-masked]
>>>> We would like to ask the WG what is their opinion about  
>>>> accepting  draft-droms-mext-nemo-pd-00.txt as the WG document for  
>>>> the Nemo PD  deliverable included in our charter.
>>>>
>>>> Please provide comments so we cna make some progress on this  
>>>> long  overdue deliverable
>>>>
>>>> A New Internet-Draft is available from the on-line Internet- 
>>>> Drafts  directories.
>>>>

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 02 Jun 2008 13:23:37 +0200

Hi,

Alexandru Petrescu <[email-masked]> writes:

> That sounds reasonable, but what do you mean by small devices? 

Mainly two things:

- limited hardware (RAM, processor, storage and *battery*).
- limited maintenance/configuration (limited user interaction or no
  user interaction at all)

> Most if not all such small devices first things they do when they come 
> alive is DHCP and then TCP and then HTTP.

Certainly true for MN. But I think that there will be MR out there that
will be deployed only to do their job: route IPv6 traffic. They will
possibly come with TCP. HTTP will depend on the need. Here we just add
DHCPv6 to the picture.

> DHCP PD is not heavier than DHCP tout court in terms of message
> numbers and size.

AFAICT, my MN (the laptop this mail is sent from) does not have DHCPv6
and use DHCPv4 when needed (for teredo to bootstrap in those networks)
only because there is no such thing as SLAAC for IPv4 (i.e. no other way
to get an IPv4 @).

Maybe current consensus of the WG is towards providing the most generic
solution without considering *specifically* the scope of all the
possible target platforms and their constraints but only the goal:
providing a solution for NEMO PD. In the end, if some *lighter* but
*more specific* solution is needed at some point, someone will probably
make a draft (for instance based on the other one proposed in this
thread). Hence, my support for current document as a WG item: it answers
the question in the context of the consensus.

Regards,

a+

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 02 Jun 2008 13:54:00 +0200

Hi,

Alexandru Petrescu <[email-masked]> writes:

> it must have them in the Prefix Table; regardless of HA using or not
> PD. It's for security reasons (make sure a certain MR doesn't claim

Yes. There are two parts in the picture:

- how HA gets the prefixes for the MR (manual config, PD, ...)
- how MR gets the prefix from its home netwok

> overall.  If one attacks DHCPv6 then one can attack DHCPv6 PD too.

Clearly, I don't ask for removal of that part of the section. There are
some threats to DHCPv6 and PD that apply too in NEMO context (possibly
all): only clarification and extensions. i.e. my opinion is just that
the content of the section is probably not sufficient.

> subnet.  With NEMO the MR would be far from its HA.

Yes. I was under the impression (I think it is even written somewhere in
the documents) that some security provided by the infrastructure in a
usual [ISP] context is expected. Hence the point.

> Maybe because HA and MR would MUST ESP and DHCPv6 auth would be
> through that ESP.

If it is that, then it should probably be stated. My point was: *must*
some security mechanism be used or is it optional? Which one is
mandatory/preferred? When? 

> HMAC-SHA-512 with IPsec".

You cover all my 4 points with an IPsec argument (those 3 ones and
previous one). Is that correct? If the intent of the authors is to only
provide security of NEMO PD using IPsec, the security considerations
section can not directly be built on top of 3315 and 3633. If not, I
think my questions are still on the table. 

> configure on a NEMOv6 MR?

It will probably depends of the platform (Linux, vendor, BSD ...) and
what you want to do. Even if this is probably off-topic, AFAICT,
there is at least a NEMO+IPsec/IKE implementation available (kinda) for
Linux (contact me off-list for details). WIDE DHCPv6 supports PD and is
available for BSD and Linux. Francis might have more information on
that. For vendors, I do not know.

Regards,

a+

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Jun 2008 15:02:42 +0200

Hi,

Arnaud Ebalard wrote:
>>> HMAC-MD5-based authentication method is the only one defined in 
>>> 3315. Is it sufficient?
>> 
>> Now, SHA-256 should too rfc4868 "Using HMAC-SHA-256, HMAC-SHA-384,
>>  and HMAC-SHA-512 with IPsec".
> 
> previous one). Is that correct?

No, only the last one.

>>> - how do the security mechanisms of both protocols interact?

I'm wondering same.

>>> - In the simple mode (no relay), how will the use of multicast 
>>> interact with IPsec protection of traffic if it is in place?

Not sure I understand how IPsec would interact DHCPv6-PD.

MIP6' IPsec protection should be up _after_ the prefix assignment phase, 
I think.  So I suppose the prefix assignment - or PD - should happen 
straight multicast, not through MR-HA tunnel (contrary to 
droms-mext-nemo-pd "The HA and MR exchange DHCPv6PD protocol messages 
through the tunnel connecting them.")

Or, maybe DHCPv6-PD doesn't use the multicast Solicit/Advertise and uses 
only the unicast Request/Reply/Confirm messages - in which case MR 
should discover Server's or HA's address somehow.

> If the intent of the authors is to only provide security of NEMO PD 
> using IPsec, the security considerations section can not directly be
>  built on top of 3315 and 3633. If not, I think my questions are
> still on the table.

Well I think yes.

> there is at least a NEMO+IPsec/IKE implementation available (kinda) 
> for Linux (contact me off-list for details). WIDE DHCPv6 supports PD
>  and is available for BSD and Linux. Francis might have more 
> information on that. For vendors, I do not know.

DHCPv6-PD implementation for Linux - where?

Alex

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 02 Jun 2008 15:44:26 +0200

Hi,

> Not sure I understand how IPsec would interact DHCPv6-PD.

Possibly for:

- protection of the DHCPv6 flows themselves
- protection of flows routed by the MR which use the newly acquired
  prefix. 

> MIP6' IPsec protection should be up _after_ the prefix assignment
> phase, I think. 

I would say *before* (DHCPv6 traffic will possibly trigger IKE nego or be
the first to use existing SA protecting data traffic) but I will let the
authors comment on how things should/could happen. 

>  So I suppose the prefix assignment - or PD - should
> happen straight multicast, not through MR-HA tunnel (contrary to
> Or, maybe DHCPv6-PD doesn't use the multicast Solicit/Advertise and
> uses only the unicast Request/Reply/Confirm messages - in which case
> MR should discover Server's or HA's address somehow.

AFAICT, this is not covered yet.

>>  built on top of 3315 and 3633. If not, I think my questions are

ok.

> DHCPv6-PD implementation for Linux - where?

Packages are is wide-dhcpv6-{server, client, relay} under Debian. Support
might be partial, you will have to look at the man pages. The project is
on sourceforge (wide-dhcpv6).

Regards,

a+

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 00:37:40 +0200

In your previous mail you wrote:

=> or DHAAD is a bad idea (:-)?

=> RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong.

Regards

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 00:41:03 +0200

=> in fact it is smaller (i.e., a PD only client is smaller) and
BTW PD doesn't use some messages (Confirm and Decline).

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 00:55:22 +0200

=> this is not possible (to use only the unicast Request/Reply/Confirm
messages), this is why I introduced the DHCPv6 relay agent to use
only unicast Relay-Forw/Relay-Reply...

=> at the last DHCPv6 bake-off there were many PD implementations and
most of them ran on Linux (or BSD or both)...

Regards

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 03 Jun 2008 09:51:43 +0200

Hi Francis,

Francis Dupont <[email-masked]> writes:

>    On the other side, I wonder if it is not overkill
>    that will serve a single subnet with IPv6 stateless @ autoconf=20
>    
> => I believe you are talking about MRs so as the DHCPv6 use (and support
> requirement) is at the initiative of the client/MR there is no issue:

Yes, I am talking about MR. For HA, I see no possible issue regarding
the implementation of DHCPv6 given their environment and expected
capabilities: as router, they will most probably come with it anyway.

> simply don't use it (and don't support it) on pico devices.

;-)

> => in fact I think the opposite: the critical parts will be protected,
> for instance the MR-HA tunnel protected by ESP for all packets.
>    
> [...]
>
>    * "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST"?
>
> => mainly because there are better ways and when they are used the
> weak DHCPv6 authentication is useless (or worse).
>
>    * how do the security mechanisms of both protocols interact?
>
> => badly!
>
>    * In the simple mode (no relay), how will the use of multicast interact
> => this is an IPsec issue. When IPsec protects all packets multicast
> doesn't matter.
>
>    * What is the impact of the assignment of new prefixes in a dynamic
> => irrelevant and BTW there is simple solution if IPsec is applied
> to all packets in the MR-HA tunnel.

If both protocols interact badly and IPsec is the best way to protect
DHCPv6 traffic, then the Security Consideration section definitely needs
to clarify that. What do you think?

Thanks,

a+

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 3 Jun 2008 16:54:12 +0900

Hi Marcelo,

I agree to accept this as WG doc.

I also agree with Romain and Vijay.
We don't need extension to DHAAD.
Since MR can act as MN, MR should be able to bootstrap with the same  
mechanism of MIP (except for PD).
We should not bring DHAAD back in the bootstrap process only for PD.

regards,
ryuji

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Jun 2008 09:59:55 +0200

Hi Vijay:

Allow me to disagree.

I'm not trying to challenge whether DHAAD is 'good' or 'bad'. Simply, it
is the mechanism we have and we want to be consistent between our specs.
If you can convince this group that DHAAD should be obsoleted, then
we'll rev RFC 3775, 3963 and the PD work altogether and in a consistent
manner.

>bad idea to keep extending DHAAD every time we add an extension to

[Pascal] Why not? We do not have so many extensions in the charter and
prefix delegation is a much needed and quite major one. DHAAD is exactly
designed for the purpose at hand and the use in the PD draft is
homogeneous with the use in RFC 3963. 

>capable of NEMO prefix delegation. But I think this is also
unnecessary.

[Pascal] I think that Prefix Delegation can and should be a simple
extension to complete the explicit and implicit modes on a NEMO MR.
There's no necessity to prerequire support for the MIP bootstrap
mechanism. PD is not specifically a provisionning function anyway, but
something that also happens in the life of the MR, much like renumbering
the Home Link.

>home agents if the first one does not respond to DHCPv6 messages. If

[Pascal] Vijay, I do hope I see you in Dublin. But I'll certainly not go
through all the rooms in the hotel to see if you are there or not :)

>nothing the mobile router can do about it, maybe use some static mobile

[Pascal] The MR should be able to raise an alert if it is configured for
PD and there no HA that supports it. Then again, a simple flow to detect
it is a good thing, and for the time being DHAAD is the simplest flow
that fits the bill

Pascal

>> discover

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Jun 2008 10:08:55 +0200

Hi Ryuji:

I agree that PD should not impact bootstrap. These are and should be
kept unrelated. 

We must be able to extend a RFC 3963 MR with PD without forcing the
bootstrap process in the picture. So I agree not to bring DHAAD back
into the bootstrap... 

But I think that PD is NOT a bootstrap process. It is post bootstrap and
can reoccur many times in the life of the MR. 

Until we define a new process and rev 3775 and 3963, we should stay
consistent and simple in what we are doing.

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ryuji Wakikawa
>Sent: mardi 3 juin 2008 09:54

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 10:24:14 +0200

> => RFC 2782 (aka DNS SRV RR) is enough used to prove you are wrong.

Similarly to how a DHCP Client wouldn't DNS to discover a DHCP Server, a 
MN wouldn't DNS to discover a HA.

Of course, one _would_ DNS to discover a LDAP, printing, SIP, web service.

Right or wrong - I don't know.

Alex

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Tue, 3 Jun 2008 11:54:28 +0200

Hi,

I agree that this draft becomes WG document.

Best regards.

JMC.

2008/5/30, marcelo bagnulo braun <[email-masked]>:
>  Please provide comments so we cna make some progress on this long overdue
> deliverable
>

---

From: "Julien Bournelle" <[email-masked]>
Date: Tue, 3 Jun 2008 12:08:46 +0200

Hi,

> MN wouldn't DNS to discover a HA.

 why a MN wouldn't use DNS to discover a HA ? not sure to understand.

 Regards,

 Julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 13:36:44 +0200

>  why a MN wouldn't use DNS to discover a HA ? not sure to understand.

MN needs a HA that can bind a CoA to its HoA.  The HA that can do that 
binding must have the same prefix as the HoA.  In this sense, DNS does 
not offer any relationship whatsover between a prefix and an address 
(DNS relates names to addresses).

I don't understand why using DNS to discover a HA?

Alex

Why would MN need to discover its HA in the first place? (regardless of 
the means of doing it).

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Jun 2008 13:48:40 +0200

I'm with Alex on this. 

If we really want to deprecate DHAAD then let's go ahead design its
successor and rev all the RFCs that use it. In the meantime, DHAAD is
still the tool designed specifically to locate a HA and NEMO sets a
precedent in adding filters to it.

Things are complex enough as they are; so please let us not create a new
HA localization tool for each sub-feature we come up with!

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
>Sent: mardi 3 juin 2008 13:37
>To: Julien Bournelle
>Cc: Julien Laganier; Francis Dupont; [email-masked]
>Subject: Re: [MEXT] side discussion about discovering a HA
>
>Julien Bournelle wrote:
>> Hi,
>>

---

From: "Julien Bournelle" <[email-masked]>
Date: Tue, 3 Jun 2008 14:04:40 +0200

inline...

On Tue, Jun 3, 2008 at 1:36 PM, Alexandru Petrescu
<[email-masked]> wrote:
> binding must have the same prefix as the HoA.  In this sense, DNS does not
> offer any relationship whatsover between a prefix and an address (DNS
> relates names to addresses).
>

 this is what we specified in RFC 5026, so I was surprised that you say:
"MN wouldn't DNS to discover a HA".

 Julien

>
> Alex
>
>
>
>
> Why would MN need to discover its HA in the first place? (regardless of the
> means of doing it).
>
>
>
>>
>>  Regards,
>>
>>  Julien
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 14:08:55 +0200

> "MN wouldn't DNS to discover a HA".

DHAAD is what's implemented in MIPL and others.  DHAAD is what's been 
tested between two different implementations.

How about RFC 5026?

Alex

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 3 Jun 2008 14:17:40 +0200

Hi Pascal,

> HA localization tool for each sub-feature we come up with!

DNS is not new, and is the standardized tool to resolve a FQDN or a  
service by domain name. The MIPv6 bootstrapping makes the assumption  
that the HA domain or FQDN is initially configured on the MR, hence  
the use of DNS to get the HA address. This seems like an obvious  
choice to me.

DHAAD cannot be used in that case because the home prefix is not known  
by the MR. RFC 5026 explain more the motivations about that.

romain

---

From: Julien Laganier <[email-masked]>
Date: Tue, 3 Jun 2008 14:35:19 +0200

Folks,

<wg chair hat on>

We already have the DHAAD vs. RFC5026 discussion on that mailing list. 
The fact is there are indeed two standardized methods to discover a HA, 
one based on DHAAD, and the other based on RFC5026, with different 
properties and applicability.

Let me suggest that we don't spend again a lot of time arguing again 
which one is better than the other, and concentrate on our 
deliverables.

Thanks.

--julien

On Tuesday 03 June 2008, Romain KUNTZ wrote:
> DHAAD cannot be used in that case because the home prefix is not
> known by the MR. RFC 5026 explain more the motivations about that.
>
> romain
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 14:54:46 +0200

Romain KUNTZ wrote:
>> Things are complex enough as they are; so please let us not create
>> a new HA localization tool for each sub-feature we come up with!
> 
>  service by domain name.

Somehow agree with you, but MIP6 has a distinctive feature: a HA is 
bound to a subnet (which is the size of a link-local multicast.)  I 
don't think any other protocol relying on SRV Resource Records make this
assumption: LDAP, printing, sip, http don't make any assumption about a
subnet and a domain; for example, there is a single SIP Server for an
entire domain, regardless of how many subnets that domain spans.

To deploy rfc5026 in a network one needs to assign a different subdomain
name to each subnet.  This is difficult to maintain.

SRV RR were useful for discovering a MIP6 HA _only_ if HA were not bound
to a subnet.  But this is not the case.  One can't imagine a HA for an
entire domain.  An HA is not a VPN Server.

Alex

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 3 Jun 2008 14:54:41 +0200

Hi Alex,

> MN needs a HA that can bind a CoA to its HoA. The HA that 
> can do that binding must have the same prefix as the HoA.
 
Not directly related to the topic, but... I thought that the HoA and the HA addresses could be based on different prefixes. What you say would be a limitation at least for the case when the per-MN prefix model is used.

domagoj

> Behalf Of Alexandru Petrescu
> Sent: 03. lipanj 2008 13:37
> To: Julien Bournelle
> >> Similarly to how a DHCP Client wouldn't DNS to discover a DHCP 
> >> Server, a MN wouldn't DNS to discover a HA.
> >>
> > 
> MN needs a HA that can bind a CoA to its HoA.  The HA that 
> can do that binding must have the same prefix as the HoA.  In 
> this sense, DNS does not offer any relationship whatsover 
> between a prefix and an address (DNS relates names to addresses).
> 
> Why would MN need to discover its HA in the first place? 
> (regardless of the means of doing it).
> 
> 
> 
> > 
> >  Regards,
> > 
> >  Julien
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 15:02:09 +0200

Premec, Domagoj wrote:
> Hi Alex,
> 
>> MN needs a HA that can bind a CoA to its HoA. The HA that can do
>> that binding must have the same prefix as the HoA.
> 
> Not directly related to the topic, but... I thought that the HoA and
> the HA addresses could be based on different prefixes.

Which HA address(es)?  The HA address with which the HA does proxy ND 
defending the HoA when not at home, and with which HA replies to DHAAD, 
and with which it builds the HA list among the other HAs, must have 
precisely the same prefix as the HoA.

If one considers a HA with two interfaces: egress and ingress, and the 
ingress is the home of the mobiles then the egress and ingress could be 
assigned entirely different prefixes (differ at leftmost bit).  Or could 
have a the same first few bits, or same leftmos 64 bits.  Typically the 
two prefixes of HA do share some initial bits.

But I don't think rfc3775 specifies HA to do anything with its address 
that is not on the same prefix as the HoA.

Alex

  What you say
> would be a limitation at least for the case when the per-MN prefix
> model is used.
> 
> domagoj
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu 
>> Sent: 03. lipanj 2008 13:37 To: Julien Bournelle Cc: Julien
>> Laganier; Francis Dupont; [email-masked] Subject: Re: [MEXT] side
>> discussion about discovering a HA
>> 
>> Julien Bournelle wrote:
>>> Hi,
>>> 
>> MN needs a HA that can bind a CoA to its HoA.  The HA that can do
>> that binding must have the same prefix as the HoA.  In this sense,
>> DNS does not offer any relationship whatsover between a prefix and
>> an address (DNS relates names to addresses).
>> 
>>>> _______________________________________________ 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
>> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Jun 2008 15:37:19 +0200

Hi Romain:

This thread started with the Prefix Delegation draft. PD is not
bootstrap and does not have its assumptions and limitations. IOW,
whether a MR is preconfigured or found its home info via 5026 is
orthogonal to Prefix Delegation.

So I perfectly respect the design is RFC 5026 but that's not the problem
at hand. The precedent is actually RFC 3963 and the method is extending
DHAAD... 

Pascal

>From: Romain KUNTZ [mailto:[email-masked]]
>Sent: mardi 3 juin 2008 14:18
>To: Pascal Thubert (pthubert)
>Cc: [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Jun 2008 15:44:17 +0200

Hi Julien:

This is exactly what I'm trying to do. 

The use of DHAAD in the PD draft is being challenged and we have reach
an agreement whether it's justified or not. There is a confusion that
since PD might occur right after bootstrap it could be considered as
bootstrap and thus use the bootstrap discovery method. 

I'm claiming it's not bootstrap but runtime and that at the time the PD
process starts, the home prefix is known one way or another, regardless
on whether config or RFC 5026 was used or not to get there.

There should be no tie or dependency between PD and bootstrap.

Pascal

>From: julien laganier [mailto:[email-masked]] On Behalf Of
Julien Laganier
>Sent: mardi 3 juin 2008 14:35
>To: Julien Bournelle; Romain KUNTZ; Pascal Thubert (pthubert);
Alexandru Petrescu
>> > a new

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 16:13:57 +0200

MN needs a HA that can bind a CoA to its HoA.  The HA that can do that 
   binding must have the same prefix as the HoA.

=> you assume the HoA is wired down in MN, I strongly disagree: this
is not a coomon rule and there are many reasons which make this a bad
idea.

PS: and this doesn't make DNS not usable: some of the addresses
bound to the service/HA name should be in the expected prefix
(with 2^64 addresses per prefix :-).
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 16:25:07 +0200

=> I don't understand: the home link is a part of the mobility service,
do you describe something where all links are home links?

   One can't imagine a HA for an entire domain. An HA is not a VPN Server.

=> obviously we have not the same definition of a mobility service
(and for me the only difference between a HA and a 'road warrior' VPN
server is the HA supports real mobility, not nomadism).

Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 16:30:38 +0200

> is not a coomon rule and there are many reasons which make this a bad

YEs I assumed that.  If neither the HoA nor the home prefix are
hardcoded in the MN then there are few chances MN needs to discover a HA
at some remote across the Internet - just use the locally provided address.

> PS: and this doesn't make DNS not usable: some of the addresses bound
> to the service/HA name should be in the expected prefix (with 2^64
> addresses per prefix :-).

I don't understand, what's an expected prefix?  How is an expected 
prefix allowing DNS SRV RR for bootstrapping to not require each subnet 
which may constitute a home link to be assigned a subdomain name?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 16:43:46 +0200

Francis Dupont wrote:
> To deploy rfc5026 in a network one needs to assign a different
> subdomain name to each subnet.  This is difficult to maintain.
> 
> => I don't understand: the home link is a part of the mobility
> service, do you describe something where all links are home links?

YEs, I describe something where all links have hosts attached to them
and need to become mobile.

>  server is the HA supports real mobility, not nomadism).

Well yes we don't have the same definition of the mobility service.  If
one sees it as an independent service where the mobiles never connect
directly to the home link, never at home, then I believe Mobile IPv6 has
never been used for that purpose, I've never seen it as such - have you?

Why would one bother always encapsulating all packets, especially when 
many mobile wireless links offer mobility already.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 17:36:52 +0200

Francis Dupont wrote:
[...]

Just one quick point:

 > In the GSM, a HLR or VLR handles millions of users...

Mobile IPv6 is _not_ adapted for GSM, HLR nor VLR.  Mobile IPv6 is well 
adapted for inter-system handovers maintaining sessions and be reachable 
at a permanent home addres that the end user decides.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 17:50:52 +0200

Francis Dupont wrote:
> => this is far from the default model...

I don't think there's any default model.  I think MIP6 use can be
imagined in many ways but the actual implementations are very few and clear.

> => this is the operator model [...]

I think Mobile IPv6 risks more to be deployed by small independent end
users than by large operators.

> Why would one bother always encapsulating all packets, especially 
> when many mobile wireless links offer mobility already.
> 
> => this doesn't work with heterogeneous technologies and with other 
> words the network layer is the first universal layer.

I agree.  Heterogeneous is what Mobile IPv6 can do very well.  This also
means it's not adapted for homogeneous intra-system mobility where other
protocols do better.

> PS: my main concern about DHAAD is it is intrinsically impossible to 
> secure (cf the DHAAD considered harmful I-D which is reviving...). 
> IMHO it should be removed from RFC 3775 (i.e., its status should be 
> more "elective").

Francis, DHAAD is no less secure than DHCP.  Its main weakness is the
discovery phase, as all discovery phases are.  DHCP discovery is weak
too.  Discovery of the DNS Server too.  mDNS too.  In this sense every
discovery is harmful?

Alex

---

From: Julien Laganier <[email-masked]>
Date: Tue, 3 Jun 2008 17:58:12 +0200

And one more below:

>  > In the GSM, a HLR or VLR handles millions of users...
>
> Mobile IPv6 is _not_ adapted for GSM, HLR nor VLR.  Mobile IPv6 is
> well adapted for inter-system handovers maintaining sessions and be
> reachable at a permanent home addres that the end user decides.

This is your opinion, and it seems contradicted by facts: In 3GPP 
Release 8, the Evolved Packet System (EPS -- successor of GPRS) has a 
so-called PDN Gateway (the EPS equivalent of GSM's HLR) that will 
possibly be a DSMIPv6 HA.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Jun 2008 18:12:21 +0200

> possibly be a DSMIPv6 HA.

This wouldn't be the first time 3GPP required a MIP6-based protocol.  I 
don't think we (MIP, MIP6, MEXT WGs) failed to deliver what was 
required, on time.  I think the ball is in the 3GPP camp.  And if it's 
not happening, it must be for some good reason we unfortunately fail to 
identify.

Alex

---

From: Frank Xia <[email-masked]>
Date: Tue, 03 Jun 2008 12:10:46 -0500

Hi Chairs and Ralph

As to prefix delegation, PMIPv6 is using BU&BA to delegate prefixes.
In this draft, we abandoned this machinism, IMHO which seems to be 
applicable
in NEMO scenario.

I don't think we need brand new design just because there are some tiny 
differences.

BR
Frank
----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: <[email-masked]>; "Julien Laganier" <[email-masked]>; "Ralph 
Droms" <[email-masked]>
Sent: Friday, May 30, 2008 9:51 AM
Subject: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

> implementation to automatically retrieve the ASCII version of the

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 03 Jun 2008 10:52:55 -0700

> at hand. The precedent is actually RFC 3963 and the method is extending

Pascal, I don't see how this can justify further extending DHAAD to discover
a prefix delegation-capable home agent. Yes, we did it once to discover a
home agent that is capable of supporting mobile routers (in RFC 3963). In
hindsight, I think even that was unnecessary. At that time, we all thought
it was necessary. I will support removing that extension to DHAAD if (and
when) 3963 is revised.

But the reality is that I don't see DHAAD being used that much for
discovering home agents, because DHAAD assumes that the mobile node/mobile
routers knows the home prefix (this means the mobile node is already tied to
a certain subnet). Most bootstrapping scenarios that I have seen don't want
to tie the mobile node/mobile router to a certain subnet.

Vijay

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Jun 2008 10:02:08 +0200

Hi Frank,

as i mentioned before, the WG consensus reached in last ietf meeting and 
confirmed in the mext ml is to use dhcp or this and NOT BU for this

so, this discussion is closed and now we need to proceed to figure out 
which is the way we use dhcp for this

Regards, marcelo

Frank Xia escribió:
> I don't think we need brand new design just because there are some 
> tiny differences.
>
> BR
> Frank
> ----- Original Message ----- From: "marcelo bagnulo braun" 
> <[email-masked]>
> To: <[email-masked]>; "Julien Laganier" <[email-masked]>; 
> "Ralph Droms" <[email-masked]>

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 4 Jun 2008 10:23:06 +0200

Hi Pascal,

> on whether config or RFC 5026 was used or not to get there.

I'm not sure I understood what you suggest here: you seem to say that,  
even though RFC 5026 was used at the bootstrap phase, one can still  
use DHAAD after to find a suitable (= which is DHCPv6PD-capable) HA?  
In that case, what happens if the dhaad reply returns a different HA  
than the one that was configured at bootstrap time?

regards,

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 5 Jun 2008 09:37:34 +0900

Hello Pascal,

Sorry for late response. We have interop event in Tokyo and tested  
HAHA there;-)

> bootstrap process in the picture. So I agree not to bring DHAAD back

we agree then..

> consistent and simple in what we are doing.

DHCP-PD can surely impact to the bootstrap process.

Let's say MR boots up as a MN with RFC5026 first.
Then, it tries to get a MNP for NEMO.

If the current HA is not PD-enabled and DHAAD returns different HA,
MR must de-register the binding from the current HA and tries to start  
all the registration process to the new HA.

This seems very redundant operation..
I want to make the PD spec simple.

regards
ryuji

>> Behalf Of

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 5 Jun 2008 09:38:59 +0900

Hi

> it was necessary. I will support removing that extension to DHAAD if  

+1

We should not use DHAAD for discovering a HA supporting particular  
extension.
We had DHAAD extension to discovery a HA supporting Multiple Care-of  
Address Registration, but
we removed it from the spec.

ryuji

>>>> Things are complex enough as they are; so please let us not  
>>>> create a
>>>> new
>>> known

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 17:37:33 +0200

=> this is the operator model where the home link can be virtual but
many think more about some kind of extended nomadism: hosts are by
default at home but they can become mobile using heterogeneous
layer 2 technologies.

Regards

PS: my main concern about DHAAD is it is intrinsically impossible to secure
(cf the DHAAD considered harmful I-D which is reviving...).
IMHO it should be removed from RFC 3775 (i.e., its status should
be more "elective").
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 17:17:50 +0200

=> I believed the boostrapping stuff was just about this and
it seems the name of a mobility service/server (note a mobility server
is in fact a HA) was enough?

   > addresses per prefix :-).
   
   I don't understand, what's an expected prefix?

=> the prefix where is the HoA and where should be the HA.

   How is an expected 
   
=> because DNS resource records come per set. With other words the DNS
can provide many HA addresses so if you'd like to provide some HA
addresses per home link you can if the number of addresses is still
reasonnable. BTW I don't see a reason to use more than a few home links.
In the GSM, a HLR or VLR handles millions of users...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 11:48:19 +0200

=> I don't but your argument because DHCP is constraint to be link-local
(for an obvious reason for address assignment and only by keeping
the design for stateless or PD). This is not the case for the mobility
service, so the not-local HA discovery (DHAAD) can be replaced by the DNS.
(note the local HA discovery is done by the HA info option in RAs and
has far less problems than DHAAD).

=> (global) mobility service?
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 11:29:28 +0200

In your previous mail you wrote:

   > ... BTW there is simple solution if IPsec is applied

=> there is a potential bootstrapping issue because sending packets
on the MR-HA tunnel is fine but doesn't work before this tunnel is
established...
Note when the MR has the relay agent function, we can simply apply
RFC 3315 21.1 "Relay agents and servers that exchange messages securely
use the IPsec mechanisms for IPv6..." so the only thing to do is to
configure IPsec knowing addresses, protocol and ports.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 00:25:08 +0200

Some initial thoughts:
   
   * What are the hypothesis behind 3315 and 3633 design decisions that do
     not hold anymore in MIPv6 environments (if any)?

=> IMHO none.

=> badly!

   * HMAC-MD5-based authentication method is the only one defined in
     3315. Is it sufficient?

=> HMAC-MD5 is not yet proved broken but I agree it is not the best choice
(I have a nice reference with comment for the same issue in TSIG).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jun 2008 00:34:40 +0200

=> we have to do this (extend DHAAD) until there will be a consensus
about phasing out DHAAD (DHAAD considered harmful is reviving :-).

=> I agree

Thanks

---

From: "fan zhao" <[email-masked]>
Date: Fri, 6 Jun 2008 10:18:00 -0700

Hi Ryuji and et al,

Sorry for jumping in.
I agree with Ryuji that the DHCP based PD procedure introduces redundancy.
IMHO, the MR can request a MNP together with a HNP/HoA when establishing
the IPSec SA with the HA. IMO, this is simpler. Do I miss something?
Thanks.

Sincerely,
fan

---

From: Frank Xia <[email-masked]>
Date: Fri, 06 Jun 2008 12:51:40 -0500

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.

BR
Frank

---

From: "fan zhao" <[email-masked]>
Date: Fri, 6 Jun 2008 13:33:51 -0700

Hi Frank,

Please see below.

On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia <[email-masked]> wrote:
> NEMO operations

I agree that signaling overhead can be reduced if multiple _related_
requests/responses
are piggybacked together, e.g. during one message exchange. For the MR
to work, it
needs both a HoA/HNP and a MNP. Besides requesting/registering the
MNP, there is
no much difference between the operation of the MN and that of the MR.
Furthermore,
the MR can request the MNP during the establishment of IPSec SA when
it is at either home link or foreign link.

> because prefix management is an integrated part
> of NEMO.
If I understand correctly, PMIP is a slightly different case from DSMIPv6/NEMO.
Because the connection, such as the IPSec SA, between the MAG and the LMA
is already in place long before the MN attaches to the MAG, it makes sense for
the MAG to request the HNP for the MN during the PBU/PBA exchange. With
DSMIPv6, the MN requests the HoA/HNP during the establishment of the IPSec
SA, therefore the MR should request the MNP during this procedure as well.

What do you think?

Sincerely,
fan

>
> BR
> Frank
>
> ----- Original Message ----- From: "fan zhao" <[email-masked]>

---

From: Frank Xia <[email-masked]>
Date: Fri, 06 Jun 2008 16:40:09 -0500

Hi Fan

Please see my reply...

BR
Frank

----- Original Message ----- 
From: "fan zhao" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Ryuji Wakikawa" <[email-masked]>; "Julien Laganier" 
<[email-masked]>; <[email-masked]>
Sent: Friday, June 06, 2008 3:33 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

> it is at either home link or foreign link.
Frank=>For adressing in NEMO, there are two categories
nodes for addressing, that is, MRs and hosts behind MRs.

IKE can be used for MR's addressing, while it probabaly
can't be used for host addressing (PD) without extension of IKE.

> SA, therefore the MR should request the MNP during this procedure as well.
Frank=>It is true there is difference between PMIP and NEMO.
I just do an analogy.   What I want to say is it makes sense if we integrate 
PD
into NEMO.

>>> On Wed, Jun 4, 2008 at 5:37 PM, Ryuji Wakikawa 
>>> <[email-masked]>
>>> wrote:
>>>>
>>>> Hello Pascal,
>>>>

---

From: "fan zhao" <[email-masked]>
Date: Fri, 6 Jun 2008 15:22:56 -0700

Hi Frank,

Please see below..

> can't be used for host addressing (PD) without extension of IKE.

Fan> We can simply define a new attribute carried in the CFG_REQUEST/CFG_REPLY
configuration payload during the IKE_AUTH exchange.

> I just do an analogy.   What I want to say is it makes sense if we integrate

Fan> OK.

Sincerely,
fan

---

From: Frank Xia <[email-masked]>
Date: Fri, 06 Jun 2008 17:35:45 -0500

Hi Fan

Please check my reply...

BR
Frank

----- Original Message ----- 
From: "fan zhao" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Ryuji Wakikawa" <[email-masked]>; "Julien Laganier" 
<[email-masked]>; <[email-masked]>
Sent: Friday, June 06, 2008 5:22 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

> configuration payload during the IKE_AUTH exchange.
Frank=>It couples PD with IKE procedure.   How does the
MR renew/release/renumber the prefixes after IKE_AUTH exchange?
Anyway, IKE is not solely for MIP, IMHO, it is not proper to
extend for this purpose.

IMO, the compromised way is to use BA/BU which
is in line with PMIP thoughtway.

>>> is already in place long before the MN attaches to the MAG, it makes 
>>> sense
>>> for

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Sat, 7 Jun 2008 01:30:39 +0200

Hi,

Don't forget that people may want to deploy SEND and so you will have
to provide Router Authorization Certificate too in that case.
AFAIK, for the moment, there is no proposal to provide such
certificates with PBU/PBA and so you will have another mechanism. The
consequence is that you will loose the advantage in time you gained in
piggybacking the delegated prefixes in the PBU/PBA ...

This is not the case with PMIP because the LMA is aware of the
prefixes assigned to the MAGs and during the set up of

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Sat, 7 Jun 2008 01:35:02 +0200

Sorry, I forgot to finish my email before to send it :)

>  prefixes assigned to the MAGs and during the set up of

a MAG, the LMA may provide a Router Authorization Certificate linked
to a prefix containing all the future prefixes advertised by this MAG.

Best regards.

JMC.

---

From: "fan zhao" <[email-masked]>
Date: Fri, 6 Jun 2008 16:55:26 -0700

Hi Frank,

<...>
> Frank=>It couples PD with IKE procedure.
Fan> We already agreed in RFC 5026 that the HoA/HNP is assigned to
the MN during the IKEv2. I do not see why this is a bad thing.

> How does the

Fan> There are a couple of approaches. I am open to suggestions and
inputs, especially those related to NEMO deployment, as which approach
is better and what value should be set depend on how often the MNP
becomes expired in the real deployment.

Releasing:
Similar to the Prefix Lifetime field defined in RFC 5026 for the
MIP6_HOME_PREFIX
Attribute, we can include a lifetime field for the new attribute for
MNP. In addition,
the lifetime of the MNP may be associated with that of the IKE SA. Or,
we can define
a new type of the payload.

Renewing:
This is also related to the lifetime of the MNP. We can extend the
lifetime of the
assigned MNP by either re-keying the IKE SA, or informational exchange with
CFG_REQUEST/CFG_REPLY payload.

Renumbering:
Informational exchange can do the work.

> Anyway, IKE is not solely for MIP, IMHO, it is not proper to
Fan> One more advantage that when using the IKEv2 to request a MNP,
the security
is already provided by IPSec.

> is in line with PMIP thoughtway.

Fan> I would agree that when the MR attaches to a PMIP domain, the PBA
and PBU messages are extended to carry the MNP; however not in the
case of DSMIPv6/NEMO.

Sincerely,
fan

---

From: "fan zhao" <[email-masked]>
Date: Fri, 6 Jun 2008 17:02:08 -0700

Hi JMC,

I have a doubt, please see below.

> to a prefix containing all the future prefixes advertised by this MAG.
What happens if a MR handovers to a PMIP domain? In this case,
can the LMA know the MNPs that the MR recevies before handover?

Thanks for clarification.

Sincerely,
fan

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Sat, 7 Jun 2008 02:13:33 +0200

Hi Fan,

>  can the LMA know the MNPs that the MR recevies before handover?

AFAIK, the MNPs are already delegated to the MR before the HO
(otherwise the MR is not a MR but just a MN :)) and there is no
relationship between the MR's MNPs and the prefix delegated to the
MAG.

Or did I miss your point?

Best regards.

JMC.

---

From: "fan zhao" <[email-masked]>
Date: Fri, 6 Jun 2008 17:25:42 -0700

Hi Jean-Michel,

OK, I think I have to check the CSI. :-)
Thanks for raising this interesting point.

BR,
fan

---

From: Frank Xia <[email-masked]>
Date: Mon, 09 Jun 2008 09:50:20 -0500

Hi Jean-Michel

Even in SEND,  IMHO, it is not necessary for HA to
provide Router Authorization Certificate because
HA and MR have authenticated each other using
IKE, etc.

Anyway, this scenario is not clear.

BR
Frank

----- Original Message ----- 
From: "Jean-Michel Combes" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "fan zhao" <[email-masked]>; <[email-masked]>; "Julien Laganier" 
<[email-masked]>
Sent: Friday, June 06, 2008 6:30 PM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

>>  >>>> I favor the integrated mode in which Prefix Delegation is 
>> integrated
>>  >>>> into
>>  >>>> NEMO operations
>>  >>>
>>  >>> Because the connection, such as the IPSec SA, between the MAG and 
>> the
>>  >>> LMA
>>  >>>>>>> But I think that PD is NOT a bootstrap process. It is post 
>> bootstrap
>>  >>>>>>> and
>>  >>>>>>>> We should not bring DHAAD back in the bootstrap process only 
>> for
>>  >>>>>>>> PD.
>>  >>>>>>>>
>>  >>>>>>>> regards,
>>  >>>>>>>> ryuji
>>  >>>>>>>>
>>  >>>>>>>>
>> accepting
>> long

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Mon, 9 Jun 2008 18:05:45 +0200

Hi Frank,

If SEND is deployed in the NEMO network (i.e. MR's ingress interface),
at the same time the HA has to provide the MNPs, it has to provide the
Router Authorization Certificate linked to the MNPs.

There is no relationship between IKE and SEND, by the way.

Best regards.

JMC.

2008/6/9, Frank Xia <[email-masked]>:
>  ----- Original Message ----- From: "Jean-Michel Combes"
> <[email-masked]>
> > >  >>> DSMIPv6, the MN requests the HoA/HNP during the establishment of
> the
> > >  >>> IPSec
> > >  >>> SA, therefore the MR should request the MNP during this procedure
> as
> > >  >>> well.
> > >  >>
> > >  >>>>>>>> Since MR can act as MN, MR should be able to bootstrap with
> the
> > >  >>>>>>>> same

---

From: Frank Xia <[email-masked]>
Date: Mon, 09 Jun 2008 12:53:49 -0500

Hi JMC

Firstly, the certificate issuing party is not supposed to be HA, so
the certificate does not mandatorily get from the HA.
Or, how does the HA get  the certificate of the MR?

Secondly, if the prefix information can't be sychronized between
the certificate issuing party and the HA, the prefix should not
included in the certificate.

There are same concerns with PMIPv6 when  you insist that
the certificate should be delegated from the HA.

There is no perfect solution but compromised solution.

BR
Frank

----- Original Message ----- 
From: "Jean-Michel Combes" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "fan zhao" <[email-masked]>; <[email-masked]>; "Julien Laganier" 
<[email-masked]>
Sent: Monday, June 09, 2008 11:05 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

>> > >  >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia 
>> > > <[email-masked]>
>> > >  >>> wrote:
>> > >  >>>>
>> > >  >>> are piggybacked together, e.g. during one message exchange. For 
>> > > the
>> MR
>> > >  >>> to work, it
>> > >  >>> no much difference between the operation of the MN and that of 
>> > > the
>> MR.
>> > >  >>> Furthermore,
>> > >  >>> If I understand correctly, PMIP is a slightly different case 
>> > > from
>> > >  >>> DSMIPv6/NEMO.
>> > >  >>> the MAG to request the HNP for the MN during the PBU/PBA 
>> > > exchange.
>> With
>> > >  >> I just do an analogy.   What I want to say is it makes sense if 
>> > > we
>> > >  >> integrate
>> > >  >> PD
>> > >  >> into NEMO.
>> > >  >
>> > >  > Fan> OK.
>> > >  >
>> > >  > Sincerely,
>> > >  > fan
>> > >  >
>> > >  >>
>> > >  >>>
>> > >  >>> What do you think?
>> > >  >>>
>> > >  >>> Sincerely,
>> > >  >>> fan
>> > >  >>>
>> > >  >>>>
>> > >  >>>> BR
>> > >  >>>> Frank
>> > >  >>>>
>> > >  >>>>>>> We must be able to extend a RFC 3963 MR with PD without 
>> > > forcing
>> the
>> > >  >>>>>>> bootstrap process in the picture. So I agree not to bring 
>> > > DHAAD
>> back
>> > >  >>>>>>> into the bootstrap...
>> > >  >>>>>>
>> > >  >>>>>> we agree then..
>> > >  >>>>>>
>> > >  >>>>>>> Until we define a new process and rev 3775 and 3963, we 
>> > > should
>> stay
>> > >  >>>>>> If the current HA is not PD-enabled and DHAAD returns 
>> > > different
>> HA,
>> > >  >>>>>> MR must de-register the binding from the current HA and tries 
>> > > to
>> > >  >>>>>> start
>> > >  >>>>>>>>> One aspect of network mobility support is the assignment 
>> > > of a
>> > >  >>>>>>>>> prefix
>> > >  >>>>>>>>> or prefixes to a Mobile Router (MR) for use on the links 
>> > > in
>> the
>> > >  >>>>>>>>> implementation to automatically retrieve the ASCII version 
>> > > of
>> the
>> > >  >>>>>>>>> Internet-Draft.
>> > >  >>>>>>>>>
>> > >  >>>>>>>>>
>> > >  >>>>>>>>> Content-Type: text/plain

---

From: Julien Laganier <[email-masked]>
Date: Tue, 10 Jun 2008 09:11:41 +0200

On Friday 06 June 2008, Frank Xia wrote:
> I favor the integrated mode in which Prefix Delegation is integrated
> into NEMO operations because prefix management is an integrated part

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

---

From: "fan zhao" <[email-masked]>
Date: Tue, 10 Jun 2008 01:26:09 -0700

Hi Julien, Marcelo et al,

> on NEMO prefix delegation based on DHCPv6 PD a WG draft.

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.

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.

Thanks.

Sincerely,
fan

---

From: Julien Laganier <[email-masked]>
Date: Tue, 10 Jun 2008 11:01:22 +0200

On Tuesday 10 June 2008, fan zhao wrote:
> > 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.
>
> IMHO, the DHCP-PD solution leads to additional signaling overhead;

For the record I'm going to reply *once* to your technical input with WG 
chair hat off.

Signaling overhead is a non-issue in the context of prefix delegation 
since it will only happen once, when a MN becomes a MR.

> furthermore, using the DHCP Authentication Option introduces another
> layer of overhead/redundancy.

If this is a concern, the NEMO prefix delegation might not use the DHCP 
authentication option, and protect the DHCP PD signalling with an IPsec 
b/w MR and HA. The WG can decide what it wants.

> Therefore, my oponion is DHCP-PD should not be the only solution.

This is not to be discussed: We are chartered to specify one solution. 

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 10 Jun 2008 11:05:24 +0200

Hi Fan and thank you for the other private email, I take advantage of 
this to reply publicly.

>> 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.

> 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.

>  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

> Sincerely, fan
>>> IMHO,There are two ways for prefix delegation in Nemo, that is,
>>> overlay and integrated modes.
>>> 
>>> 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.
>>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 10 Jun 2008 11:15:37 +0200

Hello Alex,

> implementation and ready to modify it further.

Just for clarification, if the draft becomes a WG draft, it will of 
course be subject to modifications as per the WG consensus. This is the 
IETF process

> > furthermore, using the DHCP Authentication Option introduces
> > another layer of overhead/redundancy. Therefore, my oponion is
> > DHCP-PD should not be the only solution.
>

This is my understanding as well.

> > 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,
> 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).

And bottom line is that optimizing the efficiency of a one round-trip 
process that happens once when the MR boots up, and not in any critical 
path (e.g. handover) at the expense of modularity is questionable, 
IMHO.

--julien

---

From: "fan zhao" <[email-masked]>
Date: Tue, 10 Jun 2008 02:17:27 -0700

Hi Julien,

Thanks for your reply. Please see below.

> since it will only happen once, when a MN becomes a MR.
It also holds true for the IKEv2 based approach: the MR can just request once.
What I want to say is under the same condication, the IKEv2 based approach
is more efficient.

> b/w MR and HA. The WG can decide what it wants.
Sure.
Sorry we do not have a draft to describe the IKEv2 based approach yet.
Once it is uploaded, I hope it can make it clearer.

> This is not to be discussed: We are chartered to specify one solution.
Ok, I correct myself: my oponion is DHCP-PD should not be the solution.

Sincerely,
fan

---

From: "fan zhao" <[email-masked]>
Date: Tue, 10 Jun 2008 02:47:34 -0700

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:
>>
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.

> 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

>>>> DHCP based PD is a overlay solution which introduce redundancy while
>>>> trying to reduce impact on NEMO itself.
>>>>

---

From: "fan zhao" <[email-masked]>
Date: Tue, 10 Jun 2008 02:51:17 -0700

Sorry I miss one more step with the DHCP-PD when the MR is not at home
link. Please
see below.

> a DHCP reply message. Now the PD is completed.
One more step for the MR is that now the MR needs to send the BU message
again to the HA to register the binding between the HoA, the MNP and the CoA.

> It is also not as simple as saving two messages.
It is also not as simple as saving four messages (two dhcp messages plus BU/BA).
That is all. Thanks for reading.

Sincerely,
fan

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 10 Jun 2008 14:22:20 -0400

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. The mobile
router could just request for the mobile network prefix(es) in the BU
and get the information in the BAck. 

Vijay

> Behalf Of fan zhao
> Sent: Tuesday, June 10, 2008 2:48 AM
> To: Alexandru Petrescu
> Cc: [email-masked]; Julien Laganier

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 11 Jun 2008 17:27:23 +0200

Hi Frank,

At first I assume this is the HA that delegates the MNPs.

>  the certificate does not mandatorily get from the HA.

Agree. The HA has just to provide the cert.

>  Or, how does the HA get  the certificate of the MR?

HA may be the Certificate Authority or a Registration Authority.

>  included in the certificate.

AFAIK, the HA is always aware of the delegated MNPs: in explicit mode
with the Prefix Table and in implicit mode where it is assumed the HA
knows the MNPs in using a specific mechanism

>  the certificate should be delegated from the HA.

IMHO, this is the simplest solution when we assume this is the HA/LMA
that delegates the prefixes.

Best regards.

> > > > >  > On Fri, Jun 6, 2008 at 2:40 PM, Frank Xia
> <[email-masked]>
> > > wrote:
> > > > >  >> Hi Fan
> > > > >  >>
> > > > >  >> Please see my reply...
> > > > >  >>
> > > > >  >> BR
> > > > >  >> Frank
> > > > >  >>
> > > > >  >> ----- Original Message ----- From: "fan zhao" > >
> <[email-masked]>
> > > > >  >> Cc: "Ryuji Wakikawa" <[email-masked]>; "Julien > >
> Laganier"
> > > > >  >>> On Fri, Jun 6, 2008 at 10:51 AM, Frank Xia > >
> <[email-masked]>
> > > > >  >>> wrote:
> > > > >  >>>>
> > > > >  >>> If I understand correctly, PMIP is a slightly different case >
> > from
> > > > >  >>> DSMIPv6/NEMO.
> > > > >  >>> Because the connection, such as the IPSec SA, between the MAG >
> > and
> > > the
> > > > >  >>> LMA
> > > > >  >>> the MAG to request the HNP for the MN during the PBU/PBA > >
> exchange.
> > > With
> > > > >  >>> SA, therefore the MR should request the MNP during this > >
> procedure
> > > as
> > > > >  >>> well.
> > > > >  >>
> > > > >  >>>> Cc: "Julien Laganier" <[email-masked]>; > >
> <[email-masked]>
> > > > >  >>>>> I agree with Ryuji that the DHCP based PD procedure
> introduces
> > > > >  >>>>> redundancy.
> > > > >  >>>>>>> We must be able to extend a RFC 3963 MR with PD without > >
> forcing
> > > the
> > > > >  >>>>>>> bootstrap process in the picture. So I agree not to bring >
> > DHAAD
> > > back
> > > > >  >>>>>>> into the bootstrap...
> > > > >  >>>>>>
> > > > >  >>>>>> we agree then..
> > > > >  >>>>>>
> > > > >  >>>>>>> Until we define a new process and rev 3775 and 3963, we > >
> should
> > > stay
> > > > >  >>>>>> If the current HA is not PD-enabled and DHAAD returns > >
> different
> > > HA,
> > > > >  >>>>>> MR must de-register the binding from the current HA and
> tries > > to
> > > > >  >>>>>> start
> > > > >  >>>>>>>> We should not bring DHAAD back in the bootstrap process >
> > only
> > > for
> > > > >  >>>>>>>> PD.
> > > > >  >>>>>>>>
> > > > >  >>>>>>>> regards,
> > > > >  >>>>>>>> ryuji
> > > > >  >>>>>>>>
> > > > >  >>>>>>>>
> > > > >  >>>>>>>>> draft-droms-mext-nemo-pd-00.txt as the WG document for
> the
> > > Nemo PD
> > > > >  >>>>>>>>> Please provide comments so we cna make some progress on >
> > this
> > > long
> > > > >  >>>>>>>>> overdue deliverable
> > > > >  >>>>>>>>>
> > > > >  >>>>>>>>> implementation to automatically retrieve the ASCII
> version > > of
> > > the
> > > > >  >>>>>>>>> Internet-Draft.
> > > > >  >>>>>>>>>
> > > > >  >>>>>>>>>
> > > > >  >>>>>>>>> Content-Type: text/plain
> > > > >  >>>>>>>>> Internet-Draft directories: > >
> http://www.ietf.org/shadow.html
> > > > >  >>>>>>>>> or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > >  >>>>>>>>>
> > > > >  >>>>>>>>>

---

From: Frank Xia <[email-masked]>
Date: Wed, 11 Jun 2008 10:38:57 -0500

Hi JMC

Thank for your response, please see my inline comments...

BR
Frank

----- Original Message ----- 
From: "Jean-Michel Combes" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "fan zhao" <[email-masked]>; <[email-masked]>; "Julien Laganier" 
<[email-masked]>
Sent: Wednesday, June 11, 2008 10:27 AM
Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt?

> HA may be the Certificate Authority or a Registration Authority.
Frank=>IMHO, it seems to be impossible.
In extreme case, there are probably thousands of HA in the a
administrative domain.  (In 3GPP,  if a serving gateway and a
PDN gateway are collocated, the distributed HA network is possible)

>> > > > >  >>> needs both a HoA/HNP and a MNP. Besides 
>> > > > > requesting/registering
>> > > the
>> > > > >  >>> MNP, there is
>> > > > >  >>> the MR can request the MNP during the establishment of IPSec 
>> > > > > SA
>> > > when
>> > > > >  >>> is already in place long before the MN attaches to the MAG, 
>> > > > > it
>> > > makes
>> > > > >  >>> sense
>> > > > >  >>> for
>> > > > >  >>> DSMIPv6, the MN requests the HoA/HNP during the 
>> > > > > establishment
>> of
>> > > the
>> > > > >  >>> IPSec
>> > > > >  >>>>> IMHO, the MR can request a MNP together with a HNP/HoA 
>> > > > > when
>> > > > >  >>>>> establishing
>> > > > >  >>>>>> Sorry for late response. We have interop event in Tokyo 
>> > > > > and
>> > > tested
>> > > > >  >>>>>> HAHA there;-)
>> > > > >  >>>>>>
>> > > > >  >>>>>>> I agree that PD should not impact bootstrap. These are 
>> > > > > and
>> > > should be
>> > > > >  >>>>>>> kept unrelated.
>> > > > >  >>>>>>>
>> > > > >  >>>>>>>> From: [email-masked] 
>> > > > > [mailto:[email-masked]]
>> > > On
>> > > > >  >>>>>>>> Behalf Of
>> > > > >  >>>>>>>
>> > > > >  >>>>>>> Ryuji Wakikawa
>> > > > >  >>>>>>>>
>> > > > >  >>>>>>>> We should not bring DHAAD back in the bootstrap process 
>> > > > >  >
>> > only
>> > > for
>> > > > >  >>>>>>>> PD.
>> > > > >  >>>>>>>>
>> > > > >  >>>>>>>> regards,
>> > > > >  >>>>>>>> ryuji
>> > > > >  >>>>>>>>
>> > > > >  >>>>>>>>
>> > > > >  >>>>>>>>> Mobile Network.  DHCPv6 prefix delegation can be used 
>> > > > > for
>> > > this
>> > > > >  >>>>>>>>> configuration task.
>> > > > >  >>>>>>>>>
>> > > > >  >>>>>>>>> Below is the data which will enable a MIME compliant 
>> > > > > mail
>> > > reader

---

From: Julien Laganier <[email-masked]>
Date: Fri, 13 Jun 2008 17:42:14 +0200

Folks,

We have a WG consensus to adopt draft-droms-mext-nemo-pd-00.txt as a WG 
draft corresponding to the Nemo Prefix Delegation work item. 

Authors, please resubmit the draft as WG draft under the name:

	draft-ietf-mext-nemo-pd-00.txt

Note: you can use the online I-D submission tool to make it faster: 
<https://datatracker.ietf.org/idst/upload.cgi>

Thanks.

--julien & marcelo, MEXT chairs.