Subject: [netlmm] MIP6 HoA and PMIPv6 pHoA

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 1 Feb 2007 01:50:42 -0800

One of the possible ways of allowing PMIPv6 and MIP6 to co-exist is by
allowing a MIP6 HoA of an MN to be a PMIP6 pHoA within a PMIP domain.
This potentially causes a given binding to be updated by the MN and the
PMAs. This presents several problems as summarized below. 

1. The PMA is the default router and the entity generating the RAs to
the MN. In order for the MN to detect that it is on the home link, a
couple of different things may happen. The RA from the HA must be
available to the MN with the H bit set and the source link-layer
address. In accordance with RFC3775, the MN must multicast an RS - such
a multicast RS in the PMIP domain will (and should) not be sent beyond
the PMA, as the PMIP domain is not treated as a broadcast domain. 

2. As I noted in another email, the consensus on the unique prefix per
MN model for global IP addressing still holds. In this case, the RA sent
to the MN has its own prefix - hence, there is really no scope to have
that be the home link prefix as well - there can be no H bit set on
that, for one. 

3. A MIP6 HA, upon receiving a de-registration, will stop defending the
HoA of the MN. In this case, the HA must continue to defend the address
and intercept packets belonging to the MN. I realize that the pBU will
kick that process off again, but, the changes to the HA behavior would
still need to be described. This is especially problematic if the PMIP
and MIP BCEs are the same - for e.g., what if the de-registration
reaches after the pBU? It is not within the charter to modify any MIP6
behaviors to define PMIP - so, we have to be careful about where this
leads us. 

4. A similar impact will be on the MIP6 behavior of the MN - the MN must
send an unsolicited NA upon returning home, in accordance with RFC3775;
but, the MN will not do this after a link change within the PMIP domain.

5. If the MN moves back and forth between two PMAs associated with
different LMAs, the pBU and the BU at the LMA/HA may create race
conditions. The sequence numbers are obviously not synchronized and
hence, there is really no way to tell which is the latest one. 

6. The security model of PMIP and MIP are vastly different. PMIP
operates with a notable risk that in the event of a PMA compromise, it
is feasible to redirect traffic belonging to any address within the PMIP
domain. If the PMA is authorized to send BUs for the MN's MIP HoA, a
compromised PMA can redirect traffic belonging to an MN even when the MN
is no longer in that domain. In this case, PMIP is extending the threat
to the scope of MIP6 and this is not acceptable. 

7. The different security models also lead to IPsec processing
differences. For MIP6, the SPD must be checked against the HoA of the
MN. For PMIP6, the SPD must be checked against the PMA's IP address
(which is often the pCoA or simply, the source address of the pBU). When
a given IP address is both the MIP6 HoA and the PMIP6 pHoA, there is an
issue with IPsec processing due to the differences in the two models.
This would result in improper (or even lack of) authorization of the
MIP6 BUs, resulting in an undesirable and unacceptable impact to MIP6
security. 

For all the above reasons, I suggest explicitly disallowing the case of
MIP6 HoA and PMIP6 pHoA being the same. 

Vidya

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 1 Feb 2007 11:03:46 -0800 (PST)

Vidya,

I do not agree with this restriction.

1. There are clear sementics for the home agent to differentiate
    a BU from a PBU and apply the corresponding security model.

2. There is one race condition as we mentioned before in the ML,
    when the CMIP enabled mobile rapidly moves from PMIP link to
    a normal link and the home agent receives BU's and PBU's in
    out of order, there is an issue with the ordering. We have
    suggested the use of time stamp, optionally, even for BU's
    from a CMIP client to resolve this issue. If that is not
    acceptible, this can be properly documented. Also, note that
    this is a rare corner case, BU's have to be out of ordered,
    the PMIP/CMIP links have to be located right next, MN needs
    to be configured for this ...etc. When all this fall in place,
    this issue occurs.

3. Typically, all operators configure mobile's to be a virtual link.
    Now, if we go for Per-MN-Prefix model, I cannot imagine any
    operator configuring a million home prefixes on a phsyical
    interfaces. The going home issue and the NA is not relevant for
    PMIP.

4. I think this restriction is very expensive and architecturally
    limits the PMIP scope. I suggest, we document issues around
    CMIP-PMIP coexistence and leave the operator a deployment choice.

Other comments ..see inline ..

Sri

> the PMA, as the PMIP domain is not treated as a broadcast domain.

The point is that, the mobile should be able to detect its home link.
The RA's must contain the home prefix. If the RA is unicasted or
multicasted is a different issue. If there is a MUST requirement,
we should relax that for this scenario.

> that be the home link prefix as well - there can be no H bit set on

If the home link is virtual, there is no issue on this either.

> behaviors to define PMIP - so, we have to be careful about where this

As discussed in the ML, the home link for PMIP in general will be
on a virtual link. Typically, the home agent will have a route for
the mobile's prefix and will not involve in any ND related operations.

> but, the MN will not do this after a link change within the PMIP domain.

Home is typically configured on a virtual link.
Besides, In the per-MN-prefix model, why is this relevant ?

> hence, there is really no way to tell which is the latest one.

We have suggested the use of time stamp for resolving the uniqueness
in such situations. Optionally, BU's from the client MAY have the
time stamp option and the home agent can predictably identify the
latest time stamped BU. Also, this reflects a specific network
topology and is a corner case.

> to the scope of MIP6 and this is not acceptable.

Compromised home agent can do the same thing as well. The same
threat applies to NEMO MNP prefixes. Home agent can certainly
apply proper authorization checks on who can send a PBU's. I
do not think this introduces any new threat.

> MIP6 BUs, resulting in an undesirable and unacceptable impact to MIP6

There are clear sementics on how the home agent can distinguish
between a BU and PBU. The home agent will always be able to identify
the type of registration and the corresponding security method
that it needs to apply. If we fail to achive that, I will agree with
this comment.

> MIP6 HoA and PMIP6 pHoA being the same.

I think this restriction is very expensive and architecturally limits
the PMIP scope. I do not agree this restriction.

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 1 Feb 2007 12:51:22 -0800

Hi Sri,

Excellent analysis. For what is worth, I agree with you completely. 

Regards
George

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Thursday, February 01, 2007 2:04 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [netlmm] MIP6 HoA and PMIPv6 pHoA
> 
> 
> Vidya,
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 1 Feb 2007 16:42:02 -0800

Hi Sri,
Given the prefix-per-MN global addressing model, this discussion is
probably moot - in that model, the MIP6 HoA cannot be the PMIP address
anyway. So, I won't spend a lot of time on this discussion, but there
are still some points worth noting. Please see inline.  

> Sent: Thursday, February 01, 2007 11:04 AM
> To: Narayanan, Vidya
> Cc: [email-masked]
>     from a CMIP client to resolve this issue. 

Updating RFC3775 MN behavior is not within the scope of this WG.
However, we do need to ensure that PMIPv6 does not affect the operation
of MIP6 when used in the same network. 

> If that is not

Not sure what you mean by MN needs to be configured, but, when the MN is
at the border of two PMIP domains, for instance, this behavior can
happen. It depends on how often a given MN geographically visits that
point - and the protocol cannot dismiss it as a rare event in my view.
Here is where PMIP gets into stepping on the correct operation of MIP6
and that's the real issue here. 

> > This potentially causes a given binding to be updated by the MN and 
> > the PMAs. This presents several problems as summarized below.
> >
> > address. In accordance with RFC3775, the MN must multicast an RS - 
> > such a multicast RS in the PMIP domain will (and should) 
> not be sent 
> > beyond the PMA, as the PMIP domain is not treated as a 
> broadcast domain.
> >
> 
> The RA's must contain the home prefix. If the RA is unicasted 
> or multicasted is a different issue. If there is a MUST 
> requirement, we should relax that for this scenario.
> 

Relaxing anything in RFC3775 for sake of PMIP is not an option - please
do keep that in mind. 

> > MN model for global IP addressing still holds. In this case, the RA 
> > sent to the MN has its own prefix - hence, there is really 
> no scope to 
> > have that be the home link prefix as well - there can be no 
> H bit set 
> > on that, for one.
> 
> 
> > 3. A MIP6 HA, upon receiving a de-registration, will stop defending 
> > the HoA of the MN. In this case, the HA must continue to defend the 
> > address and intercept packets belonging to the MN. I 
> realize that the 
> > pBU will kick that process off again, but, the changes to the HA 
> > behavior would still need to be described. This is especially 
> > problematic if the PMIP and MIP BCEs are the same - for 
> e.g., what if 
> > the de-registration reaches after the pBU? It is not within the 
> > charter to modify any MIP6 behaviors to define PMIP - so, 
> we have to 
> > be careful about where this leads us.
> >
> 
> 
> As discussed in the ML, the home link for PMIP in general 
> will be on a virtual link. Typically, the home agent will 
> have a route for the mobile's prefix and will not involve in 
> any ND related operations.
> 

Again, in view of the prefix-per-MN model, this discussion is not
needed. 

> 
> > 4. A similar impact will be on the MIP6 behavior of the MN - the MN 
> > must send an unsolicited NA upon returning home, in accordance with 
> > RFC3775; but, the MN will not do this after a link change 
> within the PMIP domain.
> >
> 
> We have suggested the use of time stamp for resolving the 
> uniqueness in such situations. Optionally, BU's from the 
> client MAY have the time stamp option and the home agent can 
> predictably identify the latest time stamped BU. Also, this 
> reflects a specific network topology and is a corner case.
> 

Same point as what I've clarified above. 

> > is feasible to redirect traffic belonging to any address within the 
> > PMIP domain. If the PMA is authorized to send BUs for the MN's MIP 
> > HoA, a compromised PMA can redirect traffic belonging to an MN even 
> > when the MN is no longer in that domain. In this case, PMIP is 
> > extending the threat to the scope of MIP6 and this is not 
> acceptable.
> >
> 
> 
> Compromised home agent can do the same thing as well. The 
> same threat applies to NEMO MNP prefixes. Home agent can 
> certainly apply proper authorization checks on who can send a 
> PBU's. I do not think this introduces any new threat.
> 
> 

You are missing the point here. When a given entity is compromised, any
service provided by that entity is obviously affected and that is a
given. In the case of network-based mobility, the compromise of an AR
already has the potential to affect the PMIP service in the entire
domain and this has already been noted. When the compromised of an AR
leads to affecting the MIP6 service to an MN beyond the PMIP domain that
the AR is serving in, it extends the threat to the scope of MIP6 and
that is not acceptable. 

> > (which is often the pCoA or simply, the source address of the pBU). 
> > When a given IP address is both the MIP6 HoA and the PMIP6 
> pHoA, there 
> > is an issue with IPsec processing due to the differences in 
> the two models.
> There are clear sementics on how the home agent can 
> distinguish between a BU and PBU. The home agent will always 
> be able to identify the type of registration and the 
> corresponding security method that it needs to apply. If we 
> fail to achive that, I will agree with this comment.
> 

In both cases, the HA is using IPsec for security. On this point,
however, thinking about it further, it seems like it can be made to
work. 

All other problems noted above are still true. 

> 
> > For all the above reasons, I suggest explicitly disallowing 
> the case 
> > of
> I think this restriction is very expensive and 
> architecturally limits the PMIP scope. I do not agree this 
> restriction.

Not true. This restriction puts the PMIP scope where it belongs - within
the PMIP domain. Once again, hopefully, we don't need much discussion on
this point with the prefix-per-MN global addressing model anyway. 

Regards,
Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 1 Feb 2007 16:51:18 -0800 (PST)

Hi Vidya,

Lets hear from others in the WG on this. I'll defer my
comments for now.

Regards !
Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 01 Feb 2007 21:31:12 -0600

Vidya,

I tend to agree with Sri's comments as well about the usage of the MIP6 HoA
as the PMIP address. Is the " prefix-per-MN global addressing model" a
baseline assumption?

-Raj

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 1 Feb 2007 23:06:55 -0500

Vidya, 

I also agree with Sri and Raj about using MIPv6 HoA as PMIP address.
Additionally, I am not sure why we 
need to limit NETLMM solution to consider per-prefix address only? IMHO,
probably we should first define 
PMIPv6 solution by making appropriate modifications to base MIPv6 RFC
(i.e. RFC 3775)  and then worry 
about any extensions such as IPv4 support, per-MN prefix etc in separate
document? IMHO, these are important but 
will be useful features for both local and global mobility and need to
be addressed in general MIPv6 context. 
Am I missing anything here?  

Regards,
Ajoy  

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Thursday, February 01, 2007 9:31 PM
To: ext Sri Gundavelli; Narayanan, Vidya
Cc: [email-masked]
Subject: Re: [netlmm] MIP6 HoA and PMIPv6 pHoA

Vidya,

I tend to agree with Sri's comments as well about the usage of the MIP6
HoA as the PMIP address. Is the " prefix-per-MN global addressing model"
a baseline assumption?

-Raj

On 2/1/07 6:51 PM, "ext Sri Gundavelli" <[email-masked]> wrote:

> 
> Hi Vidya,
> 
> Lets hear from others in the WG on this. I'll defer my comments for 
> now.
> 
> Regards !
> Sri
> 
> 
> 
>> probably moot - in that model, the MIP6 HoA cannot be the PMIP 
>> address anyway. So, I won't spend a lot of time on this discussion, 
>> but there are still some points worth noting. Please see inline.
>> 
>> However, we do need to ensure that PMIPv6 does not affect the 
>> operation of MIP6 when used in the same network.
>> 
>>> If that is not
>> Not sure what you mean by MN needs to be configured, but, when the MN

>> is at the border of two PMIP domains, for instance, this behavior can

>> Here is where PMIP gets into stepping on the correct operation of 
>> MIP6 and that's the real issue here.
>> 

>>> multicasted is a different issue. If there is a MUST requirement, we

>>> should relax that for this scenario.
>>> 
>> 
>> Relaxing anything in RFC3775 for sake of PMIP is not an option - 
>> please do keep that in mind.
>> 
>>> 

>>> As discussed in the ML, the home link for PMIP in general will be on

>>> a virtual link. Typically, the home agent will have a route for the 
>>> mobile's prefix and will not involve in any ND related operations.
>>> 
>> 

>>> threat applies to NEMO MNP prefixes. Home agent can certainly apply 
>>> proper authorization checks on who can send a PBU's. I do not think 
>>> this introduces any new threat.
>>> 
>>> 
>> 
>> You are missing the point here. When a given entity is compromised, 
>> any service provided by that entity is obviously affected and that is

>> a given. In the case of network-based mobility, the compromise of an 
>> AR already has the potential to affect the PMIP service in the entire

>> leads to affecting the MIP6 service to an MN beyond the PMIP domain 
>> that the AR is serving in, it extends the threat to the scope of MIP6

>> and that is not acceptable.
>> 
>>> 

>>> the type of registration and the corresponding security method that 
>>> it needs to apply. If we fail to achive that, I will agree with this

>>> comment.
>>> I think this restriction is very expensive and architecturally 
>>> limits the PMIP scope. I do not agree this restriction.
>> 
>> Not true. This restriction puts the PMIP scope where it belongs - 
>> within the PMIP domain. Once again, hopefully, we don't need much 
>> discussion on this point with the prefix-per-MN global addressing
model anyway.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 1 Feb 2007 22:59:01 -0800

Hi Raj,

> Sent: Thursday, February 01, 2007 7:31 PM
> I tend to agree with Sri's comments as well about the usage 
> of the MIP6 HoA as the PMIP address. 

I understand the potential use case, but, I am quite skeptical of
stepping over MIP6 functions. In this usage, we are basically providing
the option of a MIP6 binding to be modified by an entity other than the
MN, when MIP6 is designed such that no entity other than the MN can be
authorized to do that. All the issues pointed out have to do with that
meta point. I'm willing to be convinced it is not a problem - so far, I
have not seen it. 

Also, changing MIP6 to fit the needs of NETLMM is not something we can
do based on the current charter. 

> Is the " prefix-per-MN 
> global addressing model" a baseline assumption?
> 

Yes. That was the WG consensus on the list (a lot of email on this, if
you want to dig up the archives :)) and one of the ground rules in
picking a solution was to stick with the link model decisions (see
Jari's slide from the NETLMM SD meeting). 

Vidya 

> will be on 
> uniqueness 
> >> discussion on this point with the prefix-per-MN global 
> addressing model anyway.
> >> 
> >> Regards,
> >> Vidya
> >> 
> >

---

From: Julien Laganier <[email-masked]>
Date: Fri, 2 Feb 2007 15:31:55 +0100

Hi Vidya,

More below,

On Thursday 01 February 2007 10:50, Narayanan, Vidya 
wrote:
> One of the possible ways of allowing PMIPv6 and MIP6
> to co-exist is by allowing a MIP6 HoA of an MN to be
> a PMIP6 pHoA within a PMIP domain. This potentially
> causes a given binding to be updated by the MN and
> 1. The PMA is the default router and the entity
> generating the RAs to the MN. In order for the MN to
> detect that it is on the home link, a couple of
> different things may happen. The RA from the HA must
> be available to the MN with the H bit set and the
> source link-layer address. In accordance with
> RFC3775, the MN must multicast an RS - such a
> multicast RS in the PMIP domain will (and should)
> not be sent beyond the PMA, as the PMIP domain is
> not treated as a broadcast domain.
>
> 2. As I noted in another email, the consensus on the
> unique prefix per MN model for global IP addressing
> still holds. In this case, the RA sent to the MN has
> its own prefix - hence, there is really no scope to
> have that be the home link prefix as well - there
> can be no H bit set on that, for one.
>
> 3. A MIP6 HA, upon receiving a de-registration, will
> stop defending the HoA of the MN. In this case, the
> HA must continue to defend the address and intercept
> packets belonging to the MN. I realize that the pBU
> will kick that process off again, but, the changes
> to the HA behavior would still need to be described.
> This is especially problematic if the PMIP and MIP
> BCEs are the same - for e.g., what if the
> de-registration reaches after the pBU? It is not
> within the charter to modify any MIP6 behaviors to
> define PMIP - so, we have to be careful about where
> this leads us.
>
> 4. A similar impact will be on the MIP6 behavior of
> the MN - the MN must send an unsolicited NA upon
> returning home, in accordance with RFC3775; but, the
> MN will not do this after a link change within the
> PMIP domain.
>
>
> 5. If the MN moves back and forth between two PMAs
> associated with different LMAs, the pBU and the BU
> at the LMA/HA may create race conditions. The
> sequence numbers are obviously not synchronized and
> 6. The security model of PMIP and MIP are vastly
> different. PMIP operates with a notable risk that in
> the event of a PMA compromise, it is feasible to
> redirect traffic belonging to any address within the
> PMIP domain. If the PMA is authorized to send BUs
> for the MN's MIP HoA, a compromised PMA can redirect
> traffic belonging to an MN even when the MN is no
> longer in that domain. In this case, PMIP is
> extending the threat to the scope of MIP6 and this
> is not acceptable.
>
> 7. The different security models also lead to IPsec
> processing differences. For MIP6, the SPD must be
> checked against the HoA of the MN. For PMIP6, the
> SPD must be checked against the PMA's IP address
> (which is often the pCoA or simply, the source
> address of the pBU). When a given IP address is both
> the MIP6 HoA and the PMIP6 pHoA, there is an issue
> with IPsec processing due to the differences in the
> two models. This would result in improper (or even
> lack of) authorization of the MIP6 BUs, resulting in
> an undesirable and unacceptable impact to MIP6
> security.
>
> For all the above reasons, I suggest explicitly
> disallowing the case of MIP6 HoA and PMIP6 pHoA
> being the same.

I don't think it makes sense to have a MIP6 HoA which 
is PMIP6 pHoA.

As I see it, the NetLMM fabric should hide L3 movements 
to *any* MN moving within the NetLMM domain, MIPv6 or 
non-MIPv6 enabled.

Therefore a MN that is in a NetLMM domain would get an 
address from that domain (I am proposing to call that 
a NetLMM Mobile Address -- NMoA). As long as the MN 
stays in the domain the NetLMM fabric will take care 
that this NMoA remains constant. When it leaves the 
domain it will acquire a new address valid at its new 
point of attachment.

Now if the MN in question is MIPv6 enabled, it can 
register with its Home Agent this NMoA as its CoA. As 
long as it remains in the NetLMM domain it won't need 
to change the HoA->CoA binding since NetLMM will take 
care that this CoA remains constant. When it leaves 
the domain, then it will change the HoA->CoA binding 
to point to the address it acquired at its new point 
of attachment.

Thoughts?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 2 Feb 2007 15:39:19 +0100

Folks,

In other words, what I tried to say below is that IMO:

- It doesn't make sense to have a MIP6 HoA which is 
  PMIP6 pHoA.

- It makes sense to have a MIP6 CoA which is PMIP6
  pHoA.

Hence I think the term pHoA is misleading and should be 
change to NMoA (NetLMM Care-of Address)

--julien

On Friday 02 February 2007 15:31, Julien Laganier 
wrote:
> 
> [...]
>
> I don't think it makes sense to have a MIP6 HoA
> which is PMIP6 pHoA.
>
> As I see it, the NetLMM fabric should hide L3
> movements to *any* MN moving within the NetLMM
> domain, MIPv6 or non-MIPv6 enabled.
>
> Therefore a MN that is in a NetLMM domain would get
> an address from that domain (I am proposing to call
> that a NetLMM Mobile Address -- NMoA). As long as
> the MN stays in the domain the NetLMM fabric will
> take care that this NMoA remains constant. When it
> leaves the domain it will acquire a new address
> valid at its new point of attachment.
>
> register with its Home Agent this NMoA as its CoA.
> As long as it remains in the NetLMM domain it won't
> need to change the HoA->CoA binding since NetLMM
> will take care that this CoA remains constant. When
> it leaves the domain, then it will change the
> HoA->CoA binding to point to the address it acquired
> at its new point of attachment.
>
> Thoughts?
>
> --julien

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 2 Feb 2007 16:07:39 +0100

Hi,

I think there are two options if session continuity beyond the PMIP
domain is desired (assumption is that PMIPv6 is used for localized MM
and MIPv6 for global MM, i.e., MIPv6-HoA is used by application):

1. PMIP-HoA must not equal MIPv6-HoA. Instead, PMIP-HoA is registered as
CoA at MIPv6-HA.
(MIPv6-HA and PMIPv6-HA are not necessarily co-located in this case)

2. PMIP-HoA may equal MIPv6-HoA. 
(MIPv6-HA and PMIPv6-HA must be co-located in this case.)

The unique advantage of option 2 is that no IP tunnel to the MN (i.e.,
over the air) is necessary (at least as long as the MN is moving within
the "home PMIP domain", i.e. the PMIP domain, which is anchored at the
co-located PMIPv6/MIPv6-HA). In option 1, there is always an IP tunnel
to the MN needed, assuming that the MIPv6 home link is virtual. IMHO,
this is a reason to support option 2.

Regards,

Kilian

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Freitag, 2. Februar 2007 15:39
> To: [email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 2 Feb 2007 11:12:14 -0800 (PST)

> this is a reason to support option 2.

Absolutely !

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 2 Feb 2007 11:45:14 -0800

Hi Julien,
I completely subscribe to this school of thought :) 

We have, however, several people on the list who seem to want to allow
the case of the MIP6 HoA being the same as the PMIP6 pHoA (also agree
that term is misleading). I would like to understand why they believe
that scenario is not problematic or why it is okay to impact the MIP6
operation. 

Vidya 

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Friday, February 02, 2007 6:39 AM
> To: [email-masked]
> Cc: Narayanan, Vidya
> > I don't think it makes sense to have a MIP6 HoA which is PMIP6 pHoA.
> >
> > As I see it, the NetLMM fabric should hide L3 movements to *any* MN 
> > moving within the NetLMM domain, MIPv6 or non-MIPv6 enabled.
> >
> > Therefore a MN that is in a NetLMM domain would get an address from 
> > that domain (I am proposing to call that a NetLMM Mobile Address -- 
> > NMoA). As long as the MN stays in the domain the NetLMM fabric will 
> > take care that this NMoA remains constant. When it leaves 
> the domain 
> > it will acquire a new address valid at its new point of attachment.
> >
> > Now if the MN in question is MIPv6 enabled, it can register 
> with its 
> > Home Agent this NMoA as its CoA.
> > As long as it remains in the NetLMM domain it won't need to 
> change the 
> > HoA->CoA binding since NetLMM will take care that this CoA remains 
> > constant. When it leaves the domain, then it will change the

---

From: "Hugo Santos" <[email-masked]>
Date: Fri, 2 Feb 2007 20:58:39 +0000

Hi,

> that scenario is not problematic or why it is okay to impact the MIP6

  If while in the "Home PMIP domain" the prefix advertised is the home
prefix it doesn't impact the MIP6 operation at all. The Mobile node
just assumes it is directly connected to the home domain and
de-registers from the HA. From this point on, the NETLMM fabric will
handle all of the mobility as Julien stated. When roaming to a
different PMIP domain, the Mobile Node will acquire a new CoA (a pHoA
from a new prefix from the new domain) and will register itself in
it's HA, thus allowing seamless mobility.

  Hugo

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 3 Feb 2007 00:46:40 -0600

Hi Julien,
 
> change 

[Ahmad]
I absolutely AGREE here that it is misleading and confusing too.

> to NMoA (NetLMM Care-of Address)
> 
> --julien
>

---

From: "Genadi Velev" <[email-masked]>
Date: Mon, 5 Feb 2007 16:41:39 +0100

Hi Julien, Vidya,

while I can follow the "school of thoughts" taught by Julien and
understand why the separation of MIP6 HoA and PMIP6 pHoA results in
simpler PMIPv6 protocol, we need to keep in mind goal #4 (Limit Overhead
in the Network) from draft-ietf-netlmm-nohost-req. In this I-D it is
written:  "...Therefore, any solutions for localized mobility management
should minimize overhead within the access network."

As it was already mentioned on the mailing list, having a separation of
MIP6 HoA and PMIP6 pHoA leads to IP-in-IP tunnel over the wireless link
for each MIPv6 enabled MN.  Thus, IMHO goal #4 is not fulfilled. My
opinion on this is to keep both options, i.e. separation of MIP6 HoA and
PMIP6 pHoA and both addresses being the same, valid and leave it up to
the network operator to decide which option to deploy. If there is a
"home" PMIP domain for a MN, why not allowing for this MN to feel like
at home and avoid MIPv6 tunneling over the air. Otherwise this MN would
never be at "home". Of course if the MN moves to a "foreign" PMIP
domain, it configures a new PMIP6 pHoA (used only for local MM within
the "foreign" PMIP domain) and registers it as CoA in the MIP6 HA.

Of course there is an impact on the design of the HA if MIP6 HoA and
PMIP6 pHoA are the same in the "home" PMIP domain, but as Vidya has
mentioned ""No changes to MIP6 HA" is NOT a goal of this design".  

regards,
Genadi

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Friday, February 02, 2007 8:45 PM
> To: Julien Laganier; [email-masked]
> Subject: RE: [netlmm] MIP6 HoA and PMIPv6 pHoA
> 
> Hi Julien,
> to *any* MN 
> address from

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 5 Feb 2007 10:25:57 -0800

Hi Genadi,
Thanks for the comments. Please see inline.  

> From: Genadi Velev [mailto:[email-masked]] 
> Sent: Monday, February 05, 2007 7:42 AM
> To: Narayanan, Vidya; Julien Laganier; [email-masked]
> while I can follow the "school of thoughts" taught by Julien 
> and understand why the separation of MIP6 HoA and PMIP6 pHoA 
> results in simpler PMIPv6 protocol, we need to keep in mind 
> goal #4 (Limit Overhead in the Network) from 
> draft-ietf-netlmm-nohost-req. In this I-D it is
> written:  "...Therefore, any solutions for localized mobility 
> management should minimize overhead within the access network."
> 
> MIP6 HoA and PMIP6 pHoA leads to IP-in-IP tunnel over the 
> wireless link for each MIPv6 enabled MN.  Thus, IMHO goal #4 
> is not fulfilled. 

Please note that the requirements document applies to the network-based
mobility protocol only, not for any combination of that with MIP6. 

>My opinion on this is to keep both options, 
> i.e. separation of MIP6 HoA and
> PMIP6 pHoA and both addresses being the same, valid and leave 
> it up to the network operator to decide which option to 
> deploy. If there is a "home" PMIP domain for a MN, why not 
> allowing for this MN to feel like at home and avoid MIPv6 
> tunneling over the air. Otherwise this MN would never be at 
> "home". Of course if the MN moves to a "foreign" PMIP domain, 
> it configures a new PMIP6 pHoA (used only for local MM within 
> PMIP6 pHoA are the same in the "home" PMIP domain, but as 
> Vidya has mentioned ""No changes to MIP6 HA" is NOT a goal of 
> this design".  
> 

Also, please note that the "no changes to MIP6 HA" being NOT a goal is
also for the PMIPv6 design. We are not chartered to make any changes to
MIP6 itself. 

Thanks,
Vidya

> > > From: julien laganier [mailto:[email-masked]] 
> On Behalf 
> > > Of Julien Laganier
> > > Hence I think the term pHoA is misleading and should be change to 
> > > NMoA (NetLMM Care-of Address)
> > > 
> > > --julien
> > >

---

From: "Genadi Velev" <[email-masked]>
Date: Tue, 6 Feb 2007 15:46:07 +0100

Hi Vidya,

please see my short comments inline...

> Sent: Monday, February 05, 2007 7:26 PM
> To: Genadi Velev; Julien Laganier; [email-masked]
 
I agree about the applicability of goal #4. However, if we have
MIP6-HoA!=PMIP6-HoA and MIP6-capable host, then we always have MIP
tunneling over the air. So, the goal #4 for NetLMM is fulfilled only in
case of plain IPv6 hosts (no MIP6 implemented). 

> also for the PMIPv6 design. We are not chartered to make any 

I also agree about the charter of the NetLMM WG. I was referring to
changes in the collocated MIP6+PMIP6-HA  that can support the MIP6-PMIP6
interaction while RFC3775-conform MN is kept unchanged. 
BTW, I'm unclear what could be the difference between collocated
MIP6+PMIP6-HA and single PMIP6-HA in the praxis... Any thoughts on this?
One of the main points of adopting PMIP as solution for NetLMM was the
deployment of modified MIP6-HA as LMA. 

Thank you for your notes,
Genadi