Subject: Re: [netlmm] Terminology confusion in draft-sgundave-mip6-proxymip6-01

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Jan 2007 12:36:59 -0800 (PST)

Absolutely.
An HA with extensions is still an HA and there is precedence from NEMO RFC 3963. 
In WiMAX SDO, PMIPv4 is being defined and it is almost completed and it has never been an issue as far as know to call HA of PMIPv4 something else and there too CMIPv4 has also been defined and MS can be in either mode.

Regards,

--behcet

----- Original Message ----
From: Singh Ajoy-ASINGH1 <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>; "Tsirtsis, George" <[email-masked]>; Kilian Weniger <[email-masked]>; [email-masked]
Sent: Thursday, January 18, 2007 2:05:55 PM
Subject: RE: [netlmm] Terminology confusion in draft-sgundave-mip6-proxymip6-01

Hi, Vidya, 

I am fine with using different terminology. However, my comment was
mostly related to maximizing the 
re-use of MIPv6 HA and allowing the support of MIPv6 and P-MIPv6
functionality by a single HA. This is 
important because of business reasons. If we can ensure that same HA can
be deployed as global as well 
as local mobility anchor then it will reduce the overall production cost
of PMIP and CMIP based mobility 
anchor and enhance deployment of MIPv6 / PMIPv6 based solution. IMHO,
this is important irrespective of 
deployment scenarios that we can envisage.    

Regards,
Ajoy  

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 1:01 PM
To: Singh Ajoy-ASINGH1; Tsirtsis, George; Kilian Weniger;
[email-masked]
Subject: RE: [netlmm] Terminology confusion in
draft-sgundave-mip6-proxymip6-01

Using unambiguous terminology does not in any way imply that we are
re-inventing the whole protocol. I think it is important to distinguish
between the two. The relation between PMIP6 and MIP6 is not exactly like
NEMO and MIP6 - NEMO is an extension of MIP6, which cannot exist without
MIP6 (so, a NEMO HA automatically implies support for MIP6). PMIP6,
OTOH, may actually be used in a system with no MIP6 or vice-versa. Also,
PMIP6 and MIP6 may be architecturally combined in a few different ways.
Let's take one example. These protocols may be deployed to provide a
two-level mobility management for a given MN, where the MIP6 CoA
mobility within a PMIP domain is handled by PMIP6 and the HoA is handled
by MIP6 - by re-using MIP6 terminology in PMIP6, the CoA in MIP6 will
become the HoA in PMIP6 and that would be very confusing.

This is not much unlike HMIP6 and MIP6 - HMIP6 is an incremental change
to MIP6, but, can be used with or without MIP6. If the MIP6 terminology
was re-used exactly in HMIP6 (without using RCoA/LCoA/MAP terminology),
it would have caused a lot of confusion, just like what seems to be the
case here. 

This is especially problematic for end users of this protocol, who are
trying to fit PMIP6 and MIP6 together in the same network. As a
protocol, PMIP6 shouldn't assume the existence or non-existence of MIP6
and it is better we have terminology that can identify whether the
specific entity/attribute is a PMIP6 one or MIP6 one. 

Again, I stress that this DOES NOT mean we are re-inventing the
protocol. It just helps with discussions and adds clarity to the
document. 

Vidya

> -----Original Message-----
> From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> Sent: Thursday, January 18, 2007 9:03 AM
> To: Tsirtsis, George; Kilian Weniger; [email-masked]
> Subject: RE: [netlmm] Terminology confusion in
> draft-sgundave-mip6-proxymip6-01
> 
> George / Kilan,
> 
> I also fully agree with you. We should not re-invent entirely new 
> protocol in the name of PMIPv6.  IMHO, the success of
> PMIPv6 will depend how much HA re-use we have achieved.. 
> Probably we should only focus on support of IPv6 traffic in base 
> draft.
> 
> Regards,
> Ajoy
> 
> -----Original Message-----
> From: Tsirtsis, George [mailto:[email-masked]]
> Sent: Thursday, January 18, 2007 5:16 AM
> To: Kilian Weniger; [email-masked]
> Subject: RE: [netlmm] Terminology confusion in
> draft-sgundave-mip6-proxymip6-01
> 
> Hi Kilian,
> 
> I fully agree with you. The whole point of basing this work on PMIP is

> to base the protocol on MIP i.e., PMIP should be a delta on MIP, not 
> an entirely different protocol.
> 
> If PMIP becomes an entirely different protocol then how do we expect 
> PMIP to utilize already defined MIP extension for things like support 
> for Dual Stack, NEMO and others??
> 
> George
> 
> > -----Original Message-----
> > From: Kilian Weniger [mailto:[email-masked]]
> > Sent: Thursday, January 18, 2007 4:02 AM
> > To: [email-masked]
> > Subject: RE: [netlmm] Terminology confusion in draft-sgundave-mip6-
> > proxymip6-01
> > 
> > Hi Julien, hi Behcet,
> > 
> > I agree that "HA" as PMIPv6 anchor name may cause some
> confusion when
> > discussing interaction between PMIPv6 and MIPv6. However,
> IMHO it has
> > benefits if "HA" would still be part of the name, in order
> to express
> > the fact that a major part of the entity is equivalent to a
> HA (i.e.,
> it
> > is an RFC3775 HA with some extensions/modifications).
> > 
> > BTW, a NEMO-capable HA is also called HA (or a
> MONAMI6-capable HA, a
> > DSMIP-capable HA etc), even though the functionality of the
> entity is
> > not exactly the same than a RFC3775 HA.
> > 
> > So how about PMIPv6-capable HA, or short PMIP6-HA, or even shorter
> pHA?
> > 
> > Regards,
> > 
> > Kilian
> > 
> > > -----Original Message-----
> > > From: Julien Laganier [mailto:[email-masked]]
> > > Sent: Donnerstag, 18. Januar 2007 09:21
> > > To: Behcet Sarikaya
> > > Cc: [email-masked]
> > > Subject: Re: [netlmm] Terminology confusion in
> > > draft-sgundave-mip6-proxymip6-01
> > >
> > > On Wednesday 17 January 2007 21:48, Behcet Sarikaya
> > > wrote:
> > > > Hello Julien,
> > >
> > > Hi Behcet,
> > >
> > > > > Hi Vidya,
> > > > >
> > > > > As I said earlier, I support using the NETLMM
> terminology we've
> > > > > been using since the WG started.
> > > > >
> > > > > I agree with you that re-use of MIP6 terminology is confusing 
> > > > > (That was one reason why we defined LMA in the first
> place, to
> > > > > avoid confusion with the
> > > > > HMIPv6 MAP entity.)
> > > >
> > > > So LMA is not HA. I think this distinction is very
> important from
> > > > PMIP point of view. The consensus in SD was to use MIP based 
> > > > solution reusing entities like HA. So I see no reason
> to remove HA
> 
> > > > from a PMIP protocol. HA is something we know, they are
> deployed,
> > > > there are HA boxes, cards, etc. available.
> > > > Now, there is something called MAP as well, and it is
> not that we
> > > > don't like it but it is a different issue, i.e. the
> consensus was
> > > > not about P-HMIP in SD as far as I can tell.
> > >
> > > I think you are confusing things by equating the
> consensus we had to
> 
> > > develop a NETLMM solution based on PMIP with both:
> > >
> > >    1. NETLMM bits-on-the-wire based on MIP
> > >       bits-on-the-wire, and
> > >
> > >    2. NETLMM network entities are the same than MIP
> > >       network entities
> > >
> > > While I agree that the consensus we had implies 1, it
> certainly does
> 
> > > not imply 2.
> > >
> > > MIP is a protocol, not a system architecture, so
> considerations on
> > > placement and collocation of MIP/PMIP network entities is 
> > > out-of-scope of this WG, IMO.
> > >
> > > > Julien you should know how changing terms could affect
> things from
> 
> > > > your MN-AR draft?
> > >
> > > Changing terms does not affect protocol or system
> architecture. It
> > > does affect, however, the WG ability to have articulate
> discussions.
> > >
> > > Best,
> > >
> > > --julien
> > >
> > > >
> > > > Best,
> > > >
> > > > --julien
> > > >
> > > > On Tuesday 16 January 2007 23:15, Narayanan, Vidya
> > > >
> > > > wrote:
> > > > > All,
> > > > > Having followed all the discussion, I think there is some 
> > > > > confusion due to the re-use of MIP6 terminology in
> this draft. I
> 
> > > > > suggest that we really focus on the PMIP6 functionality and 
> > > > > design, and use terminology that can clearly
> distinguish it from
> 
> > > > > MIP6. So, I suggest the following terms:
> > > > >
> > > > > 1. PMA (Proxy Mobility Agent) or MAG (Mobility Access
> Gateway)
> > > > > 2. LMA (Local Mobility Agent) 3. PMIP IP Address
> (PIA) (Address
> > > > > assigned to the MN in the PMIP domain) 4. PMIP Tunnel Address
> > > > > (PTA) (Address of the PMA to which packets are to be sent)
> > > > >
> > > > > Particularly, since there are several possible realizations of
> > > > > MIP6 and PMIP6 feasible in a system, using the same
> terminology
> > > > > leads to confusion. As far as this protocol is concerned, it 
> > > > > should have its own functional entities.
> > > > > Depending on architecture choices, the functional elements of
> > > > > MIP6 and PMIP6 may be collocated.
> > > > >
> > > > > Vidya
> > > >
> > > > Regards,
> > > >
> > > > --behcet
> > >
> > > _______________________________________________
> > > netlmm mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/netlmm
> > >
> > >
> > 
> > 
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/netlmm
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 

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

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

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 18 Jan 2007 16:00:02 -0500

Alex, 

WIMAXForum has only defined PMIPv4 solution. PMIPv6 solution has not
been defined yet
 
Regards,
Ajoy 

-----Original Message-----
From: Petrescu Alexandru-AAP021 
Sent: Thursday, January 18, 2007 2:56 PM
To: Behcet Sarikaya
Cc: Singh Ajoy-ASINGH1; [email-masked]
Subject: Re: What's missing in WiMax? (was: [netlmm] Terminology
confusion in draft-sgundave-mip6-proxymip6-01)

Behcet Sarikaya wrote:
> Absolutely.
> An HA with extensions is still an HA and there is precedence from NEMO

> RFC 3963.
> In WiMAX SDO, PMIPv4 is being defined and it is almost completed

So what's missing in WiMax then?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 22:00:59 +0100

> WIMAXForum has only defined PMIPv4 solution. PMIPv6 solution has not

So maybe they should?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 21:56:28 +0100

Alex

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 18 Jan 2007 16:11:29 -0500

Hi, Alex, 

If we don't then they will. But I guess we need to define a single
solution that will be acceptable to 
3GPP, 3GPP2 and WIMAX and also align protocol design with their
architecture. 

Regards,
Ajoy 

-----Original Message-----
From: Petrescu Alexandru-AAP021 
Sent: Thursday, January 18, 2007 3:01 PM
To: Singh Ajoy-ASINGH1
Cc: Behcet Sarikaya; [email-masked]
Subject: Re: What's missing in WiMax?

So maybe they should?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Jan 2007 11:35:25 +0100

Singh Ajoy-ASINGH1 wrote:
> solution that will be acceptable to 3GPP, 3GPP2 and WIMAX and also
> align protocol design with their architecture.

I completely disagree with the urgency aspect, my workplan is not along 
the plan of WiMax.

However, I do agree a solution that works across 3GPP and WiMax and many 
other links towards the mobile is very desirable.

That is why I oppose exclusive dependency on NAI and AAA for access. 
Triggering movement shouldnt happen _only_ on NAI/AAA events, it should 
happen on several types of events.

If DHCP is used on mobile then trigger is DHCP.
If PANA/Diameter is used then trigger is PANA.
If slaac is used then slaac or ND is trigger.
If BOOTP is used then BOOTP is trigger.
If PPPv6/Diameter is used then PPPv6 is trigger.

Basically address acquisition is the trigger and there are several ways 
of doing address acquisition.

Alex

> 
> Regards, Ajoy
> 
> 
> -----Original Message----- From: Petrescu Alexandru-AAP021 Sent:
> Thursday, January 18, 2007 3:01 PM To: Singh Ajoy-ASINGH1 Cc: Behcet
> Sarikaya; [email-masked] Subject: Re: What's missing in WiMax?
> 
>> WIMAXForum has only defined PMIPv4 solution. PMIPv6 solution has
>> not been defined yet
> 
> So maybe they should?
> 
> Alex
> 
>> 
>> Regards, Ajoy
>> 
>> 
>> -----Original Message----- From: Petrescu Alexandru-AAP021 Sent:
>> Thursday, January 18, 2007 2:56 PM To: Behcet Sarikaya Cc: Singh
>> Ajoy-ASINGH1; [email-masked] Subject: Re: What's missing in WiMax?
>> (was: [netlmm] Terminology confusion in
>> draft-sgundave-mip6-proxymip6-01)
>> 
>> Behcet Sarikaya wrote:
>>> Absolutely. An HA with extensions is still an HA and there is
>>> precedence from NEMO RFC 3963. In WiMAX SDO, PMIPv4 is being
>>> defined and it is almost completed

---

From: "Osvaldo Gonsa" <[email-masked]>
Date: Fri, 19 Jan 2007 12:01:41 +0100

Alex,
>>However, I do agree a solution that works across 3GPP and WiMax and
many other links towards the mobile is very desirable

I agree completely with you statement above, however
 
Regarding your triggers below, have you considered the case that a
mobile that has a MIPv6 capable stack and runs Microsoft OS (whichever
flavour is on it) _always_ send a DHCP request after authentication and
before any MIPv6 signalling or for the case any address assignment
mechanism kicks in? Hence I think DHCP should not be used as trigger
(because you will replicate the same mistake that WiMax has done and for
which they are _still_ looking for a solution)

Regards

Osvaldo

Alex

>>> precedence from NEMO RFC 3963. In WiMAX SDO, PMIPv4 is being defined

>>> and it is almost completed

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Jan 2007 12:54:11 +0100

Osvaldo, thanks for the email.

Osvaldo Gonsa wrote:
> Alex,
>>> However, I do agree a solution that works across 3GPP and WiMax 
>>> and many other links towards the mobile is very desirable
> 
> mobile that has a MIPv6 capable stack and runs Microsoft OS 
> (whichever flavour is on it) _always_ send a DHCP request after 
> authentication and before any MIPv6 signalling or for the case any 
> address assignment mechanism kicks in?

Huh that's a long phrase, could you please restate the problem shorter,
thanks.  What exactly do you complain about?  If you're more specific we
can look at the specific problem.

Windows using DHCP together with MIPv6 instead of stateless+MIPv6?  I
think that's fine.  Windows also uses Teredo, which is another address
acquisition mechanism we could consider as a triggering mechanism in my
list.

DHCP req always _after_ auth?  That's fine too provided auth happens at
link layer, and I'm sure Windows doesn't do PANA.

Also, that Windows machine won't send a DHCP Request when it puts up a
ppp interface.   So on ppp DHCP is not in the way.  WiMAx uses ppp?
WiMax uses 802.16 network-entry procedure?  802.16 network-entry
procedure says clearly when DHCP should or shouldn't be used (the
problem is that rfc2461 says it too, and they may differ -
interoperability).

So let's see exactly what the problem is about and then we can deal with it.

> Hence I think DHCP should not be used as trigger (because you will 
> replicate the same mistake that WiMax has done and for which they are
>  _still_ looking for a solution)

I don't understand your point of view.

I sense in the message above you were saying Windows _always_ does DHCP
and you consider that bad.  Well I don't consider it bad at all: when
Windows does DHCP on a interface netlmm solution will use it to trigger
movement detection.

What we can do better than WiMax (no idea what WiMax is doing BTW) is
to suggest Windows to do ND/SLAAC RFC2461etal correctly, ie when RA says
no-DHCP then no-DHCP should be.

Another RFC we could suggest to Windows is DHCPv6 RFC3315 that says that
the host should send a CONFIRM from time to time or when it changes
link.  If Windows does send that CONFIRM then to me it is a perfect
trigger for netlmm-solution movement detection.

What do you think?

Alex

---

From: "Osvaldo Gonsa" <[email-masked]>
Date: Fri, 19 Jan 2007 13:20:11 +0100

Alex,
Sorry for the long phrase, (that's a problem some people tells me all
the time)
Please see embedded, 

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, January 19, 2007 12:54 PM
To: Osvaldo Gonsa
Cc: [email-masked]
Subject: Re: dhcp (was: address acquisition and triggers)

> flavour is on it) _always_ send a DHCP request after authentication 
> and before any MIPv6 signalling or for the case any address assignment

> mechanism kicks in?

OG>>I was referring not only for movement detection but for initial
network attachment as well. The problem I see is what is going to be
used to trigger the PMIPv6 mechanism? 

Windows using DHCP together with MIPv6 instead of stateless+MIPv6?
OG>> Yes

I think that's fine.  Windows also uses Teredo, which is another address
acquisition mechanism we could consider as a triggering mechanism in my
list.

OG>> I am sorry I was not aware that Windows also uses Teredo, however I
think it's not mainstream but I am OK with adding it to your list.

OG>> Yes, that's right

OG>> You hit in on the spot -interoperability is my main concern and I
see difficulties in trying to achieve this, hence I expect the experts
in this WG to find an efficient solution.

So let's see exactly what the problem is about and then we can deal with
it.

OG>> As I said above is not only about movement detection but about
co-existence with MIPv6 on the same domain and how to identify with
mechanism to use.

What we can do better than WiMax (no idea what WiMax is doing BTW) is to
suggest Windows to do ND/SLAAC RFC2461etal correctly, ie when RA says
no-DHCP then no-DHCP should be.

OG>> Good Luck in suggesting that to Microsoft,  but I am not that
optimistic since they are even reluctant to implement MIPv6 in their
stack for mobile nodes using their OS(es).

OG>> same as bove

Regards

Osvaldo

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Jan 2007 14:11:21 +0100

Osvaldo Gonsa wrote:
> Huh that's a long phrase, could you please restate the problem 
> shorter, thanks.  What exactly do you complain about?  If you're more
>  specific we can look at the specific problem.
> 

If that link prefers DHCP (like LAN, WiFi, maybe 802.16) then use DHCP
as trigger.  DHCP is a sequence of messages and has several scenarios
(discover, alloc, realloc, renew, confirm, etc).  Some of those are more
pertinent than others for triggering.

Draft-templin and draft-ietf-netlmm-mn-ar suggests DHCP CONFIRM and
REBIND.  Draft-sgundave suggests tagging the DHCP REQUEST by the AR.
Remark none of these modifies the mobile's dhcp implementation , so our
netlmm goal can be accomplished.  Which do you prefer?  Which other do
you think?

If that link prefers pppv6 then use pppv6 as triggerrs.  I propose to
use the PPPv6 ConfigReq with the option Interface-ID for which the peer
responds positively.  Do you like it?  Which other pppv6 trigger?

> Windows using DHCP together with MIPv6 instead of stateless+MIPv6? 

I think MIPv6 works fine with DHCPv6.  DHCPv6 does address allocation
and MIPv6 manages mobility, I don't see conflict.  Is the conflict about
Windows instead.

> I think that's fine.  Windows also uses Teredo, which is another 
> address acquisition mechanism we could consider as a triggering 
> mechanism in my list.
> 
> OG>> I am sorry I was not aware that Windows also uses Teredo, 
> however I think it's not mainstream but I am OK with adding it to 
> your list.

Well, Windows XP has mainstream SP2 and an IPv6 update that enables the
interface to be Teredo.  The Teredo interface has a method to assign an
IPv6 address on it.  That method could be used as a trigger to
netlmm-protocol (PMIP, netlmmDT, whatever).

One may check Vista and let know.

> OG>> You hit in on the spot -interoperability is my main concern and
>  I see difficulties in trying to achieve this, hence I expect the 
> experts in this WG to find an efficient solution.

Great, I think too IETF is often good at finding interoperable solutions.

>> I sense in the message above you were saying Windows _always_ does
>>  DHCP and you consider that bad.  Well I don't consider it bad at 
>> all: when Windows does DHCP on a interface netlmm solution will use
>>  it to trigger movement detection.
> 

Osvaldo, DHCPv6 and MIPv6 work ok IMHO, I don't see big problems.
RFC3775 (MIP6) talks about both.  I think though in detail there may be
issues needed clarification for MIPv6 movement detection and DHCPv6 (eg,
what to compare from the DHCP response message to identify it moved).

However, DHCPv6 and _P_MIPv6 is a different story... not sure what is
exactly actually.

>> What we can do better than WiMax (no idea what WiMax is doing BTW) 
>> is to suggest Windows to do ND/SLAAC RFC2461etal correctly, ie when
>>  RA says no-DHCP then no-DHCP should be.
> 

Osvaldo, I think we should reorient the discussion away from complaining
about Microsoft.  If anybody complained to you about DHCP+MIP+Microsoft
then I think you should have suggested to redirect the complain to
Microsoft and bring only the DHCP+MIP part to IETF.

Otherwise I agree with you that a strong netlmm goal is to have a mobile
node that is unmodified, check the Goals draft, Microsoft is not mentioned.

Alex

---

From: "Osvaldo Gonsa" <[email-masked]>
Date: Fri, 19 Jan 2007 14:25:14 +0100

Alex,
My intent is not to complain about Microsoft (although I am Mac fan ;-)
but to point out the problem that even with DHCPv6 and MIPv6, using the
DHCP messages for triggers may not be a good idea.
I see a problem with the OS(es) that always send DHCP messages
inmediately after authentication, in that the network may interpret
always that the mobile is not MIPv6 capable and will launch the PMIP
mechanism. 
So the problem becomes a problem of co-existence of MIPv6 and PMIPv6 in
which mobiles which are MIPv6 capable will always be treated with the
netlmm mechanism. 
There may be some cases in which this may impede load balancing, etc, in
the network in which the mobile is visiting.

Thanks for your responses

Best regards

Osvaldo

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, January 19, 2007 2:11 PM
To: Osvaldo Gonsa
Cc: [email-masked]
Subject: Re: dhcp

> however I think it's not mainstream but I am OK with adding it to your

> experts in this WG to find an efficient solution.

Great, I think too IETF is often good at finding interoperable
solutions.

>> to suggest Windows to do ND/SLAAC RFC2461etal correctly, ie when  RA 
>> says no-DHCP then no-DHCP should be.
> 

Otherwise I agree with you that a strong netlmm goal is to have a mobile
node that is unmodified, check the Goals draft, Microsoft is not
mentioned.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Jan 2007 15:01:30 +0100

Osvaldo Gonsa wrote:
> Alex, My intent is not to complain about Microsoft (although I am Mac
>  fan ;-) but to point out the problem that even with DHCPv6 and 
> MIPv6, using the DHCP messages for triggers may not be a good idea.

On a LAN and IPv6, the decision to launch mobile's DHCP or not is based
on the contents of the RA.  The RA tells  the MN whether it should do
DHCP or autoconfig statelessly.  MN checks the prefix in RA, finds out
it moves and all well.  MN doesn't know to check the DHCPv6 messages
(instead of RA) to realize it moved, at least it is not specified how by
rfc3775.  That's a DHCPv6+MIPv6 problem.

> inmediately after authentication,

So put M=1 in RA and mobile won't do DHCPv6.  That's specified and I
think many OS(es) follow that indication.

> in that the network may interpret always that the mobile is not MIPv6
>  capable and will launch the PMIP mechanism.

The network shouldn't try to decide whether the mobile is MIPv6-capable
or not.  The network should just run netlmm-solution (netlmmDT or
PMIPv6-).

The network knows whether itself does DHCPv6 or not.  If network decides
not to do DHCPv6 then the mobile won't do DHCP (based on RA contents).
There should be a similar mechanism in IPv4 (MIP4+DHCPv4, based on Agent
Advertisements, or similar).  If there isn't, then it should be
specified, but not here, because this group currently does IPv6.

> So the problem becomes a problem of co-existence of MIPv6 and PMIPv6
>  in which mobiles which are MIPv6 capable will always be treated with
>  the netlmm mechanism.

Which is good.  Mobiles that do MIPv6 should be treated just like the
mobiles that don't, and netlmm-protocol can do that.  If the network
acts such that the mobile always auto-configures the same IPv6 address
(within the netlmm domain of links) then the MIPv6 implementation on MN
won't be executed.  But these are high-level words I use, and I agree
the co-existence should be continuosly checked in specs.

> There may be some cases in which this may impede load balancing, etc,
>  in the network in which the mobile is visiting.

Yes, we can see about these.  Let's keep this thread on DHCP.

Alex