Subject: [netlmm] Re: Ticket #166: Host Multi-Homing

From: Christian Vogt <[email-masked]>
Date: Wed, 01 Aug 2007 10:29:43 +0300

Vidya:

>> - How can it be ensured that the mobile node configures the 
>> same HoA on each of its interfaces?
> 
> It is not just about how the MN configures the same address on each of
> its interface, is it?  The multiple interfaces that the MN has may be
> going to different MAGs associated with different LMAs, for instance.
> Also, it is a question of whether the MN wants to have those interfaces
> as multihomed at the IP level.

The issue with multiple interfaces going to different MAGs is I think
covered by my 2nd bullet below.  The issue with multiple LMAs should not
occur given that only 1 LMA can be responsible for a given MN identity.

Whether or not the MN want to have its interfaces multi-homed is a good
point.  There may also be a technical issue:  If the MN ends up with the
same IP (home) address on multiple interfaces, then how can the MN
select which interface outgoing packets are sent through?

>> - How can all of the MAGs that the mobile node attaches to 
>> simultaneously have a binding with the mobile node's LMA?
>
> Given that the base spec is not dealing with multiple bindings, support
> for this doesn't seem inline with the scope of the base spec. 
>
>> - To which interface of the mobile node should the LMA 
>> forward packets received for the mobile node?
> 
> This seems tied to whether the LMA has multiple bindings for the MN or
> not.  This doesn't seem applicable, given that there are no multiple
> bindings with the basic PMIPv6 protocol.

I guess the limitation to one LMA per MN plus the limitation to one
binding per LMA actually precludes host multi-homing.  This seems to
resolve the issue in the first place.

>> This issue was brought up by Hesham Soliman during the NETLMM 
>> session at IETF 69 in Chicago. See also:
>> http://www1.ietf.org/mail-archive/web/netlmm/current/msg02665.html
>>
> 
> I think Hesham had also raised the issue about having the same prefix as
> the MIP6 home prefix and a PMIP prefix for the MN on another interface.
> While in general, multihoming raises some issues with PMIP6, the
> situation seems to get even further complicated with the same
> address/prefix is being handled by MIP6 and PMIP6.

This additional issue comes into play when MIPv6 and P-MIPv6 are used in
a non-hierarchical manner (i.e., scenario C of Vijay's MIPv6/P-MIPv6
interaction presentation).  In this scenario, however, the LMA and the
HA must be co-located because the HoA prefix routes to both.  I
therefore think that the issue with pure P-MIPv6-based multi-homing is
conceptually the same as the issue with mixed MIPv6/P-MIPv6 multi-homing
-- whether or not you have a combined LMA/HA or a pure LMA is not really
that important.

>> There is consensus in the WG that host multi-homing should 
>> not be supported by the current P-MIPv6 specification. 
>> Whether or not host multi-homing should be explicitly 
>> forbidden in the specification is still an open question.
> 
> I'm not sure what it means to forbid something in an IETF document :) 

I was thinking of a "MUST NOT", justified by a brief statement of what
the consequences of P-MIPv6-based multi-homing would be.

- Christian

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 1 Aug 2007 11:41:21 -0700

Hi Christian, 

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 12:30 AM
> To: Narayanan, Vidya
> Cc: NetLMM Mailing List; Hesham Soliman; Soininen Jonne; Sri 
> Gundavelli
> Subject: Re: Ticket #166: Host Multi-Homing
> 
> Vidya:
> 
> >> - How can it be ensured that the mobile node configures 
> the same HoA 
> >> on each of its interfaces?
> > 
> > Also, it is a question of whether the MN wants to have those 
> > interfaces as multihomed at the IP level.
> 
> The issue with multiple interfaces going to different MAGs is 
> I think covered by my 2nd bullet below.  The issue with 
> multiple LMAs should not occur given that only 1 LMA can be 
> responsible for a given MN identity.
> 

Well, I guess it depends on how the MAG acquires the identity of the MN
and whether the different MAGs get the same identity for a given MN or
not.  But, I do agree that we should not attempt to solve that here. 

> Whether or not the MN want to have its interfaces multi-homed 
> is a good point.  There may also be a technical issue:  If 
> the MN ends up with the same IP (home) address on multiple 
> interfaces, then how can the MN select which interface 
> outgoing packets are sent through?
> 

Yes, this is among the issues it brings.  If the MN wants to use both
interfaces simultaneously, it needs to see those as different IP
interfaces with distinct addresses. 

> > Given that the base spec is not dealing with multiple bindings, 
> > support for this doesn't seem inline with the scope of the 
> base spec.
> >
> >> - To which interface of the mobile node should the LMA forward 
> >> packets received for the mobile node?
> > 
> I guess the limitation to one LMA per MN plus the limitation 
> to one binding per LMA actually precludes host multi-homing.  
> This seems to resolve the issue in the first place.
> 
> >> This issue was brought up by Hesham Soliman during the 
> NETLMM session 
> >> at IETF 69 in Chicago. See also:
> > I think Hesham had also raised the issue about having the 
> same prefix 
> > as the MIP6 home prefix and a PMIP prefix for the MN on 
> another interface.
> This additional issue comes into play when MIPv6 and P-MIPv6 
> are used in a non-hierarchical manner (i.e., scenario C of 
> Vijay's MIPv6/P-MIPv6 interaction presentation).  In this 
> scenario, however, the LMA and the HA must be co-located 
> because the HoA prefix routes to both.  I therefore think 
> that the issue with pure P-MIPv6-based multi-homing is 
> -- whether or not you have a combined LMA/HA or a pure LMA is 
> not really that important.
> 

Sure.  But, given that the MAG is signaling for one interface of the MN
and the MN is signaling for the other one itself, it could be worse.  I
am not sure if the LMA/HA collocated entity will accept both bindings or
not - depending on whether the binding cache is shared or not between
the PMIP6 and MIP6 sides, the behavior could be different. 

I think simply mentioning the issue and stating that such multihoming is
out of scope in the interactions document as well is sufficient for now.

> >> There is consensus in the WG that host multi-homing should not be 
> >> supported by the current P-MIPv6 specification.
> >> Whether or not host multi-homing should be explicitly forbidden in 
> >> the specification is still an open question.
> > 
> I was thinking of a "MUST NOT", justified by a brief 
> statement of what the consequences of P-MIPv6-based 
> multi-homing would be.
> 

That works for me. 

Thanks,
Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Aug 2007 15:34:07 -0700

I am no longer sure what issue we are discussing here. It is not even 
clear if we are talking about the base PMIPv6 spec or the scenario C in 
the PMIPv6-MIPv6 interactions document.

Multi-homing is obviously out of scope for the base specification.

> address/prefix is being handled by MIP6 and PMIP6. 

Think of a regular RFC 3775 Mobile Node. When it is attached to the home 
link, is the home address assigned to the physical interface with which 
the mobile node is attached to the home link or to the Mobile IP virtual 
adapter? Both? When it moves away from the home link, the home address 
is only assigned to the virtual Mobile IP adapter. The physical 
interface is now assigned a CoA. The behavior is implementation specific.

In Scenario C, when the MN is not attached to its home link, it can 
either be attached to another PMIPv6 domain or to an access router where 
there is no PMIPv6 support. In this case, there is either a new PMIPv6 
MN-HoA or a CoA. We are mixing up things quite a bit here.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Aug 2007 15:35:12 -0700

> the consequences of P-MIPv6-based multi-homing would be.

This does not make sense. IMO, the only statement we should add to the 
base PMIPv6 spec is that multi-homing is out of scope.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Aug 2007 15:38:57 -0700

> the PMIP6 and MIP6 sides, the behavior could be different. 

The MAG sending a proxy BU on behalf of the mobile node when the mobile 
node is not attached to it is considered an error condition in the base 
PMIPv6 spec. See section 6.12 of 
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-01.txt

The PMIPv6 - MIPv6 issues I was presenting at the meeting involved some 
corner cases where the proxy BU that the MAG sent when the MN is 
attached to it was delayed and received after the BU from the MN. We 
were trying to figure out if this is an issue that needs solution.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 1 Aug 2007 20:29:20 -0700

Thanks Vijay, I agree. Just a step back on this highly
discussed topic. Just to clarify, from the perspective
of the Proxy Mobile IPv6 base specification and not
in the context of the CMIP.MIP6 interactions document:

- We are stating we are not supporting this scenario.

- We the authors prefer not to investigate or document this
  issue in detail, other than having some minimal text. We
  do not think, we should have explicit text ruling this
  out. We can at the most say, the host needs to be modified
  to handle such configuration and that the LMA needs to 
  support multiple bindings for each MN.

- Its an advanced scenario, falls in the scope of
  "evolutionary" category and we believe this is a logical 
  extension to the base work and can be extended in future.
  For reasons of lack of time, we believe we will not be
  able to support this scenario with in the current timelines.

Hope this conclusion is ok with every one.

PS: I will be offline for two days.

Sri

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 3:34 PM
> To: Narayanan, Vidya
> Cc: Hesham Soliman; Christian Vogt; NetLMM Mailing List
> Subject: Re: [netlmm] RE: Ticket #166: Host Multi-Homing
> 
> same prefix as

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 01 Aug 2007 23:58:09 -0400

Sri, I agree with most of your explanation from the perspective of the 
Proxy Mobile IPv6. It is probably a good idea to add few text that you 
have described below with respect to multi-homed scenario and leave the 
real solution for the evolutionary category to explored later.

	We will need to deal with this specific scenario at some point, as 
sooner or later, carriers will begin to deploy PMIP with multi-homed 
mobile that could involve movement between access networks of different 
types (e.g., 802.11, WiMAX, or CDMA).

Thanks
Ashutosh

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 2 Aug 2007 09:32:03 -0700

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 3:35 PM
> To: Christian Vogt
> Cc: Narayanan, Vidya; Hesham Soliman; NetLMM Mailing List
> Subject: Re: [netlmm] Re: Ticket #166: Host Multi-Homing
> 
> Christian Vogt wrote:
> statement of what 
> This does not make sense. IMO, the only statement we should 
> add to the base PMIPv6 spec is that multi-homing is out of scope.
> 

I understood Christian's suggestion to mean that multi-homing is out of
scope and that in accordance with the base specification, the same IP
prefix/address MUST NOT be assigned to multiple interfaces of a given MN
- i.e., MAGs and LMAs must not be assigning a prefix/address to multiple
devices/interfaces at the same time. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 2 Aug 2007 09:35:02 -0700

> Sent: Wednesday, August 01, 2007 3:39 PM
> To: Narayanan, Vidya
> Cc: Christian Vogt; Hesham Soliman; NetLMM Mailing List
> > Sure.  But, given that the MAG is signaling for one 
> interface of the 
> > MN and the MN is signaling for the other one itself, it could be 
> > worse.  I am not sure if the LMA/HA collocated entity will 
> accept both 
> > bindings or not - depending on whether the binding cache is 
> shared or 
> > not between the PMIP6 and MIP6 sides, the behavior could be 
> different.
> 
> The MAG sending a proxy BU on behalf of the mobile node when 
> the mobile node is not attached to it is considered an error 
> condition in the base

I'm talking about the case where the MN is attached to the MAG using one
of its interfaces.  Consider this a multi-homed MN that has one
interface attached to its MIP6 home link (served by PMIP6, in Scenario
C) and another link being away from home (in the MIP6 perspective).  

We don't need to explore this now - it is a multihomed scenario and
that's out of scope for now anyway. 

Vidya

> The PMIPv6 - MIPv6 issues I was presenting at the meeting 
> involved some corner cases where the proxy BU that the MAG 
> sent when the MN is attached to it was delayed and received 
> after the BU from the MN. We were trying to figure out if 
> this is an issue that needs solution.
> 
> Vijay
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 02 Aug 2007 09:46:44 -0700

Narayanan, Vidya wrote:
> scope and that in accordance with the base specification, 

Yes.

> the same IP

Multiple devices?

If multi-homing is out of scope, how does the above sentence makes sense?

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 2 Aug 2007 09:54:13 -0700

> 
> > the same IP
> > prefix/address MUST NOT be assigned to multiple interfaces 
> of a given 
> > MN
> > - i.e., MAGs and LMAs must not be assigning a prefix/address to 
> > multiple devices/interfaces at the same time.
> 
> Multiple devices?
> 

Just saying multihoming is out of scope, without providing normative
behavior for the MAG/LMA to avoid leading to multihoming issues doesn't
make sense to me.  Multihoming is out of scope is a separate statement.
We then need to specify what the MAG/LMA needs to do to avoid issues in
regular IP nodes.  That is what the above is trying to capture. 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 02 Aug 2007 09:59:57 -0700

Narayanan, Vidya wrote:
> regular IP nodes.  

What is the problem with "regular IP nodes", if we assume multi-homed 
nodes are out of scope?

Vijay

That is what the above is trying to capture.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 2 Aug 2007 10:08:06 -0700

> Sent: Thursday, August 02, 2007 10:00 AM
> To: Narayanan, Vidya
> > behavior for the MAG/LMA to avoid leading to multihoming issues 
> > doesn't make sense to me.  Multihoming is out of scope is a 
> separate statement.
> > We then need to specify what the MAG/LMA needs to do to 
> avoid issues 
> > in regular IP nodes.
> 
> What is the problem with "regular IP nodes", if we assume 
> multi-homed nodes are out of scope?
> 

Multihoming is out of scope for NETLMM; we are not prohibiting regular
IP nodes from being multihomed.  Hence, when such nodes have multiple
interfaes attached to PMIP-enabled networks, the PMIP devices need to
know not to assign the same address to those interfaces so that the MN,
being a regular IP node unaware of PMIP, doesn't have the issue of
multiple interfaces ending up with the same IP address. 

Vidya

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 02 Aug 2007 13:10:44 -0400

By saying "multi-homed nodes are out of scope" we are not trying to 
solve the problem that a carrier might face in future. We may not 
include this in the current spec and can probably defer this problem to 
a later spec. It has also the implication on how LMA and MAG can/should 
behave as pointed out rightly.

Thanks
Ashutosh

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 02 Aug 2007 12:34:36 -0500

> multiple interfaces ending up with the same IP address.

I agree that we need some clarification of how to handle a multi-interface
host which may be multihomed only from the perspective of ensuring that the
same address does not get assigned to the interfaces. We need to ensure that
the MAGs and LMA entities to which the MN is attached to, via its
interfaces, are aware of the assignment of an address to the MN.
We don't need to provide a solution for this scenario in the base protocol
but merely mention it to ensure that the MN behaves correctly.

-Raj

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 03 Aug 2007 12:27:53 +0200

I see the importance of multihomed nodes and inter-tech handover
(which should be distinguished, by the way), but I think we
do not need a statement in the base spec that sais 'this is out
of scope', as it's not relevant for basic PMIPv6 operation.
These are enhanced scenarios, which of course require
some support from LMAs. Or does the spec also indicate that fast handover,
route optimization and support for mobile routers is out of scope?
Well, the charter sais. We could consider these enhanced scenarios
in scope of a possible re-charter. But we should keep the base spec as
base spec without mentioning what's not supported.

marco

Ashutosh Dutta wrote:
> include this in the current spec and can probably defer this problem
> to a later spec. It has also the implication on how LMA and MAG
> can/should behave as pointed out rightly.
>
> Thanks
> Ashutosh
>
>
> Vijay Devarapalli wrote:
>> Narayanan, Vidya wrote:
>>>>> the same IP

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 3 Aug 2007 20:47:39 -0700 (PDT)

Hi Marco,

> route optimization and support for mobile routers is out of scope?

Agreed. This is a good comment. We are not supporting many other
features in the base document and we dont about them. At the most,
we can state, this document does not asupport that configuration.
But, trying to detect that scenario and MAG ensuring the address
configuration is delivered only one of the interfaces attached to
the mobile node may be bit extreme. So, we prefer to stay silent
or just state this scenario is not supported, affectively, "here
is the gun and here is the bullet, and there is your feet".

Further, this protocol is applied in  managed networks and so
attempting to detect this error case, may not be required, IMO.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 3 Aug 2007 21:50:19 -0700 (PDT)

Hi Ashutosh,

On Wed, 1 Aug 2007, Ashutosh Dutta wrote:

> Sri, I agree with most of your explanation from the perspective of the Proxy 
> Mobile IPv6. It is probably a good idea to add few text that you have 
> described below with respect to multi-homed scenario and leave the real 
> solution for the evolutionary category to explored later.
>

Sure. We will state its not supported. But, we will not
go into the details of detecting that error scenario and
try correcting it.

> soXoner or later, carriers will begin to deploy PMIP with multi-homed 
mobile 
> that could involve movement between access networks of different types (e.g., 
> 802.11, WiMAX, or CDMA).
>

Absolutely.

Sri

---

From: Christian Vogt <[email-masked]>
Date: Mon, 06 Aug 2007 15:38:05 +0300

>> some support from LMAs. Or does the spec also indicate that fast
>> handover, route optimization and support for mobile routers is
>> out of scope?
> 
> features in the base document and we dont about them. [...]

Sri, Marco,

there is a difference between features that would be nice to have, but
are currently not supported, and deployment options that may actually be
supported, but would break things.

Fast handovers, context transfer, etc. belong to the former category.
We have to make sure host multi-homing does not belong to the latter.

However, fortunately, the technical details of P-MIPv6 are such that
host multi-homing with a single HoA is impossible:  An LMA removes an
old binding whenever it receives a request for a new binding.  So the
issues with multiple interfaces having the same HoA really cannot occur
unless the base spec is violated.

Still, the design decision of why host multi-homing with a single HoA is
not supported should be stated and justified in the base spec IMO.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 06 Aug 2007 15:41:08 +0300

> devices/interfaces at the same time. 

Yep, thanks.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 06 Aug 2007 16:01:05 +0300

> - We are stating we are not supporting this scenario.

Sri and all,

FYI: I noted this in the issues tracker, settling this issue for now.

- Christian

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 06 Aug 2007 15:28:05 +0200

Hi Christian,

> supported, but would break things.
Agreed.
> unless the base spec is violated.
That depends on the nature of the MNID and how the MNID is mapped to
the HNP. If the MNID is the same for both interfaces, then there
is no conflict. If the MNID(s) distinguish interfaces (e.g. using
the MAC address), mapping of such MNID to the same HNP should be
avoided. This is beyond what the base spec describes, as the HNP
assignment is out of scope. So, maybe the spec should cover a note,
that resolving different MNIDs to the same HNP is not allowed.
That's maybe more useful than just stating 'host multi-homing
not supported'.

marco

---

From: Christian Vogt <[email-masked]>
Date: Mon, 06 Aug 2007 16:45:25 +0300

> That's maybe more useful than just stating 'host multi-homing

Good point.  I agree.

- Christian

---

From: Julien Laganier <[email-masked]>
Date: Mon, 6 Aug 2007 15:54:59 +0200

Hi Christian,

On Monday 06 August 2007, Christian Vogt wrote:
> 
> [...]
>
> However, fortunately, the technical details of
> P-MIPv6 are such that host multi-homing with a
> single HoA is impossible:  An LMA removes an old
> binding whenever it receives a request for a new
> binding.  So the issues with multiple interfaces
> having the same HoA really cannot occur unless the
> base spec is violated.

The behavior you're describing occurs in the NETLMM 
fabric, not on the MN which is an unmodified host. So 
while I agree with you that with the current 
spec "[an] LMA removes an old binding whenever it 
receives a request for a new binding", that is 
orthogonal to the behavior of the MN. 

While we'd like the MN to unconfigure the HoA from the 
interface which created the old binding and configure 
the HoA on the interface which creates the new binding 
(and update local routing accordingly), that is not 
what will happen with an unmodified host since it has 
no clue about what's going on in the NETLMM fabric. 

What will happen is: when the old binding is removed, 
an unmodified host will have no way to know that the 
old NETLMM binding was removed and will keep its HoA 
configured on the interface that created that old 
binding. When the new binding will be created, the MAG 
will try to trigger the unmodified host to configure 
the same HoA on its other interface (through e.g. 
DHCP) and that will either 1) fail since the HoA is 
already configured on the former interface, or 2) 
succeed and result in two interfaces with the same 
address, a confused MN routing table, and a multi-link 
subnet.

> Still, the design decision of why host multi-homing
> with a single HoA is not supported should be stated
> and justified in the base spec IMO.

I think that we should simply state:

"The NETLMM protocol defined in this document has been 
designed for MN who have only one interface attached 
to a given NETLMM domain. Support for multihomed MN 
with more than one interface attached to a given 
NETLMM domain is not supported by this protocol and 
out of scope of this document."

...and avoid use of MUST / MUST NOT words.

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 06 Aug 2007 07:40:00 -0700

> ...and avoid use of MUST / MUST NOT words.

I would re-word as

"Support for a mobile node with more than one interface attached to
a given NETLMM domain is out of scope and is not addressed in this
document."

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Mon, 6 Aug 2007 16:43:28 +0200

On Monday 06 August 2007, you wrote:
> > "The NETLMM protocol defined in this document has
> > been designed for MN who have only one interface
> > attached to a given NETLMM domain. Support for
> > multihomed MN with more than one interface
> > attached to a given NETLMM domain is not supported
> > by this protocol and out of scope of this
> > document."
> >
> "Support for a mobile node with more than one
> interface attached to a given NETLMM domain is out
> of scope and is not addressed in this document."

Fine with me.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Aug 2007 23:06:47 -0700 (PDT)

Hi Christian,

> unless the base spec is violated.

True. With out supporting multiple bindings on the LMA, the support
for multi-homing will not be there. As you pointed out, the LMA will
keep replacing the binding from one MAG with the other. So, this will
be the undesirable affect for the mobile node when multi-homing
is enabled and by violating the base spec.

So, we will resolve this issue by stating that this scenario is not
supported and by adopting the text proposed by Julien and with the
changes from Vijay.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Aug 2007 23:13:14 -0700 (PDT)

Hi Marco,

Hi Marco,

There is a 1:1 relation between a mobile node and its identifier.
That is the implicit assumption. Now, for any reasons if the
identifiers are different across interfaces, the protocol does
not keep a relation between those identifiers and will allocate
different home network prefixes for different identifiers. So,
the current issues will not be valid in such scenario.

But, I did not think, operators will allocate different identifiers
for different access technologies and expect seamless mobility
across those interfaces.

If need be, we can state this assumption explicitly.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 6 Aug 2007 23:54:40 -0700 (PDT)

This issue was discussed with Julien on quite a few threads.

The issue is related to establishing the link-local address
uniqueness on the access link and when DNAv6 is enabled on
the mobile node.

Even though the odds are extremly low, 1:billion, the possibility
of a link-local address collision on a point-to-point link and
between the MAG and the MN. But, for the sake of completeness
we need to do some thing here. There is higher probability for
the network going down due to million other reasons as supposed
to due to link-local address collision on a p2p link.

Also, IMO, this is primarily due to the missing semantics in 2461
for an access router to force a node to do DAD operation on
demand. DAD is designed with the fixed view of the network. A
node joining a LAN will do a DAD and enter the game and after
that only the new nodes joining that link will do the DAD operation.
NETLMM modifies this view slightly. A mobile node in the NETLMM domain
always thinks its still on the same link, but, it has a new
neighbor after each handoff. Interstingly, DNAv6 makes it worse by
supressing the DAD operation after a link up/down event.

Proposed Solutions:

1. Configure the DNAv6 Configuration Parameter

One of the workarounds for this issue is to set the DNAv6
configuration parameter, DNASameLinkDADFlag to TRUE and that will
force the mobile node to redo DAD operation every time the interface
comes up, even when DNAv6 stack on the mobile node does not detect a
link change .

2. Upload the link-local address of the mobile node to the
mobile node's policy profile.

3. Establish domain-wide link-local address uniqueness.

4. MAG should always do a DAD when ever it detects a new mobile
node on its access link.

IMO, option#3 is out of question. Please comment.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Tue, 7 Aug 2007 10:15:08 +0200

Hi Sri, 

Thanks for summarizing the issue. I support solution 2 
(see my comments on the proposed solutions inlined 
below).

> One of the workarounds for this issue is to set the
> DNAv6 configuration parameter, DNASameLinkDADFlag to
> TRUE and that will force the mobile node to redo DAD
> operation every time the interface comes up, even
> when DNAv6 stack on the mobile node does not detect
> a link change .

If the MN is forced to redo DAD after each handover, 
this will severely impact the handover performance of 
NETLMM since upon each handover a MN will have to wait 
for DAD completion before transitioning its address 
from tentative to assigned state. With the default DAD 
parameters (i.e. DupAddrDetectTransmits is 1 and 
RetransTimer is RETRANS_TIMER = 1000 milliseconds) 
that means that the MN will not be able to communicate 
for 1 second. 

I thought that the bad effects of DAD could be 
alleviated by having the router (MAG) overriding the 
default value of RetransTimer with a lower value. 

This is however not possible since RFC2462 says that 
1) "in some link-layer environments, particularly with 
MLD-snooping switches, no multicast reception will be 
available until the MLD report is sent", and 2) "a 
node SHOULD delay joining the solicited-node multicast 
address by a random delay between 0 and 
MAX_RTR_SOLICITATION_DELAY". There is hence a 
possibility that the MN doesn't not receive multicast 
traffic sent to the solicited-node address and thus 
can't detect a duplicate address. Therefore, it 
doesn't seem safe to reduce RetransTimer to less than 
MAX_RTR_SOLICITATION_DELAY (1 second) if we want to 
keep DAD robust.

> 2. Upload the link-local address of the mobile node
> to the mobile node's policy profile.

This is what I've been suggesting and I think that's 
the best solution out of the four listed in your note.

> 3. Establish domain-wide link-local address

We discussed that many time and concluded that it is 
problematic when multiple LMAs are used in a single 
NetLMM domain.

> 4. MAG should always do a DAD when ever it detects a
> new mobile node on its access link.

This has the same issue as 1. above since it means that 
the MAG won't be able to communicate before DAD 
completes after each handover, i.e. 1 second service 
interruption.

Thus I support option 2.

--julien

On Tuesday 07 August 2007, Sri Gundavelli wrote:
> The issue is related to establishing the link-local
> address uniqueness on the access link and when DNAv6
> is enabled on the mobile node.
>
> Even though the odds are extremly low, 1:billion,
> the possibility of a link-local address collision on
> a point-to-point link and between the MAG and the
> MN. But, for the sake of completeness we need to do
> some thing here. There is higher probability for the
> network going down due to million other reasons as
> supposed to due to link-local address collision on a
> p2p link.
>
> Also, IMO, this is primarily due to the missing
> semantics in 2461 for an access router to force a
> node to do DAD operation on demand. DAD is designed
> with the fixed view of the network. A node joining a
> LAN will do a DAD and enter the game and after that
> only the new nodes joining that link will do the DAD
> operation. NETLMM modifies this view slightly. A
> mobile node in the NETLMM domain always thinks its
> still on the same link, but, it has a new neighbor
> after each handoff. Interstingly, DNAv6 makes it
> worse by supressing the DAD operation after a link
> up/down event.
>
>
> Proposed Solutions:
>
> One of the workarounds for this issue is to set the
> DNAv6 configuration parameter, DNASameLinkDADFlag to
> TRUE and that will force the mobile node to redo DAD
> operation every time the interface comes up, even
> when DNAv6 stack on the mobile node does not detect
> a link change .
>
>
> 2. Upload the link-local address of the mobile node
> to the mobile node's policy profile.
>
>
> 4. MAG should always do a DAD when ever it detects a
> new mobile node on its access link.
>
>

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 07 Aug 2007 10:19:15 +0200

Hi Sri,

> the current issues will not be valid in such scenario.
I think there are two implicit assumptions, on the MNID and on
the resolution of the MNID to an HNP. The assumption on the
MNID is ok, but then the Term section should not indicate, that
the MNID can be "... or any other type of identifier which may
be specific to the access technology".

The assumption on how to resolve the MNID to an HNP is really
implicit. If this is clear enough, good.

> If need be, we can state this assumption explicitly.
I am fine with what you proposed in the reply to Christian and
to take over Julien's and Vijay's text.

thanks,
marco

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 7 Aug 2007 06:44:20 -0700

The text suggestions below still only capture that multihoming support
is out of scope.  Leaving the text just at this level suggests one of
the following two things: 

A. That deployments need to ensure that all MAGs in a given PMIP domain
are only serving the same access technology (and this further assumes
that MNs don't have multiple interfaces on the same technology at the
same time - having multiple Ethernet or WLAN interfaces on a node is not
all that uncommon and it is hard to predict in future which other access
technology may fall in that category. 

(or)

B. That deployments are always managed networks and such managed
networks restrict the MNs to never have more than one interface active
at a given time. 

The issue we are facing here is that we assume no impact to regular IP
nodes - in other words, regular IP nodes can connect as they usually do
and NETLMM will just hide IP address changes from the node.  If that
really needs to be true, we have to be clearer about the behavior of
MAGs and LMAs on features that have the potential to break or impact
behavior of regular IP nodes.  This is really one of those features
where we need to do a better job describing what will avoid such impact
to MNs. 

Vidya

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Monday, August 06, 2007 7:43 AM
> To: Vijay Devarapalli
> Cc: [email-masked]
> designed for 
> > > MN who have only one interface attached to a given NETLMM domain. 
> > > Support for multihomed MN with more than one interface 
> attached to a 
> > > given NETLMM domain is not supported by this protocol and out of 
> > > scope of this document."
> > >
> > "Support for a mobile node with more than one interface 
> attached to a 
> > given NETLMM domain is out of scope and is not addressed in this 
> > document."
> 
> Fine with me.
> 
> --julien
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 7 Aug 2007 23:50:29 +1000

I can't agree more. Sweeping this under the carpet is not going to wash with
people that think about using PMIP. 

Hesham 

 > From: Narayanan, Vidya [mailto:[email-masked]] 
 > Sent: Tuesday, August 07, 2007 11:44 PM
 > To: Julien Laganier; Vijay Devarapalli
 > Cc: [email-masked]
 > Subject: RE: [netlmm] Re: Ticket #166: Host Multi-Homing
 > 
 >

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 07 Aug 2007 08:33:37 -0700

Vidya,

We either analyze this completely, and figure out the MAG and LMA 
behavior and the client requirements (if any) or stay away from it 
completely in the base spec. Doing something half-baked with some
assumptions causes more harm. It only serves some folks agenda to 
prohibit some scenario elsewhere. :)

So I am open to discussing this more in detail if you want.

> networks restrict the MNs to never have more than one interface active

Neither. It means we haven't analyzed anything in this space in the 
PMIPv6 base document.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 7 Aug 2007 09:28:15 -0700

Vijay,

> Sent: Tuesday, August 07, 2007 8:34 AM
> To: Narayanan, Vidya
> Cc: Julien Laganier; [email-masked]
> We either analyze this completely, and figure out the MAG and 
> LMA behavior and the client requirements (if any) 

We're not entitled to imposing any client requirements in the scope of
our current charter. 

>or stay 
> away from it completely in the base spec. Doing something 
> half-baked with some assumptions causes more harm. It only 
> serves some folks agenda to prohibit some scenario elsewhere. :)
> 
> > A. That deployments need to ensure that all MAGs in a given PMIP 
> > domain are only serving the same access technology (and 
> this further 
> > assumes that MNs don't have multiple interfaces on the same 
> technology 
> > at the same time - having multiple Ethernet or WLAN interfaces on a 
> > node is not all that uncommon and it is hard to predict in future 
> > which other access technology may fall in that category.
> > 
> > (or)
> > 

I believe we are closing our eyes to the problem here.  The problem
doesn't go away by simply shutting our eyes to it.  This protocol has
the responsibility to ensure that it does not affect normal behavior of
IP nodes.  And, being multihomed is regular IP behavior.  We cannot
claim that nothing needs to be done and that regular IP node behavior is
not impacted.  

Vidya

> > nodes - in other words, regular IP nodes can connect as 
> they usually 
> > do and NETLMM will just hide IP address changes from the node.  If 
> > that really needs to be true, we have to be clearer about 
> the behavior 
> > of MAGs and LMAs on features that have the potential to break or 
> > impact behavior of regular IP nodes.  This is really one of those 
> > features where we need to do a better job describing what 
> will avoid 
> > such impact to MNs.
> > 
> > Vidya
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 07 Aug 2007 09:33:48 -0700

> We're not entitled to imposing any client requirements in the scope of

I said "if any", you are assuming you need new behavior on the client 
and running away with "MUST NOT" statements built on it.

> claim that nothing needs to be done and that regular IP node behavior is

As I said, we need to discuss the scenario in more detail. It is not 
just multihoming, but also PMIPv6 for inter-access technology handovers 
that is involved here. We have assumed that also to be out of scope.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 7 Aug 2007 09:46:39 -0700

<snip>

> >> behavior and the client requirements (if any)
> > 

No, I just want to ensure that we are not placing requirements or
restrictions on the client. 

>and running away with "MUST NOT" statements built on it.

I'm not saying any text proposed thus far is really the right thing.
I'm saying that simply stating it is out of scope is insufficient. 

<snip> 

> 
> As I said, we need to discuss the scenario in more detail. 

Yes, and if this is needed, it needs to be done on this topic.  

>It 
> is not just multihoming, but also PMIPv6 for inter-access 
> technology handovers that is involved here. We have assumed 
> that also to be out of scope.
> 

I'm not sure.  It is a matter of how many "IP" interfaces of the MN are
actively connected to the same PMIP domain at the same time. Again, we
need to iron this out and write the necessary text.  We have determined
that we are not solving multihoming now - we do need to determine the
correct text that will ensure regular IP behavior is not impacted. 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 07 Aug 2007 14:06:36 -0700

> mobile node's policy profile.

How about storing it on the LMA? When the MN enters a PMIPv6 domain, the 
  MN performs DAD and the MAG informs the LMA of the link local address 
of the MN. The others MAGs in the PMIPv6 domain get the link local 
address of the MN from the LMA. No need to involve the "policy store".

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 7 Aug 2007 18:12:48 -0700

Hi Julien,

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Tuesday, August 07, 2007 1:15 AM
> To: [email-masked]
> Cc: Sri Gundavelli
> Subject: Re: [netlmm] Issue: Link-local address collision on 
> the access link
> 
> Hi Sri, 
> 

Thanks for adding the explanation for each case.

I'm trying to see, if we can optimize on option#4, based
on ODAD [RFC-4429], it removes the RetransTimer delay.
Also, its a p2p link, if the MN sends any message using a
link-local address, the MAG just needs to detect the
collision and configure a different link-local address and
start using it. This issue is also not applicable when
PPP is in use, as the identifiers are negotiated at the
link setup.

Also, relating this to 3775, when the MN moves to a new
AR, it must do a DAD on the link-local address. So, the
DAD latency and the issue is pretty much the same.

We can certainly update the policy store. Since, the
probability of collision is so low, thinking, how we can
avoid any network messaging for this. 

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 7 Aug 2007 18:29:22 -0700

Hi Marco, 

> From: Marco Liebsch [mailto:[email-masked]] 
> Sent: Tuesday, August 07, 2007 1:19 AM
> To: Sri Gundavelli

I think, this is a good point. We will word it differently. 

> to take over Julien's and Vijay's text.

Ok. Thanks

Sri

---

From: "John.zhao" <[email-masked]>
Date: Wed, 08 Aug 2007 10:31:32 +0800

Hi,Sri

	Sorry for lating to join this discussion.
	I want to make sure what do you means in method 3? How to Establish
domain-wide link-local address uniqueness?
	From the perspective of a MN,we can also let the MN didn't find the
AR has been changed and then it will didn't do DAD.

	Best Rgds,
Thanks,

John.zhao
Huawei Technologies Co.,LTD

-----邮件原件-----
发件人: Sri Gundavelli [mailto:[email-masked]] 
发送时间: 2007年8月8日 9:13
收件人: 'Julien Laganier'; [email-masked]
主题: RE: [netlmm] Issue: Link-local address collision on the access link

Hi Julien,

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 7 Aug 2007 22:55:17 -0700

Option 2 seems incompatible with RFC3041-style privacy extensions.  What
would be the purpose of recording the MN's IID?  What happens if the MN
changed its IID later, for privacy reasons? 

Vidya

> Thanks for summarizing the issue. I support solution 2 (see 
> my comments on the proposed solutions inlined below).
> 
> > Proposed Solutions:
> >
> > DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that 
> > will force the mobile node to redo DAD operation every time the 
> > interface comes up, even when DNAv6 stack on the mobile 
> node does not 
> > detect a link change .
> 
> If the MN is forced to redo DAD after each handover, this 
> will severely impact the handover performance of NETLMM since 
> upon each handover a MN will have to wait for DAD completion 
> before transitioning its address from tentative to assigned 
> state. With the default DAD parameters (i.e. 
> DupAddrDetectTransmits is 1 and RetransTimer is RETRANS_TIMER 
> = 1000 milliseconds) that means that the MN will not be able 
> to communicate for 1 second. 
> 
> I thought that the bad effects of DAD could be alleviated by 
> having the router (MAG) overriding the default value of 
> RetransTimer with a lower value. 
> 
> available until the MLD report is sent", and 2) "a node 
> SHOULD delay joining the solicited-node multicast address by 
> a random delay between 0 and MAX_RTR_SOLICITATION_DELAY". 
> There is hence a possibility that the MN doesn't not receive 
> multicast traffic sent to the solicited-node address and thus 
> can't detect a duplicate address. Therefore, it doesn't seem 
> safe to reduce RetransTimer to less than 
> MAX_RTR_SOLICITATION_DELAY (1 second) if we want to keep DAD robust.
> 
> > 2. Upload the link-local address of the mobile node to the mobile 
> > node's policy profile.
> 
> This is what I've been suggesting and I think that's the best 
> solution out of the four listed in your note.
> 
> problematic when multiple LMAs are used in a single NetLMM domain.
> 
> > 4. MAG should always do a DAD when ever it detects a new 
> mobile node 
> > on its access link.
> 
> This has the same issue as 1. above since it means that the 
> MAG won't be able to communicate before DAD completes after 
> each handover, i.e. 1 second service interruption.
> 
> Thus I support option 2.
> 
> --julien
> 
> uniqueness 
> > on the access link and when DNAv6 is enabled on the mobile node.
> >
> > Even though the odds are extremly low, 1:billion, the 
> possibility of a 
> > link-local address collision on a point-to-point link and 
> between the 
> > MAG and the MN. But, for the sake of completeness we need 
> to do some 
> > thing here. There is higher probability for the network 
> going down due 
> > to million other reasons as supposed to due to link-local address 
> > collision on a p2p link.
> >
> > Also, IMO, this is primarily due to the missing semantics 
> in 2461 for 
> > an access router to force a node to do DAD operation on 
> demand. DAD is 
> > designed with the fixed view of the network. A node joining 
> a LAN will 
> > do a DAD and enter the game and after that only the new 
> nodes joining 
> > that link will do the DAD operation. NETLMM modifies this view 
> > slightly. A mobile node in the NETLMM domain always thinks 
> its still 
> > on the same link, but, it has a new neighbor after each handoff. 
> > Interstingly, DNAv6 makes it worse by supressing the DAD operation 
> > after a link up/down event.
> >
> >
> > Proposed Solutions:
> >
> > DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that 
> > will force the mobile node to redo DAD operation every time the 
> > interface comes up, even when DNAv6 stack on the mobile 
> node does not 
> > detect a link change .
> >
> >
> > 2. Upload the link-local address of the mobile node to the mobile 
> > node's policy profile.
> >
> >

---

From: Christian Vogt <[email-masked]>
Date: Wed, 08 Aug 2007 09:52:15 +0300

Julien:

> binding. 

Right.  What we need to avoid this is the same mechanism through which a
MAG withdraws a home prefix after a binding was rejected by the LMA.

Withdrawing the home prefix on the old link should make the mobile node
unconfigure the home address on the old interface.

As mentioned by Suresh during the NETLMM session in Chicago, it may not
be sufficient to simply set the home prefix lifetime to zero in Router
Advertisement messages.  The mobile node may in such a case simply
ignore the sudden lifetime change for DoS protection.

- Christian

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 09:35:37 +0200

On Wednesday 08 August 2007, Sri Gundavelli wrote:
> > From: julien laganier
> > Thanks for summarizing the issue. I support
> > solution 2 (see my comments on the proposed
> > solutions inlined below).
> >
> > > Proposed Solutions:
> > >
> > > One of the workarounds for this issue is to set
> > > the DNAv6 configuration parameter,
> > > DNASameLinkDADFlag to TRUE and that will force
> > > the mobile node to redo DAD operation every time
> > > the interface comes up, even when DNAv6 stack on
> > > the mobile node does not detect a link change .
> >
> > If the MN is forced to redo DAD after each
> > handover, this will severely impact the handover
> > performance of NETLMM since upon each handover a
> > MN will have to wait for DAD completion before
> > transitioning its address from tentative to
> > assigned state. With the default DAD parameters
> > (i.e. DupAddrDetectTransmits is 1 and RetransTimer
> > is RETRANS_TIMER = 1000 milliseconds) that means
> > that the MN will not be able to communicate for 1
> > second.
> >
> > alleviated by having the router (MAG) overriding
> > the default value of RetransTimer with a lower
> > value.
> >
> > This is however not possible since RFC2462 says
> > that 1) "in some link-layer environments,
> > particularly with MLD-snooping switches, no
> > multicast reception will be available until the
> > MLD report is sent", and 2) "a node SHOULD delay
> > joining the solicited-node multicast address by a
> > random delay between 0 and
> > possibility that the MN doesn't not receive
> > multicast traffic sent to the solicited-node
> > address and thus can't detect a duplicate address.
> > Therefore, it doesn't seem safe to reduce
> > RetransTimer to less than
> > > 2. Upload the link-local address of the mobile
> > > node to the mobile node's policy profile.
> >
> > This is what I've been suggesting and I think
> > that's the best solution out of the four listed in
> > your note.
> >
> > We discussed that many time and concluded that it
> > is problematic when multiple LMAs are used in a
> > single NetLMM domain.
> >
> > > 4. MAG should always do a DAD when ever it
> > > detects a new mobile node on its access link.
> >
> > This has the same issue as 1. above since it means
> > that the MAG won't be able to communicate before
> > DAD completes after each handover, i.e. 1 second
> > service interruption.
>
> I'm trying to see, if we can optimize on option#4,
> based on ODAD [RFC-4429], it removes the
> RetransTimer delay. 

FWIW, RFC4429 states that "A router SHOULD NOT 
configure an Optimistic Address."

> Also, its a p2p link, if the MN 
> sends any message using a link-local address, the
> MAG just needs to detect the collision and configure
> a different link-local address and start using it.

That's what DAD is for, detecting collisions.

> This issue is also not applicable when PPP is in
> use, as the identifiers are negotiated at the link
> setup.
>
> Also, relating this to 3775, when the MN moves to a
> new AR, it must do a DAD on the link-local address.
> So, the DAD latency and the issue is pretty much the
> same.

Yes the issue is pretty much the same, which is why 
DNAv6 was developed in the first place.

> probability of collision is so low, thinking, how we
> can avoid any network messaging for this.

The update of the policy store has a minimal impact 
since it will only happen when the MN does DAD, which 
for a DNAv6 node will only happen upon first 
attachment to the NETLMM domain (if the node doesn't 
use RFC3041 privacy addresses, in which case it will 
do DAD each time it renew its address.)

So I don't see a compelling reason to try to optimize 
by suppressing one rarely occurring LL update 
request/reply messages .

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 09:38:47 +0200

On Wednesday 08 August 2007, Narayanan, Vidya wrote:
> Option 2 seems incompatible with RFC3041-style
> privacy extensions.  

What would be incompatible?

> What would be the purpose of recording the MN's IID? 

To let the new MAG pick a link-local for itself that 
does not collide with that of the MN.

> What happens if the MN changed its IID later, for
> privacy reasons? 

The MN will do DAD for the new link-local, and that new 
link-local would be recorded by the MAG in the MN 
profile.

--julien

> > From: Julien Laganier
> > [mailto:[email-masked]] Sent: Tuesday,
> > August 07, 2007 1:15 AM
> > To: [email-masked]
> > Subject: Re: [netlmm] Issue: Link-local address
> > collision on the access link
> >
> > Hi Sri,
> >
> > > the mobile
> > > detects a new
> > > to million other reasons as supposed to due to
> > > link-local address collision on a p2p link.
> > >
> > > semantics
> > > that link will do the DAD operation. NETLMM
> > > modifies this view slightly. A mobile node in
> > > the NETLMM domain always thinks
> >
> > its still
> >
> > > on the same link, but, it has a new neighbor
> > > worse by supressing the DAD operation after a
> > > link up/down event.
> > >
> > >
> > > Proposed Solutions:
> > >
> > > the mobile

---

From: <[email-masked]>
Date: Wed, 8 Aug 2007 10:57:48 +0300

>From: ext Julien Laganier [mailto:[email-masked]] 
>Sent: 08 August, 2007 10:36
>To: Sri Gundavelli
>Cc: [email-masked]
>> > Thanks for summarizing the issue. I support solution 2 (see my 
>> > comments on the proposed solutions inlined below).
>> >
>> > > Proposed Solutions:
>> > >
>> > > force the mobile node to redo DAD operation every time the 
>node does 
>> > > not detect a link change .
>> >
>> > If the MN is forced to redo DAD after each handover, this will 
>> > severely impact the handover performance of NETLMM since upon each 
>> > handover a MN will have to wait for DAD completion before 
>> > transitioning its address from tentative to assigned 
>state. With the 
>> > default DAD parameters (i.e. DupAddrDetectTransmits is 1 and 
>> > RetransTimer is RETRANS_TIMER = 1000 milliseconds) that means that 
>> > the MN will not be able to communicate for 1 second.
>> >
>> > I thought that the bad effects of DAD could be alleviated 
>by having 
>> > the router (MAG) overriding the default value of 
>RetransTimer with a 
>> > lower value.
>> >
>> > This is however not possible since RFC2462 says that 1) "in some 
>> > link-layer environments, particularly with MLD-snooping 
>switches, no 
>> > multicast reception will be available until the MLD report 
>is sent", 
>> > and 2) "a node SHOULD delay joining the solicited-node multicast 
>MAX_RTR_SOLICITATION_DELAY". 
>> > multicast traffic sent to the solicited-node address and 
>thus can't 
>> > detect a duplicate address.
>> > Therefore, it doesn't seem safe to reduce RetransTimer to 
>less than 
>> > We discussed that many time and concluded that it is problematic 
>> > when multiple LMAs are used in a single NetLMM domain.
>> >
>> > This has the same issue as 1. above since it means that the MAG 
>> > won't be able to communicate before DAD completes after each 
>> > handover, i.e. 1 second service interruption.
>>
>> I'm trying to see, if we can optimize on option#4, based on ODAD 
>> [RFC-4429], it removes the RetransTimer delay.
>
>FWIW, RFC4429 states that "A router SHOULD NOT configure an 
>Optimistic Address."
>
>> sends any message using a link-local address, the MAG just needs to 
>> detect the collision and configure a different link-local 
>address and 
>> start using it.
>
>> This issue is also not applicable when PPP is in use, as the 
>> identifiers are negotiated at the link setup.
>>
>> Also, relating this to 3775, when the MN moves to a new AR, 
>it must do 
>> a DAD on the link-local address.
>> So, the DAD latency and the issue is pretty much the same.
>

In RFC 3314 entire /64 as assigned to a mobile connection so DAD is not
useful. 

>> We can certainly update the policy store. Since, the probability of 
>> collision is so low, thinking, how we can avoid any network 
>messaging 
>> for this.
>
>The update of the policy store has a minimal impact since it 
>will only happen when the MN does DAD, which for a DNAv6 node 
>will only happen upon first attachment to the NETLMM domain 
>(if the node doesn't use RFC3041 privacy addresses, in which 
>case it will do DAD each time it renew its address.)

Isn't it IID can be used only for link local address which is not
supposed to expose or leak outside the link? So p2p link within NETLMM
needs to follow the RFC 3041.

-Preeti
>
>So I don't see a compelling reason to try to optimize by 
>suppressing one rarely occurring LL update request/reply messages .
>
>--julien
>

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 10:23:56 +0200

On Tuesday 07 August 2007, Vijay Devarapalli wrote:
> How about storing it on the LMA? When the MN enters
> a PMIPv6 domain, the MN performs DAD and the MAG
> informs the LMA of the link local address of the MN.
> The others MAGs in the PMIPv6 domain get the link
> local address of the MN from the LMA. No need to
> involve the "policy store".

Yes that would work! Let's do that then.

--julien

---

From: "John.zhao" <[email-masked]>
Date: Wed, 08 Aug 2007 16:32:32 +0800

See my comments in line.

	Best Rgds,
Thanks,
John.zhao

Yes that would work! Let's do that then.
[John.zhao] Yes,we may use the LAM to store the LLD of MN. But,what should
to do if a MAG get it from LMA and find that conflict with itself.Reject the
roaming request ? Otherwise, any other choice?
--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 10:37:25 +0200

On Wednesday 08 August 2007, 
[email-masked] wrote:
> >From: ext Julien Laganier
> >>
> >> use, as the identifiers are negotiated at the
> >> link setup.
> >>
> >> Also, relating this to 3775, when the MN moves to
> >> a new AR, it must do a DAD on the link-local
> >> address. So, the DAD latency and the issue is
> >> pretty much the same.
> >
> In RFC 3314 entire /64 as assigned to a mobile
> connection so DAD is not useful.

RFC3314 has recommendations on how to use IPv6 for 
*GPRS*. This is not what we're discussing here. GPRS 
does not need DAD for the same reason than PPP does 
not need it: mobile node addresses are assigned by the 
other end of the point-to-point link (i.e. the PPP 
server or the GGSN). 

This is not relevant to what we're discussing here 
since the NETLMM protocol must be agnostic to the link 
layer technology in use on the access link, and hence 
cannot rely on a lower layer to configure IPv6 
addresses and avoid collisions. That mean DAD will be 
used. (Think about IPv6 over IEEE 802.16, IEEE 802.16 
does not deal with IPv6 address assignment; that mean 
DAD will be used.)

> >> We can certainly update the policy store. Since,
> >> the probability of collision is so low, thinking,
> >> how we can avoid any network messaging for this.
> >
> > since it will only happen when the MN does DAD,
> > which for a DNAv6 node will only happen upon first
> > attachment to the NETLMM domain (if the node
> > doesn't use RFC3041 privacy addresses, in which
> Isn't it IID can be used only for link local address
> which is not supposed to expose or leak outside the
> link? So p2p link within NETLMM needs to follow the
> RFC 3041.

I don't understand that part -- An IPv6 *packet* with a 
link-local address in source or destination field 
cannot leave the link. 

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 10:40:27 +0200

On Wednesday 08 August 2007, John.zhao wrote:
> On Wednesday 08 August 2007, Julien Laganier wrote:
> > > How about storing it on the LMA? When the MN
> > > enters a PMIPv6 domain, the MN performs DAD and
> > > the MAG informs the LMA of the link local
> > > address of the MN. The others MAGs in the PMIPv6
> > > domain get the link local address of the MN from
> > > the LMA. No need to involve the "policy store".
> >
> [John.zhao] Yes,we may use the LAM to store the LLD
> of MN. But,what should to do if a MAG get it from
> LMA and find that conflict with itself.Reject the

The idea is that the MAG picks a link-local address for 
itself to use on the point-to-point link to a given MN 
after it get the link-local address of that MN (from 
the LMA as Vijay suggested.) It it therefore in 
position to pick a link-local address that does not 
collide.

--julien

---

From: <[email-masked]>
Date: Wed, 8 Aug 2007 12:26:37 +0300

Thanks Julien

Inline pl. 

-Preeti 

>Behalf Of ext Julien Laganier
>Sent: 08 August, 2007 11:37
>To: Vinayakray-Jani Preetida (Nokia-NRC/Helsinki)
>Cc: [email-masked]; [email-masked]
>AR, it must 
>> >> do a DAD on the link-local address. So, the DAD latency and the 
>> >> issue is pretty much the same.
>> >
>> In RFC 3314 entire /64 as assigned to a mobile connection so DAD is 
>> not useful.
>
>RFC3314 has recommendations on how to use IPv6 for *GPRS*. 
>This is not what we're discussing here. GPRS does not need DAD 
>for the same reason than PPP does not need it: mobile node 
>addresses are assigned by the other end of the point-to-point 
>link (i.e. the PPP server or the GGSN). 
>
>This is not relevant to what we're discussing here since the 
>NETLMM protocol must be agnostic to the link layer technology 
>in use on the access link, and hence cannot rely on a lower 
>layer to configure IPv6 addresses and avoid collisions. That 
>mean DAD will be used. (Think about IPv6 over IEEE 802.16, 
>IEEE 802.16 does not deal with IPv6 address assignment; that 
>mean DAD will be used.)

I understand that NETLMM work is agnostic to the link layer tech.
However I should have placed some more details for discussion. My
concern was here just for rejecting the domain specific solution #3 and
I just want to understand that why this is not very good solution. 

Consider GPRS is one single domain where it can talk to mulitple
LMAs/HAs and considering same analogy for NETLMM domain where it can
talk to mulitple LMAs. In GPRS domain such case is no problem hence I
would like to understand response 'it is problematic when multiple LMAs
are used in a single NetLMM domain'    

Meanwhile when you are suggesting the policy specific solution. Then
similar type of policy which resembeles for GPRS domain for getting link
local address here can be done. Isn't it? Or I'm missing something here.

>probability of 
>> >> messaging for this.
>> >The update of the policy store has a minimal impact  since it will 
>> >only happen when the MN does DAD,  which for a DNAv6 node will only 
>> >happen upon first  attachment to the NETLMM domain (if the node  
>> >doesn't use RFC3041 privacy addresses, in which  case it 
>will do DAD 
>> >each time it renew its
>> > address.)
>>
>link-local address in source or destination field cannot leave 
>the link. 

One way Proxy IPv6 already hides the location of the MN. And link local
address property itself says that packet should not transfer beyoond its
scope. 

Thanks
Preeti

---

From: "John.zhao" <[email-masked]>
Date: Wed, 08 Aug 2007 17:59:58 +0800

[John.zhao] Do you mean the MAG will pick a IID for itself from LMA? But
that seems not the mean of the method 2, only the IID of MN is mentioned in
it. But anyway, I only want to confirm the MAG will report the IID of MN to
LMA and then get the IID for this MAG to use , right?
	Even though, that will means the LMA will maintenance a pool for the
IIDs available to all of the MAGs connected to it. Right?
	By this way, the router discovery still can't be omitted. 

John.zhao

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 13:32:26 +0200

On Wednesday 08 August 2007, John.zhao wrote:
> > > > > 2. Upload the link-local address of the
> > > > > mobile node to the mobile node's policy
> > > > > profile.
> > > >
> > > > enters a PMIPv6 domain, the MN performs DAD
> > > > and the MAG informs the LMA of the link local
> > > > address of the MN. The others MAGs in the
> > > > PMIPv6 domain get the link local address of
> > > > the MN from the LMA. No need to involve the
> > > > "policy store".
> > >
> > [John.zhao] Yes,we may use the LAM to store the
> > LLD of MN. But,what should to do if a MAG get it
> > from LMA and find that conflict with itself.Reject
> > the roaming request ? Otherwise, any other choice?
>
> The idea is that the MAG picks a link-local address
> for itself to use on the point-to-point link to a
> given MN after it get the link-local address of that
> MN (from the LMA as Vijay suggested.) It it
> therefore in position to pick a link-local address
> that does not collide.
>
> [John.zhao] Do you mean the MAG will pick a IID for
> itself from LMA? 

The MAG get the IID of the MN from the LMA. Then the 
MAG can choose for itself an IID that does not collide 
with the IID of the MN. The IID of the MAG is locally 
chosen and not stored in LMA.

> But that seems not the mean of the 
> method 2, only the IID of MN is mentioned in it. 

This is what method 2 was about.

> But anyway, I only want to confirm the MAG will
> report the IID of MN to LMA and then get the IID for
> this MAG to use , right? 

No, the MAG's IID will be generated locally by the MAG, 
but avoiding collision with the MN's IID retrieved 
from the LMA.

> Even though, that will means the LMA will maintenance
> a pool for the IIDs available to all of the MAGs
> connected to it. Right? 

See above. The LMA will only maintain for a given MN 
the IID in use by that MN. That can be stored in the 
proxy binding cache entry of the MN.

> By this way, the router discovery still can't be

Right, nobody discussed that. 

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 14:10:12 +0200

Hi Christian,

On Wednesday 08 August 2007, Christian Vogt wrote:
> > What will happen is: when the old binding is
> > removed, an unmodified host will have no way to
> > know that the old NETLMM binding was removed and
> > will keep its HoA configured on the interface that
> > created that old binding.
>
> Right.  What we need to avoid this is the same
> mechanism through which a MAG withdraws a home
> prefix after a binding was rejected by the LMA.

Right. We'd also need a mechanism through which an LMA 
can inform the old MAG that it is deleting an old 
binding (because a new one is being established to a 
new MAG). The old MAG would then be in position to 
withdraw the home prefix.

> Withdrawing the home prefix on the old link should
> make the mobile node unconfigure the home address on
> the old interface.

Right.

> As mentioned by Suresh during the NETLMM session in
> Chicago, it may not be sufficient to simply set the
> home prefix lifetime to zero in Router Advertisement
> messages.  The mobile node may in such a case simply

Yes, it is true that it would not work when the RA is 
authenticated. 

But when SEND is used, sending an RA containing a PIO 
with zero lifetime would cause the MN to stop using 
that address. (Hey, finally one good reason to use 
SEND :-P )

--julien

---

From: "John.zhao" <[email-masked]>
Date: Wed, 08 Aug 2007 20:09:51 +0800

Right, nobody discussed that. 
[John.zhao] I see. So the MAG will need to generate dynamically IID for use
to connected by different MNs. But juat as mentioned above the router
discovery still consume the time of this handover progress. So MN seems not
benefit much more from this mechanism. 
	On the other hand , if we choose the IID of LMA, then everything is
ok. The DAD is no need  and the router discovery is also no need during the
handover progress. So seems this is the option 5#.

Best Rgds,
Thanks,
John.zhao

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 15:38:04 +0200

On Wednesday 08 August 2007, John.zhao wrote:
> 
> > > [John.zhao] Do you mean the MAG will pick a IID
> > > for itself from LMA?
> >
> > The MAG get the IID of the MN from the LMA. Then
> > the MAG can choose for itself an IID that does not
> > collide with the IID of the MN. The IID of the MAG
> > is locally chosen and not stored in LMA.
> >
> > > report the IID of MN to LMA and then get the IID
> > > for this MAG to use , right?
> >
> > No, the MAG's IID will be generated locally by the
> > MAG, but avoiding collision with the MN's IID
> > retrieved from the LMA.
> >
> > > Even though, that will means the LMA will
> > > maintenance a pool for the IIDs available to all
> > > of the MAGs connected to it. Right?
> >
> > See above. The LMA will only maintain for a given
> > MN the IID in use by that MN. That can be stored
> > in the proxy binding cache entry of the MN.
> >

> [John.zhao] I see. So the MAG will need to generate
> dynamically IID for use to connected by different
> MNs. 

The MAG can use the IID all the time as long as there's 
no collision. For the rare cases where there is a 
collision, then it can flip a single bit in the IID to 
avoid that collision.

> But juat as mentioned above the router 
> discovery still consume the time of this handover
> progress. 

The latency incurred by the router discovery itself  
(i.e RtSol/RtAdv exchange) one round trip time on the 
access link (MN-MAG). This is negligible compared 
latencies induced by other aspects of the PMIP 
protocol (e.g. PBU/PBA exchange between the MAG and an 
LMA far away in the core network).

> So MN seems not benefit much more from 
> this mechanism.

Yes it will benefit since it works well with DNAv6 
nodes, and DNAv6 avoids DAD latency which is 1 second 
by default.

And one second is a *lot* compared to the latencies 
we've talked about so far (RtSol/RtAdv latency, 
PBU/PBA latency).

> 	On the other hand , if we choose the IID of LMA,
> then everything is ok. The DAD is no need  and the
> router discovery is also no need during the handover
> progress. So seems this is the option 5#.

See my comments above. The router discovery induced 
latency is negligible relatively to PMIP induced 
latency. It doesn't make sense to optimize something 
negligible.

[ and BTW, in what you're proposing the MAG is no 
longer an IPv6 router, but a transparent IPv6-layer 
bridge. That's not the assumption we've been working 
with in the WG. ]

--julien

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 08 Aug 2007 10:27:08 -0400

Hi Julien,
   Mostly agree with you except for one thing.

> that address. (Hey, finally one good reason to use 

Not always. This depends on the RemainingLifetime. If the 
RemainingLifetime is less than 2 hrs, yes. Otherwise, no.

Cheers
Suresh

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 16:43:10 +0200

My comments inline below,

On Wednesday 08 August 2007, 
[email-masked] wrote:
> > *GPRS*. This is not what we're discussing here.
> > GPRS does not need DAD for the same reason than
> > PPP does not need it: mobile node addresses are
> > assigned by the other end of the point-to-point
> > since the NETLMM protocol must be agnostic to the
> > link layer technology in use on the access link,
> > and hence cannot rely on a lower layer to
> > configure IPv6 addresses and avoid collisions.
> > That mean DAD will be used. (Think about IPv6 over
> > IEEE 802.16, IEEE 802.16 does not deal with IPv6
> > address assignment; that mean DAD will be used.)
>
> I understand that NETLMM work is agnostic to the
> link layer tech. However I should have placed some
> more details for discussion. My concern was here
> just for rejecting the domain specific solution #3
> and I just want to understand that why this is not
> very good solution.

In the solution #3 that we discussed on the mailing 
list for a long time, and that we denote 
by 'domain-wide link-local address uniquenes', a 
NETLMM domain ensure at the first MN attachment that 
it is not going to configure a link local address that 
can collide with the link local address of any MAGs in 
the domain (hence the domain-wide qualifier). 

To ensure that I proposed that 1) the LMA knows all 
link-local addresses of all MAGs in the domain, and 2)  
when the MN first attaches, and DAD its link local, 
the MAG ask the LMA if the MN's link-local conflict 
with any of the MAGs' link-local; in case it would, 
the MAG would then defend the link-local in question 
as to avoid any further collision. That wasn't deemed 
good since the LMA would have to know about every 
MAG's link local even though none of its MN is 
attached there.

> Consider GPRS is one single domain where it can talk
> to mulitple LMAs/HAs and considering same analogy
> for NETLMM domain where it can talk to mulitple
> LMAs. In GPRS domain such case is no problem hence I
> would like to understand response 'it is problematic
> when multiple LMAs are used in a single NetLMM
> domain'

I shouldn't have said that, it was the wrong shortcut 
to the discussion we had earlier on the scheme and its 
problems: The 'problematic when multiple LMAs are used 
in a single NetLMM domain' part refers to issues 
involved with collisions over shared links. Since we 
ruled support for shared link out of scope that is 
unrelated to that discussion. Sorry about that, I just 
confused things. For the problems of that scheme, see 
discussion above about having each LMA knowing about 
all MAG's link-local addresses.

> Meanwhile when you are suggesting the policy
> specific solution. Then similar type of policy which
> resembeles for GPRS domain for getting link local
> address here can be done. Isn't it? Or I'm missing
> something here.

It is entirely different from GPRS. 

First of all, in GPRS the IPv6 next hop from the UE 
(and BTW its only neighbor since the link is 
point-to-point) is the GGSN, and the GGSN doesn't 
change when the UE moves within the GPRS domain. That 
is in contrast to NETLMM where the next hop from the 
MN is the MAG, and the MAG changes each time a 
handover occurs. Thus in NETLMM there is an address 
collision issue in between one MN and many MAGs, 
whereas in GPRS the issue is only between the UE and 
the GGSN.

Secondly, GPRS "stateless" address autoconfiguration 
looks like that of PPPv6: the UE link-local address is 
assigned by the GGSN at primary PDP context activation 
(that is, it is stateless from IPv6 point of view, but 
in reality it is statefull at the lower layer, but 
that is beyond the point). The GGSN merely ensures 
that no collision occurs between its own link-local 
address and that of the UE. That is again different 
from the generic IPv6 stateless address 
autoconfiguration that we consider in NETLMM where a 
MN is supposed to generate itself its link-local 
address, and then try to detect for a possible 
duplicate using DAD.

The solution that works well is solution #2:

- Whenever a MN does DAD for a link-local, the MAG 
register that link-local with the MN's LMA.
 
- Whenever a new MN attaches to a MAG, the MAG gets the 
IID of the MN from the LMA. The MAG can then choose 
for itself an IID that does not collide with the IID 
of the MN. 

> >> >> We can certainly update the policy store.
> >> >> Since, the probability of collision is so low,
> >> >> thinking, how we can avoid any network
> >> >> messaging for this. 
> >> >
> >> > The update of the policy store has a minimal
> >> > impact  since it will only happen when the MN
> >> > does DAD,  which for a DNAv6 node will only
> >> > happen upon first  attachment to the NETLMM
> >> > domain (if the node doesn't use RFC3041 privacy
> >> > addresses, in which  case it will do DAD
> >> >each time it renew its address.)
> >>
> >> Isn't it IID can be used only for link local
> >> address which is not supposed to expose or leak
> >> outside the link? So p2p link within NETLMM
> >I don't understand that part -- An IPv6 *packet*
> > with a link-local address in source or destination
> > field cannot leave the link.
>
> One way Proxy IPv6 already hides the location of the
> MN. And link local address property itself says that
> packet should not transfer beyoond its scope.

Nobody said that any *packet* containing MN's 
link-local in source or destination fields would be 
*forwarded* beyond the link. What was suggested is 
that a MAG registers its MN's link local with the LMA. 

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 8 Aug 2007 17:01:49 +0200

> Hi Julien,

Hi Suresh,

Right, see below:

> Julien Laganier wrote:
> >> As mentioned by Suresh during the NETLMM session
> >> in Chicago, it may not be sufficient to simply
> >> set the home prefix lifetime to zero in Router
> >> Advertisement messages.  The mobile node may in
> >> such a case simply ignore the sudden lifetime
> >> change for DoS protection.
> >
> > Yes, it is true that it would not work when the RA
> > is authenticated.

FWIW, what I meant here was that "it would not work 
when the RA is NOT authenticated." (but I think you 
understood what I meant :)

> > But when SEND is used, sending an RA containing a
> > PIO with zero lifetime would cause the MN to stop
> > using that address. (Hey, finally one good reason
> > to use SEND :-P )
>
> Not always. This depends on the RemainingLifetime.
> If the RemainingLifetime is less than 2 hrs, yes.
> Otherwise, no.

Ah, you're right, I read too quickly into 2462bis. 
Thanks for catching this!

So for the MN to unconfigure an address upon reception 
of a SEND-protected RA with a zero-lifetime PIO, we 
also have to mandate that all RAs send by MAG contains 
PIO with valid lifetime of at most 2 hours. Right?

--julien

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 08 Aug 2007 11:09:19 -0400

Hi Julien,

> understood what I meant :)

Yes, I did :-).

> Thanks for catching this!

No problems.

> PIO with valid lifetime of at most 2 hours. Right?

Yes. With valid lifetime of < 2hrs, this should work.

Cheers
Suresh

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 8 Aug 2007 10:33:31 -0500

Hi Julien,

see my in

Mohamed>> I believe a mechanism which is defined in

http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio
n-01.txt

can be used to do what u described above

---

From: Christian Vogt <[email-masked]>
Date: Thu, 09 Aug 2007 10:19:34 +0300

>> Yes, it is true that it would not work when the RA is authenticated.
>> But when SEND is used, sending an RA containing a PIO with zero
>> lifetime would cause the MN to stop using that address. (Hey, finally
>> one good reason to use SEND :-P )
> 

Hmm, RFC 2462bis is actually slightly ambiguous about this.

If you read bullet 2 on page 19, it is not clear whether the restriction
"If RemainingLifetime is less than or equal to 2 hours..." also applies
to the rule

                                    If the Router Advertisement
    was authenticated, the valid lifetime of the corresponding
    address should be set to the Valid Lifetime in the received
    option.

Independent of this wording, /conceptually/ I don't see a reason for NOT
accepting the Valid Lifetime value of a Router Advertisement message,
regardless of how small that value is, if the message is authenticated.

- Christian

---

From: "John.zhao" <[email-masked]>
Date: Thu, 09 Aug 2007 16:15:33 +0800

On Wednesday 08 August 2007, John.zhao wrote:
> ...... (omitted those discussed)

The latency incurred by the router discovery itself  
(i.e RtSol/RtAdv exchange) one round trip time on the 
access link (MN-MAG). This is negligible compared 
latencies induced by other aspects of the PMIP 
protocol (e.g. PBU/PBA exchange between the MAG and an 
LMA far away in the core network).
[John.zhao] What means the negligible? During handover progress, MN will
detect the new router reachable after it can believe that old one is
unreachable. The neighbor unreachable detection will cost :
	Random factor times BaseReachableTime milliseconds.
	Comments: Random factor between MIN_RANDOM_FACTOR and
MAX_RANDOM_FACTOR
			MIN_RANDOM_FACTOR :0.5
			MAX_RANDOM_FACTOR :1.5
			The default value of basereachabletime is 30,000
	(The definition above come from RFC2461)
	to do the neighbor unreachable detection.
	Considering the time before MN initiate the NUD progress, this time
maybe less than 1 second, but can't be ignored to a continues application. I
estimate it will need 30-200 microseconds.
	So we can conclude that it not as simple as a round-trip RS/RA
progress.

Yes it will benefit since it works well with DNAv6 
nodes, and DNAv6 avoids DAD latency which is 1 second 
by default.
[John.zhao] But DNAv6 is a option to MN, not mandatory.

[ and BTW, in what you're proposing the MAG is no 
longer an IPv6 router, but a transparent IPv6-layer 
bridge. That's not the assumption we've been working 
with in the WG. ]
[John.zhao]The same as the above explanation. The discovery and decision for
default gateway isn't a negligible progress.
--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 9 Aug 2007 10:25:57 +0200

> Hi Julien,

Hi Mohamed,

> see my in
>
> Right. We'd also need a mechanism through which an
> LMA can inform the old MAG that it is deleting an
> old binding (because a new one is being established
> to a new MAG). The old MAG would then be in position
> to withdraw the home prefix.
>
> http://www.ietf.org/internet-drafts/draft-muhanna-mi
>p6-binding-revocatio n-01.txt
>

Yes, seems like it would work.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 9 Aug 2007 01:27:55 -0700 (PDT)

On Wed, 8 Aug 2007, Christian Vogt wrote:

> ignore the sudden lifetime change for DoS protection

With respect to the prefix withdrawal on the access link:

1. The MAG will advertise the prefix with zero lifetime.

2. The MAG will remove the routing state for that prefix.
It will remove the default route over the tunnel, i.e.
the route for tunneling all packets matching that source
prefix. The MAG will not forward any packets sent to/from
that address.

Now, if 2461bis modifies the behaviour of advertising
prefixes with 0 lifetime, i.e if the interpretation of 2 hour
backout is correct, the mobile node may potentially continue to
have an address from that prefix. But, there will not be any
routing or mobility enabled for that address/prefix.

I've discussed this issue with Suresh in Chicago as well.

Sri

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 09 Aug 2007 11:39:44 +0200

Sri,

last comment from my side about this, just to ensure it turns
into the right direction.

Sri Gundavelli wrote:
>>>> That depends on the nature of the MNID and how the MNID is 
>>>>         
>> mapped to
>>     
I referred to this as it conflicts with the assumptions you describe.
That needs to be consistent throughout the base spec. I did not propose to
disallow techno specific info (e.g. MAC address) in the MNID.
I think its (or at least will be) needed. If the MNID is supposed to
be entirely techno-independent and represents for example only a NAI,
we might need a further optional parameter later, which allows techno-info
coming along with a PBU.

marco

---

From: Christian Vogt <[email-masked]>
Date: Thu, 09 Aug 2007 12:55:39 +0300

> MAX_RTR_SOLICITATION_DELAY (1 second) if we want to 

We considered exactly this when Optimistic DAD got standardized:

  http://www1.ietf.org/mail-archive/web/ipv6/current/msg05777.html

The primary reason why a node must join the solicited-node multicast
group for its prospective new IP address /before/ it initiates the DAD
procedure is to recognize the unlikely event that another node attempts
to configure the same IP address at the same time.  For such a case,
both nodes should be able to receive each other's Neighbor Solicitation
messages, which are sent to the solicited multicast group.

As standardized, Optimistic DAD let's a node join the solicited-node
multicast group immediately, and initiate the DAD procedure afterwards.

My personal opinion is that relying on DAD (option 1) is the cleanest
solution for our purpose.  Standard DAD will work, but if nodes support
Optimistic DAD, things will be more efficient.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 09 Aug 2007 13:09:25 +0300

> routing or mobility enabled for that address/prefix.

The problem is that the existence of the same address on two interfaces
of the mobile node may cause problems on the mobile-node side -- and
thus violate the requirement for P-MIPv6 to be transparent to hosts.

One specific issue is the question through which interface the mobile
node would send a packet that is sourced from the home address.

We need to avoid such issues.  Leaving a mobile node with the same
address on two interfaces is hence not an option in my opinion.  But as
I said in my previous email:  I think the wording in RFC 2462bis is just
a bit ambiguous.  The real intention behind it is, I assume, that hosts
adopt the valid lifetime advertised in authenticated RAs without change.

- Christian

---

From: Julien Laganier <[email-masked]>
Date: Thu, 9 Aug 2007 13:58:11 +0200

John,

Comments inlined below,

[ You would make it easier for me (and I suspect other 
readers of the mailing list) to read and reply to your 
message if you would use the "usual" quotation style 
(i.e. putting a "> " in front of a line you're 
quoting) when replying. ]

On Thursday 09 August 2007, John.zhao wrote:
> > > discovery still consume the time of this
> > > handover progress.
> >
> > The latency incurred by the router discovery
> > itself (i.e RtSol/RtAdv exchange) one round trip
> > time on the access link (MN-MAG). This is
> > negligible compared latencies induced by other
> > aspects of the PMIP protocol (e.g. PBU/PBA
> > exchange between the MAG and an LMA far away in
> > the core network).
>
> [John.zhao] What means the negligible? During
> handover progress, MN will detect the new router
> reachable after it can believe that old one is
> unreachable. The neighbor unreachable detection will
> cost : Random factor times BaseReachableTime
> milliseconds. Comments: Random factor between
> MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR
> 			MIN_RANDOM_FACTOR :0.5
> 			MAX_RANDOM_FACTOR :1.5
> 	Considering the time before MN initiate the NUD
> progress, this time maybe less than 1 second, but
> can't be ignored to a continues application. I
> 	So we can conclude that it not as simple as a
> round-trip RS/RA progress.

This is as simple as an RS/RA round trip if the mobile 
node has movement detection support (i.e. DNAv6). I'm 
assuming that the minimal host support for an host 
expected to be mobile (e.g. a laptop) includes a 
movement detection.

> > nodes, and DNAv6 avoids DAD latency which is 1
> > second by default.
>

A mobile node that doesn't implement any kind of 
movement detection will experience sub-optimal network 
attachment performance, NETLMM or not.

That's why IETF has work on DNAv6. 

DNAv6 might well be optional, if a host software vendor 
decides to ship host software for mobile hosts without 
movement detection support, the vendor is responsible 
for the suboptimal network attachment performance that 
such hosts will experience. That is not the problem of 
NETLMM (or say MIPv6, MIPv4, HMIPv6, etc.).

> > And one second is a *lot* compared to the
> > latencies we've talked about so far (RtSol/RtAdv
> > latency, PBU/PBA latency).
> >
> > > 	On the other hand , if we choose the IID of
> > > LMA, then everything is ok. The DAD is no need 
> > > and the router discovery is also no need during
> > > the handover progress. So seems this is the
> > > option 5#.
> >
> > See my comments above. The router discovery
> > induced latency is negligible relatively to PMIP
> > induced latency. It doesn't make sense to optimize
> > something negligible.
> >
> > longer an IPv6 router, but a transparent
> > IPv6-layer bridge. That's not the assumption we've
> > been working with in the WG. ]
>
> [John.zhao]The same as the above explanation. The
> discovery and decision for default gateway isn't a
> negligible progress. 

It is a negligible process whenever a host expected to 
be mobile has been shipped with a host software 
appropriate in that context, i.e. including built-in 
support for movement detection.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 9 Aug 2007 10:32:32 -0700 (PDT)

Hi Christian,

> node would send a packet that is sourced from the home address.

A normal IPv6 node with unmodified IPv6 stack, should not be allowing
more than one interface to configure the same address configuration
or share the same onlink prefix. Atleast, Cisco IPv6 implementation
does not allow this. I assume this is true for Windows vista as well.
Even if it did, the route resolution will always pick the first
entry.

HA(config)#int ethernet 0/1
HA(config-if)#ipv6 address abab::1/64
HA(config-if)#exit

HA(config)#int ethernet 0/2
HA(config-if)#ipv6 address abab::1/64
%Ethernet0/2: Error: ABAB::1/64 is in use on Ethernet0/1

HA(config-if)#ipv6 address abab::2/64
%Ethernet0/2: Error: ABAB::/64 is overlapping with ABAB::/64 on 
Ethernet0/1

IMO, we should state that this configuration is not supported and leave
it to the deployments on how they enforce it. Also, since this is going
to be deployed in a managed network, operators have control on this
aspect.

When a mobile node attaches to a MAG, the MAG must decide if network-based
mobility management service is to be enabled it or not. This check is done
prior to before the NETLMM protocol gets kicked in. As part of this check,
operators can certainly verify if there is an active session enabled for
the mobile node over some other interface. This can be done interfacing
with the other elements tracking the mobile node's accounting session. So,
if this truely an issue and assuming normal IPv6 stacks can share the
address configuration across interfaces, deployments can deal with it and
they have sufficient hooks to avoid any undesirable scenario. And, future
work on this topic can address this issue in detail, IMO.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 9 Aug 2007 10:47:49 -0700 (PDT)

Hi Marco,

> we might need a further optional parameter later, which allows techno-info

Thanks for the clarification. I understand. I think what we need to
capture is that the MN-Identifier has a 1:1 relation to the mobile node.
In some cases, that identifier may be specific to the access technology
/interface, as the MAC address example you mentioned above. But, the
NETLMM protocol should be able to identify a mobile node using that
one MN-Identifier and it should have the ability to acquire that
identifier when the mobile node attaches to the access link. We will
document this as we concluded in this thread.

Thanks
Sri

---

From: "John.zhao" <[email-masked]>
Date: Fri, 10 Aug 2007 09:47:50 +0800

Hi,Julien
	I understand what you mean. Of course we can append some software on
terminals to power the intelligence of terminal. But we must make sure what
is the assumption of this work group. In netlmm, we shouldn't depend on or
require MN to support any other additional functions. Although , MN can be
appended anything.
	So back to this problem, the best choice is that we can resolve this
problem without the dependency of any other involvement of terminal.
	This is why I didn't mention about DNAv6. 
	My two cents.
	[The '>' didn't be appended by my mail client. I check it and add
it. :-)]
	Best Rgds,
Thanks,
John.zhao
> ------------------------------------------------

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 12 Aug 2007 22:19:21 -0700

Hi Julien,
 
> configure an Optimistic Address."

I'm ok allowing the MAG to push the MN's link-local address
to the network. But, this requires the MAG to predictably
identify the MN's link-local address, implies it should
be able to receive the packets sent to the corresponding
solicited-node multicast address. We can say, its a p2p 
link and so the MAG should snoop those packets. Also, for
for resolving an address that is on a link, we are going
out of the link. Is that a good approach ? If ODAD has
efficient semantics, with no Retrans delay etc, we should
be able to use it and its probably the right approach. I'm
still in favor of not considering DNAv6 for now, its a p2p
link. It would make more sense to solve it along with the
work on support for shared links.

Any case, I want to close this issue. If others support
the approach of pushing the MN's link-local address to the
network, I'm ok. We don't have much time and we need to close
these issues.

Thanks
Sri

---

From: "John.zhao" <[email-masked]>
Date: Mon, 13 Aug 2007 16:43:48 +0800

Hi,Sri and Julien

	I still think that it is more simpler that MAG get the link-local
address of LMA from central entity or just LMA.
	To a p2p link mode, if we can discard the DAD, but why we are
talking so much to minor the impact of DAD?

	My two cents.

	Best Rgds,
Thanks,

John.zhao

> 发送时间: 2007年8月13日 13:19
> 收件人: 'Julien Laganier'
> 抄送: [email-masked]

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 13 Aug 2007 11:46:28 -0400

Hi Christian,

>     address should be set to the Valid Lifetime in the received

Since it is on the same bullet, I think it does apply. With my 
implementer hat on, that is how I would read it. If the authenticated 
RAs rule needs to be more general, it needs to be inserted as RULE 1 
before the 3 current steps. But this change is more than editorial, and 
does not fit in as an AUTH48 change.

> regardless of how small that value is, if the message is authenticated.

One problem I foresee is that you move an address from valid directly 
into invalid and that does not allow applications to gracefully timeout 
an address based on that prefix.

Cheers
Suresh

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Aug 2007 23:56:32 +0300

Hello everybody,

*chair hat off*

Very stupid question, very late state in the protocol discussion: Why
does the MAG have to be the default router? If the LMA would be the
default router (and would send the RA) the DAD wouldn't have to be done
at every handover as the risk of having overlapping addresses would go
away.

I know this is inconsistent with how MIP4/MIP6 works. However, in
MIP4/MIP6 the FA advertisement or the Routing Advertisement is used for
mobility detection. Here we're trying to fool the host to think it
hasn't moved at all.

Cheers,

Jonne.

---

From: "John.zhao" <[email-masked]>
Date: Wed, 15 Aug 2007 10:22:14 +0800

Hi,Soininen Jonne

	Thanks for your suggestion. That is also my confusion. But I think
we don't need to restrict the behavior of MAG with only one mode. The router
or bridge are all can be considered. That means if the MAG is a router then
it will handle the routing and data traffic of MNs. Otherwise, it can be a
transparent device in bridge state. But we can treat the whole netlmm domain
as a virtual device. Thus every MAG just like the LMA to MN.

	Best Rgds,
Thanks,

John.zhao
> -----邮件原件-----
> 发件人: Soininen Jonne (NSN - FI/Espoo) [mailto:[email-masked]]
> 发送时间: 2007年8月15日 4:57
> 收件人: [email-masked]
> 抄送: 'Sri Gundavelli'; 'Julien Laganier'; [email-masked]
> 主题: Re: [netlmm] Issue: Link-local address collision on the access link
> 
> Hello everybody,
> 
> *chair hat off*
>

---

From: Julien Laganier <[email-masked]>
Date: Wed, 15 Aug 2007 04:59:50 +0200

On Tuesday 14 August 2007, Soininen Jonne (NSN - 
> Hello everybody,

Hi Jonne,

> Very stupid question, 

There's no such thing, only stupid answers :)

> very late state in the protocol discussion: Why does
> the MAG have to be the default router? If the LMA
> would be the default router (and would send the RA)
> the DAD wouldn't have to be done at every handover as
> the risk of having overlapping addresses would go
> away. 

Let's give the stupid answer first so that I'm sure I 
won't say it later: That's always been the assumption 
that the MAG is the default router :)

More seriously: If we want the LMA to be the default 
router we either need:

1- an L2 tunnel between MAG and LMA (and need to 
analyse the consequences of that w.r.t. 
multi-access-techologies NETLMM domains.)

2- the MAG to be an IP layer bridge, and we should 
specify the behavior of that IP layer bridge, how that 
operate.

3- the MAG to be a ND proxy [RFC4389]. That has problem 
with Secure Neighbor Discovery. That would also be a 
downref since 4389 is experimental.

So I'd say that it is not so as easy as saying "the LMA 
is the default router" since each of 1-3 above needs 
some work (And there's also quite some work to do to 
have the WG reaching consensus on choosing one of the 
solution above ;)

It's good that you ask the question. I'd like to hear 
other folks' opinions?

--julien

---

From: Christian Vogt <[email-masked]>
Date: Wed, 15 Aug 2007 12:32:25 +0300

> does not fit in as an AUTH48 change.

I fully agree; implementers will read it this way.  Yet, still I doubt
that this was the way it was intended.

This might be a candidate for an errata's note.

Proxy Mobile IPv6 is probably the first protocol where the meaning of
these sentences becomes very relevant.  Hence, naturally folks might not
have paid too much attention to the actual wording until now...

Right.

There should be a good reason for setting the valid lifetime to zero all
of the sudden.  But there may be situations where hosts must be stopped
immediately from using a particular prefix -- a binding rejection in
Proxy Mobile IPv6 is one of them.  If it is acceptable that hosts
continue to use an outdated prefix for a while, it should always be the
/preferred/ lifetime which gets set to zero, not the valid lifetime.

- Christian

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 15 Aug 2007 15:20:37 +0300

Julien,

> There's no such thing, only stupid answers :)

No, believe me: There are also stupid questions. My mail might help to 
prove the fact... ;)

> that the MAG is the default router :)

This much I knew already... ;)
> multi-access-techologies NETLMM domains.)

The tunnel between MAG and LMA is already an "L2-tunnel" in a way. It is 
an IP in IP tunnel, which is invisible for the end-host. There is no 
need for any special L2-tunnel functionality, if that's what you mean.

> specify the behavior of that IP layer bridge, how that 

The MAG just forwards everything coming from access to the appropriate 
tunnel and vice versa. There is not too much to specify there... (OK, 
I'm a bit simplifying it here...)

> downref since 4389 is experimental.

The MAG does not have to be an ND proxy. As the MAG just forwards 
packets without processing them it would in a way work like a L2 bridge. 
ND proxy is definitely not needed.

> It's good that you ask the question. I'd like to hear 
Look, I don't have in any way strong feelings about this. Either way is 
ok for me. However, the trade-off in my opinion, which is more difficult 
and wastes more resources: Doing DAD on every handover or making sure 
the MAG and the host addresses never collide, or to define LMA as the 
default router. I'm sure both sides have pros and cons. Though, I didn't 
want to start any project now deeply analyze these, I just wanted to 
raise awareness about the fact that the architecture of PMIP in this 
regard can be changed if the current architecture seems difficult to 
realize...

Cheers,

Jonne.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 15 Aug 2007 23:20:10 -0700

Hi Jonne,

> at every handover as the risk of having overlapping addresses would go

Good question, indeed.

Unlike in MIP6/MIP4, the mobile node's HNP is physically hosted on the MN-AR
link. The LMA is just a topological anchor point for that prefix, while MAG
is the
gateway to that prefix and is the access router hosting that prefix.
Applying the right
semantics, MAG is the default-router for the mobile node. This is a natural
configuration.

Now, for the LMA to function as the default-router for the mobile node, the
MAG
has to perform proxy ND operations on behalf of the LMA. It has to advertise
its
own L2 address for the LMA's address. It must be able to intercept packets
sent
to the LMA's L2/L3 address (its a p2p link assumed for now and not a big
deal).

Secondly, the RA's sent by the LMA have to be routed over the tunnel. Per
2461,
the RA's cannot cross the link. The same goes for the RS messages sent by
the
mobile node.

Also, the p2p link is terminating on the MAG and some changes are required
to make the p2p link terminate on the LMA, it will be like reinventing L2TP.

For allowing the mobile node to configure an IPv6 address using DHCPv6, we
just need to configure a DHCP relay service on the MN-AR link. The DHCP
request that goes out, per 3315, will be set with the prefix hint,
suggesting the
MN-HNP and the mobile node will end up with an address from its own prefix.
For the other approach, other special hooks are required for marking the
DHCP
packets with the mobile node's home network prefix.

We can make it work with the LMA as the default-router for IPv6 mobility,
but,
the protocol will be more complex at the end of the day.  IMO, this is a
simpler
configuration and with out hacks. We also need to look at the SEND and its
impact on that configuration. 

Bottom line,  MAG is the only other node on the MN-AR link, it is the access
router hosting the prefix and hence qualifies to be the default-router.
Without
prejudice.

Sri

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 16 Aug 2007 10:38:59 +0300

ext Sri Gundavelli wrote:
[snip]
> to the LMA's L2/L3 address (its a p2p link assumed for now and not a big

Julien said the same thing that MAG should then support proxy ND. I 
cannot see why would it have to support it. The virtual link would be 
extended over MAG and go between LMA and the MN. MAG would have to just 
forward the packets and maintain the binding between the "radio bearer" 
and the PMIP-tunnel. Basically MAG would be invisible for the IP stack 
of the MN (the same way SGSN is invisible for the UE in 3GPP at the 
moment, or RN in the 3GPP2 architecture).

> the RA's cannot cross the link. The same goes for the RS messages sent by

However, the link would be between the LMA and the MN. RSes and RAs 
would not cross link boundaries.

> to make the p2p link terminate on the LMA, it will be like reinventing L2TP.
I'm not sure I would agree with your statement. Why would any real 
changes PMIP be needed and why would this be like L2TP?

> packets with the mobile node's home network prefix.
Well, I'm not sure here the difference would be that big either: The 
DHCP relay would be the LMA instead of the MAG.

> router hosting the prefix and hence qualifies to be the default-router.

Like I said, I'm not too religious about this, and I'm not even sure I'm 
proposing anything here. I just want to be sure I understand the 
tradeoffs myself. However, I'm not too convinced about your argument 
that this would be more complex. In addition, SEND would work just fine.

In addition, the prefix comes from the home network and thus, is from 
the LMA's address space. For that reason it is the owner of the address 
and would be a natural first-hop-router.

I'm not sure either of these approaches is better or worse. They would 
be different.

Cheers,

Jonne.

>> <

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 16 Aug 2007 18:28:49 +0900

Hi,

Excuse me for jumping into the discussion but please find my
comments inline:

> moment, or RN in the 3GPP2 architecture).

I think it (whether ND Proxy needs to be performed or not)
really depends on network model:

- If we assume that the MAG is placed in an IP router
(access router), the MAG needs to perform ND Proxy.
The MAG replies to the NS message from the MN requesting
for the LMA's link-layer address.  Otherwise, none on
the link can inform the MN of the link-layer address of
the LMA.

- If we assume that the MAG is placed in a L2 bridge,
then as Jonne explained, all the traffic (including NDP
messages to resolve LMA's link-layer address) from the
MN is forwarded to the LMA.  Hence there is no need for
the MAG to perform ND Proxy.

So, I think it makes more sense to consider what are the
implications of the two alternatives.

In my gut feeling, placing the MAG in an IP router gives
us more flexibility.  As Bechet mentioned, it seems difficult
to locally breakout the user traffic if the MAG is acting
as a L2 bridge.  Besides the user traffic, there would also
be some control traffic from the MN that are directed to
any node other than the LMA (e.g. AAA signaling messages,
DHCP messages).  If the MAG is placed in an IP router,
there is no need to tunnel those traffic back to the LMA.

> I'm not sure either of these approaches is better or worse. They would 

Back to your question (why can't LMA be the default router for the MN),
if it is aiming for eliminating the DAD for link-local address of the MN
on every handover, it only makes sense in the case where the MAG is 
acting as a L2 bridge.  If not (meaning that MAG is an IP router), DAD
is needed as usual.

Hence I don't see great benefit of introducing an option to make the
LMA as a default router.  Forcing the MAG to act as L2 bridge puts 
undesirable limitations, IMHO.

Regards,
Shinta

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 16 Aug 2007 03:26:38 -0700

Hi Jonne,

> From: Soininen Jonne (NSN - FI/Espoo) [mailto:[email-masked]] 
> Sent: Thursday, August 16, 2007 12:39 AM
> To: ext Sri Gundavelli
> Cc: [email-masked]; 'Julien Laganier'; [email-masked]

But, how is this virtual link achieved ? If we were to support
shared-links, how is this MAG as a IPv6 node on the access link
will be able to intercept the packets ? On a p2p link, certainly 
MAG can function as a L2 bridge. The same will not work for 
shared links.

> would not cross link boundaries.

If we were to look at the access link as a psuedo wire or L2 
link across the IP network, I agree, its a single link. That
brings us more closer to the L2 network. If we were to support
admission control or other QoS services over the MAG to LMA
tunnel, we definetly need a L3 network and not a L2 wire.

> changes PMIP be needed and why would this be like L2TP?

There is a ppp context that will be on the MAG. That needs to
be relayed to the LMA. If the PPP session from the mobile 
terminates on the MAG, that state needs to be moved to the
LMA, using L2TP kind schemes. If the PPP session needs to be
terminated on the LMA, this will be like PPP over L3 network.

> DHCP relay would be the LMA instead of the MAG.

Sure, it can be done with LMA as the relay. If we view MAG as a
L2 bridge. 

> that this would be more complex. In addition, SEND would work 

The complexity comes, when add shared link suppport, DHCP relay,
support for direct local routing ..etc to the mix, we pretty
much can define an alternative model.

>From functional point of view, your view is that the MAG is just
a L2 bridge between two network segments. This will be more like
a frame relay cloud. But, MAG is a L3 device and the assumption
is that there is an IP network between the LMA and MAG. Goes back
to the NETLMM Problem statement.

> and would be a natural first-hop-router.

Sure, LMA is the prefix owner from routing perspective. It is the
reachable point for that prefix and it knows where to forward
that traffic.

But, if we were to extend this bit further, the router attached
to the higher level service provider (enterprise edge) is the
gateway to that aggregated prefix, for the rest of the internet.
But, that router is just a topological anchor point. The prefix
will be hosted some where inside the network. The same way, the
LMA is the anchor point for a MN's HNP, but, the prefix is some
where on the access link attached to the MAG.

> I'm not sure either of these approaches is better or worse. 

Good comments to challenge us. This is good.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 16 Aug 2007 04:20:14 -0700

> there is no need to tunnel those traffic back to the LMA.

I agree. Local break out is an important requirement in the
multi-layer mobility models, envisioned by some operator
network architectures. Extending MN-AR link to the LMA and
with MAG as a L2 bridge, removes that flexibility. Will 
be difficult to achieve QoS services on a L2 link.

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Thu, 16 Aug 2007 16:13:24 +0300

Hi Shinta-san,

> implications of the two alternatives.

Exactly! LMA as the default router can only work, if the MAG is a
"L2-bridge". Doing the Proxy ND and everything like that would make the
system too complex. What I explained would only work if MAG is not a L3
equipment from the MN's point of view.

> there is no need to tunnel those traffic back to the LMA.

I think this is the core of the issue and you're giving the real arguments
of the discussion. If the MAG would be a L2-bride would it restrict a lot
the applicability of the mechanism to that functionality, which the base
spec currently supports. You couldn't do local break-out,
route-optimization, or anything like that. In addition, out-of-band
signaling would basically be out of scope.

I'm a bit wondering, however, even in the MAG L3-router case if the local
break out, route optimization, and off-band signalling are possible: If you
use your home-prefix and you put the upstream traffic out already from MAG
your ingress filtering might kill the packets in the network. So, basically
you have to get a local prefix from the local network. The same is true with
out-of-band signalling. So, how real is this case?

> acting as a L2 bridge.  If not (meaning that MAG is an IP router), DAD

Yes, exactly.

> undesirable limitations, IMHO.

OK.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Thu, 16 Aug 2007 19:02:29 +0300

Hi Sri,

> MAG can function as a L2 bridge. The same will not work for

With shared links the there is a problem. However, shared links are a
problem anyways. The model does not contribute to that. That's why we're
using prefix-per-mobile model.

> tunnel, we definetly need a L3 network and not a L2 wire.

I don't think your exactly right here. You can use admission control and
other QoS features even without the MAG being a router.

> terminated on the LMA, this will be like PPP over L3 network.

First of all, I don't think any of the SDOs looking at PMIP are looking at
PPP and even if there would be PPP it could be terminated in the MAG without
the MAG being a router.

In the 3GPP system, the PPP for the laptop is terminated on the phone. It is
not taken to the network. And the phone is totally transparent for the
laptop and is not a router.

> Sure, it can be done with LMA as the relay. If we view MAG as a

If the LMA would be first hop bridge, MAG would have to be a bridge. That's
true. This is where the tradeoff is.

> much can define an alternative model.

Shared link support will make the whole system crazy anyways. Actually,
having LMA as the router/bridge for the shared link would make the shared
link model easier, not more difficult. However, it still would be a pain to
make it work.

> to the NETLMM Problem statement.

I don't know much about frame relay. However, I assume that the underlying
network between the MAG and the LMA would of course be IP or the Internet -
not L2. IMHO, having the MAG working in "bridge mode" has nothing to do with
ND proxy, QoS, L2TP (or anything similar) , or with what the network between
MAG and the LMA is. The question is about what of the router functionality
can, could, or should be used of the MAG.

> where on the access link attached to the MAG.

Right. Depends how you look at it. I think neither of the solution is "more
natural" than the other.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 16 Aug 2007 19:07:14 +0300

Sri and Shinta-san,

> be difficult to achieve QoS services on a L2 link.

Having the local break-out somehow useful, the MN should also get a 
prefix from the local network. Basically making the MN multihomed, 
right? Otherwise you're doing triangular routing, which might end up 
with ingress filtering issues. However, I think designing the local 
break-out is not in our scope right now. So, I won't go further with it.

Sri, I still don't think that the "QoS services", or whatever those 
would be, really would differ depending on if the MAG is L2 or a router...

Cheers,

Jonne.

---

From: "John.zhao" <[email-masked]>
Date: Fri, 17 Aug 2007 10:13:51 +0800

Hi,all
	
> -----邮件原件-----
> 发件人: Soininen Jonne (NSN FI/Espoo) [mailto:[email-masked]]
> 发送时间: 2007年8月17日 0:02
> 收件人: ext Sri Gundavelli
> 抄送: [email-masked]; 'Julien Laganier'; [email-masked]
Agree.
 
> laptop and is not a router.
Agree.
> link model easier, not more difficult. However, it still would be a pain
to
What do you mean that having LMA as the bridge for the shared link? If true,
who will become the anchor point of the MNs?
> Right. Depends how you look at it. I think neither of the solution is
"more

My two cents.
To the method that let MAG as a L2 bridge and LMA play as the default
router, if the tunnel between MAG and LMA will be still existed? Otherwise,
what is the difference between this and a L2 network? Seems can't find the
PMIP mechanism here.

John.zhao

---

From: "John.zhao" <[email-masked]>
Date: Fri, 17 Aug 2007 10:27:48 +0800

Hi Jonne,

> 发送时间: 2007年8月16日 21:13
> 收件人: ext Shinta Sugimoto
What is your means about 'too complex'?
In fact, even the MAG is a L3 device, it still can make this virtual link
between MN and MAG. That is no problem and didn't involve any more new big
feature except set the Link-local address the same as LMA in the interface
faced to MN.
So that is very easy. But it can resolve all of the problem related with
DAD,RD and so on. 
So I think this is more better.

> > acting as a L2 bridge.  If not (meaning that MAG is an IP router), DAD
Just like the explaination above,if the MAG use the LMA's link-local
address,DAD is no need. But in this moment, MAG can be also as a IP router.
It terminal the traffic from MN in L3 layer.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 16 Aug 2007 21:54:25 -0700

<Chair hat off>

All,
Just wanted to share with the group that we had this discussion back in
Sept 06, around the time of the NETLMM interim meeting. At the interim
meeting itself, we had an extensive discussion on each of the options.
Although that was in the context of the design team protocol at the time
and not in the context of PMIPv6, there is really no difference in
applicability.  The conclusion was to leave the MAG be a router and not
make it a bridge.  

The primary reasoning is that the internet is built on the premise of IP
routing and here, we are taking a fully functional IP entity and making
it a bridge.  This leads to certain disadvantages, since the MAG can no
longer function as an edge router for the MN.  Take multicast, for
instance.  If a network wants to support native multicast, without
having that to traverse the PMIP tunnel, that will not be feasible.   As
someone else here pointed out, we become limited in exploring options
for route optimization, etc.  Essentially, we are then extending the
link all the way to the LMA and defying the benefits of IP at the MAG.
I don't think that is necessarily a good thing for the internet. 

My 2 cents,
Vidya

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 17 Aug 2007 15:23:52 +0900

Hi Jonne,

Thank you for your response.  Please find my comments inline.

> out-of-band signalling. So, how real is this case?

Yes, you are right that in a plain PMIPv6 scenario, local breakout
would end up in a triangular routing or the packet being dropped by 
filtering (if any).  Advertising local prefix to the MN is a way to 
solve the problem, but it may increase the operational burdern of
the MN in some sense because the MN should be knowledgable about
each IP address it owns to behave as a smart multihomed host.

I guess there could be different types of solutions for this issue
(route-optimization or local breakout in PMIPv6 networks) but they
are outside the scope of the base specification.  So, let's don't
dig deeper into the issue for now.

Regards,
Shinta

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 17 Aug 2007 10:51:04 +0300

Hi Vidya,

> applicability.  The conclusion was to leave the MAG be a router and not
OK. This is enough for me.
> having that to traverse the PMIP tunnel, that will not be feasible.
>

I wonder if this is feasible in real-life even in the current model. The 
IP address the MN gets is from a totally different network. Getting MLD, 
IGMP all those to work to the network where MAG sits might become quite 
difficult.
>   As
Oh Vidya, come on... This issue has absolutely nothing to do with the 
well-being of the Internet... ;)

Cheers,

Jonne.

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 17 Aug 2007 03:14:57 -0700 (PDT)

Hi Jonne,

Just to conclude this thread.

Some other points to note, besides the comments on
the local breakout, Route Optimization, Support for
shared access link ...etc.

- Keeps the ND messages to the access link. If there
are 100'00 mobile nodes in a PMIP6 domain, each MN
is on a unique link and the RA/RS messages need not
have to be moved to the home network. So, this is some
saving.

- Does not require Proxy ND operation by the MAG for
supporting shared access link (not the shared prefix,
shared link with multiple nodes), for future extensions.

- Keeping the MN-AR link and the home link as seperate
network segments, allows us to leverage certain L3
services on the MAG and on the LMA.

The current model is probably the most preferred model
and you are ok with it as well. So, we can conclude this
thread with the comment that, both the models can be made
to work and probably the current model, if not the most
superior model, has no disadvantages when compared to the
other model.

Hope this conclusion is ok with you.

Regards
Sri

On Fri, 17 Aug 2007, Shinta Sugimoto wrote:

> would end up in a triangular routing or the packet being dropped by filtering 
> (if any).  Advertising local prefix to the MN is a way to solve the problem, 
> but it may increase the operational burdern of

---

From: "John.zhao" <[email-masked]>
Date: Fri, 17 Aug 2007 18:19:01 +0800

Hi Jonne and vidya

	MAG as a router is OK to me too. In this situation, our resolution
to those problems seem need to be decided, for example, avoiding or
diminishing DAD, the same problem to ND and so on. So I propose to consider
continue to use the link-local address of LMA as the link-local address of
the interface faced to MN in MAG. This is make sense.
	My 2 cents.

	Best Rgds,
Thanks,

John.zhao

> ext Soininen Jonne wrote:
> 
> Hi Vidya,
>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 17 Aug 2007 03:25:36 -0700 (PDT)

Hi John,

No, that clearly breaks SEND, as discussed many times
in the ML.

For the link-local address collision issue, we will
probably upload it to the LMA/network or ignore DNAv6
for now. After getting few more comments, we will resolve
this issue.

Sri

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Fri, 17 Aug 2007 20:35:41 +0200

Hi,

sorry for the delayed reply.

I support option #3 (i.e. all the MAG in a NetLMM have the same ingress LLA).
The only issue I see with this option is about the use of SEND ... but
this is not a PMIPv6 specific issue: we have already it with the use
of SEND with anycast addresses (i.e. many nodes having the same IP
address).

Best regards.

JMC.

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Fri, 17 Aug 2007 22:03:18 +0300

Hi Sri,

If the WG is happy with MAG being a router, I'm happy. I'm not sure I even
proposed to change anything. I just wanted to understand the background as
there are tradeoffs.

However, I still have some comments to your conclusion (just for the
record).

> have to be moved to the home network. So, this is some

Yeah, ok. Kind of makes sense.

> shared link with multiple nodes), for future extensions.

I think this statement is not correct. Or at least it depends on what you
mean by shared prefix.

If you would have (which we are not having) MAG as a bridge, the MAG would
need no special handling for ND. It would just forward them to the LMA. The
LMA would have to have a way of handling NDs. Either it would just broadcast
the NDs to the other hosts under the same prefix (usually this is not what
you want at least in a cellular system), or it would have to implement
proxyND.

In the case MAG is the router, it would have to implement proxyND and there
would be a lot of extra complexity in addition to the proxyND: If (which
would be logical) not all of the nodes that have the same prefix would be
under the same MAG, the MAG would have to know somehow what are the other
nodes using the same prefix. The only one who knows this is the LMA. I'm not
quite sure how this would work.

I don't think this is very important, though. Shared prefix model is not on
our agenda right now.

> services on the MAG and on the LMA.

I'm really having hard time to see this.

> superior model, has no disadvantages when compared to the

I think the important thing is that it seems that the router model has the
WG support. I don't know about the other words in the paragraph above... ;)

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Aug 2007 15:08:45 -0700

Hi Jonne, 

> Sent: Friday, August 17, 2007 12:51 AM
> To: Narayanan, Vidya
> Cc: [email-masked]; ext Shinta Sugimoto; [email-masked]
> Subject: Re: MAG as L2 bridge vs router (was RE: [netlmm] 
> Issue: Link-local address collision on the access link)
> 
> Hi Vidya,
> 
> > Just wanted to share with the group that we had this 
> discussion back 
> > in Sept 06, around the time of the NETLMM interim meeting. At the 
> > interim meeting itself, we had an extensive discussion on 
> each of the options.
> > Although that was in the context of the design team protocol at the 
> > time and not in the context of PMIPv6, there is really no 
> difference 
> > in applicability.  The conclusion was to leave the MAG be a 
> router and 
> > not make it a bridge.
> >

I'm taking this to mean that you are fine with moving ahead without a
change to the MAG being a router assumption.  Please let me know if that
is not true. 

> >
> >
> > The primary reasoning is that the internet is built on the 
> premise of 
> > IP routing and here, we are taking a fully functional IP entity and 
> > making it a bridge.  This leads to certain disadvantages, since the 
> > MAG can no longer function as an edge router for the MN.  Take 
> > multicast, for instance.  If a network wants to support native 
> > multicast, without having that to traverse the PMIP tunnel, 
> that will not be feasible.
> >
> 
> I wonder if this is feasible in real-life even in the current 
> model. The IP address the MN gets is from a totally different 
> network. Getting MLD, IGMP all those to work to the network 
> where MAG sits might become quite difficult.

This largely depends on the IP plan of the network that the MAG and LMA
belong to.  To some extent, it also depends on whether the MAG is an
IGMP/MLD Proxy/Relay or an actual multicast router, running something
like PIM-SM/DM.  The flexibility of using these mechanisms is retained
when the MAG is a router, while it is limited to just serving as an
IGMP/MLD Snooping switch, if it is turned into an L2 bridge.  That was
basically my point. 

> Oh Vidya, come on... This issue has absolutely nothing to do 
> with the well-being of the Internet... ;)
> 

:) Well, I tend to include the wireless and cellular world to be very
much part of the big "I" (even though we have segmented views on that
here at the IETF) and I do hope that one day, these worlds will adopt
the widely accepted Internet model of terminating the link layer at the
real edge of the network and not extending it back into the core
elements.  But then, that's a philosophical debate that is independent
of this issue :) 

Regards,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Aug 2007 15:11:31 -0700

Replying to my own email here :)  

<snip>

> I'm taking this to mean that you are fine with moving ahead 
> without a change to the MAG being a router assumption.  
> Please let me know if that is not true. 
> 

Never mind this :) I sent this a bit too quickly.  I see that you have
already clarfied that in some subsequent emails. 

Thanks,
Vidya

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 17 Aug 2007 17:20:25 -0500

Hi Vidya,

On 8/17/07 5:08 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

----snip------

> IGMP/MLD Snooping switch, if it is turned into an L2 bridge.  That was

Would we have to deal with how multicast is dealt with in the context of
PMIP6? 
I think it is better to keep multicast out-of-scope for the baseline draft
at least. 

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Aug 2007 15:25:34 -0700

Hi Raj,

<snip>
> 
> Would we have to deal with how multicast is dealt with in the 
> context of PMIP6? 
> I think it is better to keep multicast out-of-scope for the 
> baseline draft at least. 
> 

It is out of scope for the base draft in the sense that we are not
talking about any multicast routing mechanisms here.  I was just trying
to provide one example of why we should not turn the MAG into a pure L2
bridge, based on what is in the base document today.  

Vidya

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 17 Aug 2007 17:28:52 -0500

> bridge, based on what is in the base document today.

I agree... But I think the issue of how multicast traffic is handled in
PMIP6 will come up at sometime or another. It is better dealt with
separately "if" it does.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 17 Aug 2007 20:19:35 -0700 (PDT)

Hi Jonne,

> However, I still have some comments to your conclusion (just for the

Ok.

> you want at least in a cellular system), or it would have to implement

There is a shared access link and a shared MN-HNP prefix. I'm
referring to the shared access link ( a non p2p link).

On shared access link, the MAG is required to intercept the
packets sent by the mobile node. The MN will continue to send
the messages to the LMA's link-local/global address. Unless,
the MAG functions as a Proxy for the LMA, it wont receive these
messages. On a p2p link, this is not an issue.

If you are saying, MAG can potentially function as a bridge on
even on a shared link, then practically all the messages
from that access link will end up at the LMA. It is possible
there are visiting MN's from different LMA's. So, not sure,
if MAG can just operate as a bridge replicating every message
from the access link to the home.

I'm not saying proxy ND is complex, its just required, thats
all to it. IMO, specifically with the Per-MN-Prefix model, the
prefix conceptually follows the mobile, like a Mobile Network
Prefix in NEMO. So, it makes sense to host it on the access
link. I agree, if this is a shared prefix, the model can be
different.

> I don't think this is very important, though. Shared prefix model is not on

But, there is a very good chance work will happen on this, in
very near future.

> WG support. I don't know about the other words in the paragraph above... ;)

I thought you are totally convinced :) Ok. I'm fine with
your closing text. Both models can potentially work, but since
the current model has WG concensus, it is "The best" ! :)

Regards
Sri

---

From: "John.zhao" <[email-masked]>
Date: Mon, 20 Aug 2007 13:41:26 +0800

Hi , Sri

	I still think using LMA's link-local address didn't break SEND. That
is not 'break'. The SEND still can be used. It is still has some
disadvantage that we upload the MN's link-local address to LMA/network, we
just discussed in ML. For this reason, I didn't find the reasonable reason
to choose the MN's link-local address to resolve the collision problem
,except we must close this problem.
	My two cents.
	Best Rgds,
Thanks,
John.zhao

> >>> Although that was in the context of the design team protocol at the
time

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Mon, 20 Aug 2007 12:17:51 +0200

Hi,
 
a very interesting discussion, although I'm a bit confused by both the subject and the argumentation
I've not had the sufficient bandwidth in the past to participate in NETLMM, nor I think I will have it in the future, so I presume that the added value of my inputs is limited, but for what is worth ...
 
The MN-LMA link being a virtual link can be modelled as ptp or shared
The latter can only be achieved if ND is encapsulated all the way upto the LMA since it requires ProxyND in the LMA
The interest of such a solution is unclear to me and I guess out of scope
In general, the concept of ProxyND as I know it is applicable to the case when the same Prefix is advertised over multiple physical links, which is something discouraged by RFC4903
Note that I'm talking about ProxyND in the LMA, which is different than a ProxyND in the MAG. I'd rather not use the term ProxyND to refer to the MAG reverse tunneling ND 
 
To me, Jonne's proposal doesn't imply a different model, it just challenges the need for prefix delegation
To my knowledge the fundamental charateristic of a PMIP solution is that the HNP is ubiquitous, i.e. available to the MN whichever the point of attachment
Consequently the MN sees always (at least) one HNP. Potentially the MN may see one or more LNPs (Local Network Prefix) as well
The HoA falls into an HNP which in turn belongs to an LMA. Consequently, I'd say that all HoA traffic will be routed by the LMA (unless triangular routing)
The MAG may own 1 or more LNPs and consequently will play the router role for LoA (Local Address) traffic
What the CoA traffic concerns (CoA not visible to MN in PMIP), the MAG is a host and most likely a router as well
But for HoA traffic, I can't see the MAG playing any other role than as a tunnel entry point. For instance, would the MAG decrement the hop count of an HoA packet?
 
Whether the HNP is available to the MN as result of prefix delegation or not will determine whether ND needs to be terminated by the MAG or tunneled back to the LMA, but I don't think it makes a difference in the routing architecture
Intuitively, I find prefix delegation a more optimal solution, not so much because of the load on the MAG-LMA link but because of the potential optimizations to network entry
 
I understand that the original problem statement addressed in this thread was the need for DAD after HO as result of MAGs having different addresses
Well, it would make sense to me if when delegating the HNP, the LMA would also delegate an associated IP@ to source the RA from
That would allow the MN to always see the HNP coming from the same "virtual" AR
Implementation wise, this would mean that the MAG should be capable of terminating an IP interface for every HNP (therefore terminating ND)
I understand that this is the direction the discussion is heading to, although the conclusions are not yet clear to me
 
Further, I agree with Jonne that the behavior during HO should be clearly explained
My expectation is that the MN will see a change of physical link, but in the new link the HNP will still be available
In other words, it is implicit to the notion of HNP that it is persistent. This is not something that can be said of the LNP which by default should be considered as temporal
When considering use cases such as support of home-routed and visited-routed roaming traffic concurrently, it may be desirable to associate explicitly to Prefixes a persistent vs. temporal attribute. 
AFAIK, such atttribute doesn't exist today, so I wonder if it would make sense to discuss it in the context of NETLMM or rather in MIP6
 
Talking about HO, in my view it doesn't makes a difference whether the technology of the old and the new link is the same or not (out of scope?).
However, I would find it very interesting an analysis of how the MN will deal with make-before-break scenarios (intra-technology) as the HNP (and the LNP if persistent) will be available from 2 different links
 
Is DAD during NetEntry part of the discussion?
I'm not sure if there's consensus on the conditions that require DAD. According to me, DAD is necessary if the Prefix is shared
Unfortunately, to my knowledge, there are no means to indicate to the host whether the Prefix is shared or individual and consequently there need to be assumptions made on the type of link
In my opinion, it would be best to have an explicit "shared vs. individual" attribute associated to Prefixes, so that there's no need for dependencies with the link model
When the Prefix is individual, DAD could be optimized away. Today, I guess DAD can only be optimized away if the link model is ptp, but it's unclear to me how can the MN tell
 
I have one question for my education: is traffic using a link-local source@ supposed to be routed out of the link?
If not, then it's not clear to me what's the added value of link-local addresses when the link model is ptp; maybe for backwards compatibility?
 
Hope it's useful
Regards
 
federico
 
________________________________

De: Sri Gundavelli [mailto:[email-masked]]
Date: sam. 18/08/2007 05:19
À: Soininen Jonne (NSN FI/Espoo)
Cc: [email-masked]
Objet : Re: [netlmm] Issue: Link-local address collision on the access link

Hi Jonne,

Ok.

Regards
Sri

---

From: Julien Laganier <[email-masked]>
Date: Mon, 20 Aug 2007 13:34:51 +0200

Hi Jonne,

On Wednesday 15 August 2007, Jonne Soininen wrote:
>
> Julien Laganier wrote:
> >
> > More seriously: If we want the LMA to be the
> > default router we either need:
> >
> The tunnel between MAG and LMA is already an
> "L2-tunnel" in a way. It is an IP in IP tunnel,
> which is invisible for the end-host. There is no

The tunnel between MAG and LMA isn't an L2 tunnel since 
it doesn't carry L2 frames. It is an L3 tunnel 
carrying IP packets.

I was referring to MAG-LMA tunneling of full L2 frames 
exchanged between LMA and MN. That would be one way to 
have the LMA be the default router for the MN since 
the MN would see the LMA as the endpoint of the 
pt-2-pt link.  

In this solution the link between MN and MAG is 
extended up to the LMA through L2 tunneling.

This has issues when multiple L2 technologies in a 
domain since the LMA's link layer address embedded in 
RAs and NAs would need to be match the L2 in use by 
the MN, while remaining constant over time. That's 
contradictory.

> > specify the behavior of that IP layer bridge, how
> > that operate.
>
> The MAG just forwards everything coming from access
> to the appropriate tunnel and vice versa. There is
> not too much to specify there... (OK, I'm a bit
> simplifying it here...)

In that case (and I think that's the simplification 
that you're referring to) the MAG is "forwarding" 
packets based on the L3 destination address (to the 
appropriate LMA for packets coming from MN, and vice 
versa).

But we want the LMA to be the default router, the MAG 
must not decrement Hop Limit on forwarded packets. 
Hence the MAG isn't a router but an 
IP-layer 'transparent bridge'. That is not specified 
yet and hence would need to be.

In this solution the link between MN and MAG is 
extended up to the LMA through L3 tunneling and L3 
bridging (I'm not using the term forwarding since it 
usually implies that Hop Limit is decremented).

In this solution the MAG emulates a virtual MN-to-LMA 
link trough L3 bridging. 

This also has issues when multiple L2 technologies in a 
domain since the LMA's link layer address embedded in 
RAs and NAs would need to be match the L2 in use by 
the MN, while remaining constant over time. That's 
contradictory.

> > 3- the MAG to be a ND proxy [RFC4389]. That has
> > problem with Secure Neighbor Discovery. That would
> > also be a downref since 4389 is experimental.
>
> The MAG does not have to be an ND proxy. As the MAG
> just forwards packets without processing them it
> would in a way work like a L2 bridge. ND proxy is
> definitely not needed.

Last solution is to use proxy ND, where two links are 
present (MN-MAG and MAG-LMA) and the MAG terminates 
both links and acts as an ND proxy and bridges 
packets. 

That has the advantage to hide L2 dissimilarities since 
ND traffic is proxied and can thus hide 
dissimilarities between multiple L2 technologies in a 
domain (LMA's link layer address embedded in RAs and 
NAs can be rewritten by MAG acting as an ND proxy.) 
This however doesn't work with SEND.

> > So I'd say that it is not so as easy as saying
> > "the LMA is the default router" since each of 1-3
> > above needs some work (And there's also quite some
> > work to do to have the WG reaching consensus on
> > choosing one of the solution above ;)
> >
> > It's good that you ask the question. I'd like to
> > hear other folks' opinions?
>
> Look, I don't have in any way strong feelings about
> this. Either way is ok for me. However, the
> trade-off in my opinion, which is more difficult and
> wastes more resources: Doing DAD on every handover
> or making sure the MAG and the host addresses never
> collide, or to define LMA as the default router. I'm
> sure both sides have pros and cons. Though, I didn't
> want to start any project now deeply analyze these,
> I just wanted to raise awareness about the fact that
> the architecture of PMIP in this regard can be
> changed if the current architecture seems difficult
> to realize...

As I tried to point out above, I think that making the 
LMA a default router raises big architectural issues 
from the point of view of L2-agnosticism, or security 
(SEND).

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 20 Aug 2007 13:59:23 +0200

Hi Jean-Michel,

On Friday 17 August 2007, Jean-Michel Combes wrote:
> I support option #3 (i.e. all the MAG in a NetLMM
> have the same ingress LLA). The only issue I see
> with this option is about the use of SEND ... but
> this is not a PMIPv6 specific issue: we have already
> it with the use of SEND with anycast addresses (i.e.
> many nodes having the same IP address).

Well, it's not because there's already an issue that 
it's okay to create another one :) I support option #2 
which has no issue (just need to add the link-local 
address of the MN in the pBU which is sent anyway!)

Further, the issue with anycast is different; an 
anycast address is either on-link or off-link:

If it is off-link, ND is not used to resolve it 
(packets sent to it are instead sent to a router which 
knows how to reach the address via use of a routing 
protocol). 

If it is on-link then ND is involved in resolution and 
there might be an issue with SEND. However, AFAIK the 
only cases where an anycast address needs to be 
on-link are Subnet-Router anycast address and Reserved 
IPv6 Subnet Anycast Addresses, both of which are not 
CGAs, and are thus not subject to SEND protection.

Best,

--julien

> > The issue is related to establishing the
> > link-local address uniqueness on the access link
> > and when DNAv6 is enabled on the mobile node.
> >
> > the possibility of a link-local address collision
> > on a point-to-point link and between the MAG and
> > the MN. But, for the sake of completeness we need
> > to do some thing here. There is higher probability
> > for the network going down due to million other
> > reasons as supposed to due to link-local address
> > collision on a p2p link.
> >
> > node to do DAD operation on demand. DAD is
> > designed with the fixed view of the network. A
> > node joining a LAN will do a DAD and enter the
> > game and after that only the new nodes joining
> > modifies this view slightly. A mobile node in the
> > NETLMM domain always thinks its still on the same
> > link, but, it has a new neighbor after each
> > handoff. Interstingly, DNAv6 makes it worse by
> > DNASameLinkDADFlag to TRUE and that will force the
> > mobile node to redo DAD operation every time the
> > interface comes up, even when DNAv6 stack on the
> > mobile node does not detect a link change .
> >
> >
> > 4. MAG should always do a DAD when ever it detects
> > a new mobile node on its access link.
> >
> >

---

From: Julien Laganier <[email-masked]>
Date: Mon, 20 Aug 2007 14:08:32 +0200

Hi Jonne,

Some more commnets to your reply below:

On Friday 17 August 2007, Soininen Jonne (NSN FI/Espoo) 
wrote:
> Hi Sri,
>
> If the WG is happy with MAG being a router, I'm
> happy. I'm not sure I even proposed to change
> anything. I just wanted to understand the background
> as there are tradeoffs.
>
> However, I still have some comments to your
> conclusion (just for the record).
>
> > the local breakout, Route Optimization, Support
> > for shared access link ...etc.
> >
> > - Keeps the ND messages to the access link. If
> > there are 100'00 mobile nodes in a PMIP6 domain,
> > each MN is on a unique link and the RA/RS messages
> > need not have to be moved to the home network. So,
> > this is some saving.
>
> > - Does not require Proxy ND operation by the MAG
> > for supporting shared access link (not the shared
> > prefix, shared link with multiple nodes), for
> > future extensions.
>
> I think this statement is not correct. Or at least
> it depends on what you mean by shared prefix.
>
> If you would have (which we are not having) MAG as a
> bridge, the MAG would need no special handling for
> ND. It would just forward them to the LMA. The LMA
> would have to have a way of handling NDs. Either it
> would just broadcast the NDs to the other hosts
> under the same prefix (usually this is not what you
> want at least in a cellular system), or it would
> have to implement proxyND.

It do not agree that the MAG "need no special handling 
for ND". ND messages may embeds link-layer addresses, 
and these needs to be rewritten while crossing the 
link. Otherwise (if they're no rewritten), and the MN 
tries to use one of the LMA's link layer address to 
send a packet to the LMA, that might no be received by 
the MAG, depending on how the link layer delivers L2 
frames. I don't think we should assume anything on the 
L2 beyond the fact that it is pt-2-pt (that is already 
quite an assumption).

> In the case MAG is the router, it would have to
> implement proxyND and there would be a lot of extra
> complexity in addition to the proxyND: If (which
> would be logical) not all of the nodes that have the
> same prefix would be under the same MAG, the MAG
> would have to know somehow what are the other nodes
> using the same prefix. The only one who knows this
> is the LMA. I'm not quite sure how this would work.

I don't understand the point you're trying to make 
here. In my understanding the only difference between 
an IP layer bridge and a router is that the latter 
decrements the Hop Limit while the former doesn't.

Best,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 22 Aug 2007 08:02:51 -0700 (PDT)

Please comment on these open issues. So far, only
very few people commented on these issues. Please
express your preference for one of the suggested
options on each of these issues.

1. Visitor List vs Binding Update List
2. Link-local address uniqueness
3. Should MAG be allowed to a send a prefix hint
    to the LMA (Issue: 165 & 155)

We need to close these issues this week. We want
to make sure, there are no open issues when we
publish -02 version of the draft next week.

Regards
Sri

---

From: Julien Laganier <[email-masked]>
Date: Wed, 22 Aug 2007 17:23:31 +0200

>     to the LMA (Issue: 165 & 155)

I think it is better to allow it, and doesn't badly impact those that 
don't think it's useful since the LMA can simply disregard the 
information.

--julien