Subject: Re: Why is PMIP a superior solution for NETLMM requireiments?(was: Re: [netlmm] Network-based mobility - NETLMM DT SolutionVsAsolutionbased on MIP6)

From: Jean-Mickael Guerin <[email-masked]>
Date: Tue, 31 Oct 2006 08:57:36 +0100

Templin, Fred L wrote:
> Having glanced through 'draft-sgundave-mip6-proxymip6',
> I'll ask the obvious question: isn't it true that the PMIP
> proposals (or, at least the sgundave proposal) are about
> maintaining a stable *home* address while the NETLMM/DT and
> NETLMM/DHCP proposals are about maintaing stable *regional*
> addresses? If so, then is it possible that the two solutions
> are complementary rather than one vs. the other?
>
I think the point is PMIP could be used for maintaining stable
"regional" addresses. For instance, if this draft makes optional
the procedures to get mobile NAI, to look for Home Agent per mobile,
and if it allows preconfigured HA address and same IP subnet on
each "PMIP" router, then it can be a solution for netlmm with
home address = regional address.
(The draft should also relax the constraint "one distinct IP link per 
mobile").

Jean-Mickael
> For my application, the stable regional address is probably
> going to best satisfy the majority expected use cases since
> traffic won't have to flow through a (possibly) distant home
> agent. But it seems like other applications could benefit
> from a stable home address since it would give the MN
> something stable to put into the global DNS whereas a stable
> regional address alone might not. So from that standpoint,
> I guess the question is whether the MN should participate
> in the global mobility signaling or whether it is OK for a
> proxy in the network to do that?
>
> Thanks - Fred
> [email-masked]
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
>
>

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Oct 2006 07:29:29 -0800

I didn't expect this much follow-up, and I don't want to
perpetuate it. But, I need clarification on the following

> home address = regional address.

I don't get this. The way I understood the draft, it says
that the MN gets a home address from a prefix that follows
the MN around wherever it goes, and traffic for the MN flows
through the home agent in the MN's home network; right? So,
how could that be a regional address if everything goes thru
the home network? Or maybe the "home agent" for PMIP is
actually local to the localized mobility management domain? 

> (The draft should also relax the constraint "one distinct IP link per 

I'll go along with that, but I cringe whenever I see the
term: "IP link" which AFAICT means the same thing as the
ubiquitous term "link". Where did "IP link" come from?
And, why do we need it?

Thanks - Fred

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Tue, 31 Oct 2006 17:20:44 +0100

> actually local to the localized mobility management domain? 
Yes, just my view on using PMIP for netlmm -  LMA acting as Home Agent,
and  same "home" network prefix advertised by MAG acting as PMIP
router so that whatever MAG the mobile connects to it will remain
in same subnet.

> ubiquitous term "link". Where did "IP link" come from?
My mistake, sorry. I thought "IP subnet", but I'm afraid to be
wrong again. The idea is from section 7.3 of this draft,
quoted here:
"
   the prefix that is advertised on this shared link is specific to that
   mobile station and no other node will be on this link.
"

Jean-Mickael

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Oct 2006 08:26:56 -0800

> router so that whatever MAG the mobile connects to it will remain

OK, I think I get it now. Then, I guess in a nutshell this
whole thing is just about two flavors of UDP messaging vs.
mobility header? So between NETLMM/DT, NETLMM/DHCP and PMIP
IMHO it seems like we are just splitting hairs here...

Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Oct 2006 17:55:30 +0100

> router so that whatever MAG the mobile connects to it will remain

The potentially inferior aspect of this aspect is that assumes 
prefix-per-mobile, which is something that should not be recommended, 
because it usually leads to address waste.

I wonder whether netlmm DT protocol supports both prefix-per-mobile and 
/128-per-mobile and whether PMIP proposal too.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 09:03:53 -0800 (PST)

On Tue, 31 Oct 2006, Alexandru Petrescu wrote:

> prefix-per-mobile, which is something that should not be recommended, because 
> it usually leads to address waste.
>

We want to be flexible with the address allocation models.
It is possible, there is only /128 address-per-mobile or a
prefix per mobile. We want to support both the schemes.
However, per-MN prefix model simplifies lot of things. Home
agent can just create a routing state for that prefix over the
HA-PMA tunnel and be done with it. For certain closed deplyments,
this might make sense.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Oct 2006 18:12:01 +0100

Sri Gundavelli wrote:
>>>>> "regional" addresses. For instance, if this draft makes
>>>>> optional the procedures to get mobile NAI, to look for Home
>>>>> Agent per
>>> mobile,
>>>>> and if it allows preconfigured HA address and same IP subnet
>>>>> on each "PMIP" router, then it can be a solution for netlmm
>>>>> with home address = regional address. I don't get this. The
>>>>> way I understood the draft, it says
>>>> that the MN gets a home address from a prefix that follows the
>>>> MN around wherever it goes, and traffic for the MN flows 
>>>> through the home agent in the MN's home network; right? So, how
>>>> could that be a regional address if everything goes thru the
>>>> home network? Or maybe the "home agent" for PMIP is actually
>>>> local to the localized mobility management domain?
>>> 
>>> Yes, just my view on using PMIP for netlmm -  LMA acting as Home
>>> Agent, and  same "home" network prefix advertised by MAG acting
>>> as PMIP router so that whatever MAG the mobile connects to it
>>> will remain in same subnet.
>> 
>> prefix-per-mobile, which is something that should not be
>> recommended, because it usually leads to address waste.
>> 
>> I wonder whether netlmm DT protocol supports both prefix-per-mobile
>>  and /128-per-mobile and whether PMIP proposal too.
>> 
> 
> We want to be flexible with the address allocation models. It is
> possible, there is only /128 address-per-mobile or a prefix per
> mobile. We want to support both the schemes.

I guess that if MIPv6 is to be extended to move a prefix around then it
should involve the NEMOv6 community as well, maybe mention it as PNEMOv6
in the NEMO WG, which is about to be re-chartered.

> However, per-MN prefix model simplifies lot of things. Home agent can
> just create a routing state for that prefix over the HA-PMA tunnel
> and be done with it. For certain closed deplyments, this might make
> sense.

I agree with this too.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Oct 2006 09:36:16 -0800

> However, per-MN prefix model simplifies lot of things.

We have seen the assertion "per-MN prefix model simplifies
(a) lot of things" mentioned many times, but so far I have
not seen the issues enumerated. I know about the requirement
for domain-wide proxy-DAD for the shared prefix/shared link
model, but that's all I know about.

If there is a commonly-held belief that the per-MN prefix
model simplifies "a lot of things" (and not just one thing),
then someone should step up and enumerate the issues here
on the list.

Thanks - Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 09:54:34 -0800 (PST)

> [email-masked]

Per-MN prefix relieves the home agent from dealing with
any of the issues related to the node communication with
link specific scope. The home agent will end up being
the topological anchor point for that prefix, but it will
not host that prefix on its link.

The home agent can just create a routing state for the prefix
say cafe, just as in NEMO.

tunnel 0: haa <----> pma
cafe::/64 over tunnel 0

If the prefix is a shared prefix across many nodes, and
some of the nodes are currently attached to different
links, being serviced by many proxy mobile agents, for
DAD or other link specific communication, the home agent
needs to be involved one way or the other. The same home
network prefix needs to be advertised on multiple network
links and that appears bit odd.

When the mobile is using DHCP addressing scheme, the network
needs to ensure the MN gets the same address from its prefix,
as it moves across the PMIP domain. In the per-mn-prefix
model, the PMA can simply act as a DHCP relay agent, setting
the giaddr value to any address from the mobile's home prefix.
The routing over the tunnel will ensure, the DHCP reply
will get routed correctly. In the one-address-per-MN model
this might become bit tricky. I'm sure, you know more issues
on this than me.

In general, atleast from the implementation point of view,
the home agent need not deal with lot of special cases. If
you look at the NEMO implementation, the HA is not required
to implement too much of logic for MNP's. This is just the
same way.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 31 Oct 2006 10:13:51 -0800

> IMHO it seems like we are just splitting hairs here...

Yep :) As much as we would all like to see more differences, that is
what it is!! That is the reason I started that comparison on the
advantages of using MH vs. UDP. 

Vidya

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Oct 2006 19:31:19 +0100

Sri Gundavelli wrote:
>> We have seen the assertion "per-MN prefix model simplifies (a) lot
>>  of things" mentioned many times, but so far I have not seen the 
>> issues enumerated. I know about the requirement for domain-wide 
>> proxy-DAD for the shared prefix/shared link model, but that's all I
>>  know about.
>> 
>> If there is a commonly-held belief that the per-MN prefix model 
>> simplifies "a lot of things" (and not just one thing), then someone
>>  should step up and enumerate the issues here on the list.
>> 
>> Thanks - Fred [email-masked]
>> 
> 
> Per-MN prefix relieves the home agent from dealing with any of the 
> issues related to the node communication with link specific scope. 
> The home agent will end up being the topological anchor point for 
> that prefix, but it will not host that prefix on its link.
> 
> The home agent can just create a routing state for the prefix say 
> cafe, just as in NEMO.

Nein :-) simplest NEMO implementations (implicit mode) don't add/remove
prefixes in routing tables, just modify the lookup order.

As a side note, NEMO WG has an informational draft which in some cases
recommends mixing the home link prefix into the mobile link prefix with
a sort of bridge in between - leading to a Home Address derived from the
mobile link prefix - derivation being recently little appreciated by
some testing organization.

> tunnel 0: haa <----> pma cafe::/64 over tunnel 0
> 
> If the prefix is a shared prefix across many nodes, and some of the 
> nodes are currently attached to different links, being serviced by 
> many proxy mobile agents, for DAD or other link specific 
> communication, the home agent needs to be involved one way or the 
> other. The same home network prefix needs to be advertised on 
> multiple network links and that appears bit odd.

Ok, got the problem, so how about advertising a full /128 (not a prefix
in RA, but a /128 sent by a DHCP Server instead).  There wouldn't be
this issue of advertising same prefix at different ARs.

> When the mobile is using DHCP addressing scheme, the network needs to
>  ensure the MN gets the same address from its prefix,

'same' - NAI or MAC address, no issue.

> as it moves across the PMIP domain.

Yes, add the MN's /128 in the AR's routing table where the MN is.

> In the per-mn-prefix model, the PMA can simply act as a DHCP relay 
> agent, setting the giaddr value to any address from the mobile's home
>  prefix. The routing over the tunnel will ensure, the DHCP reply will
>  get routed correctly. In the one-address-per-MN model this might 
> become bit tricky. I'm sure, you know more issues on this than me.
> 
> In general, atleast from the implementation point of view, the home 
> agent need not deal with lot of special cases. If you look at the 
> NEMO implementation, the HA is not required to implement too much of
>  logic for MNP's. This is just the same way.

Exactly, in NEMO implicit mode, the HA and MR deal only with the MR's
/128 home address, not any prefix.  All prefixes are static in HA and
MR's routing tables, not dynamic.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 10:37:10 -0800 (PST)

Hi Jean,

> (The draft should also relax the constraint "one distinct IP link per 

This can probably be done with more input. Some how, the network
on the access link needs to ensure, each MN see's its own home
prefix. One way is to unicast the RA's and other minor techniques
to isolate the shared MN-AR communication from all other nodes.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Oct 2006 19:50:13 +0100

Sri Gundavelli wrote:
>>> Having glanced through 'draft-sgundave-mip6-proxymip6', I'll ask 
>>> the obvious question: isn't it true that the PMIP proposals (or, 
>>> at least the sgundave proposal) are about maintaining a stable 
>>> *home* address while the NETLMM/DT and NETLMM/DHCP proposals are 
>>> about maintaing stable *regional* addresses? If so, then is it 
>>> possible that the two solutions are complementary rather than one
>>>  vs. the other?
>>> 
>> the procedures to get mobile NAI, to look for Home Agent per 
>> mobile, and if it allows preconfigured HA address and same IP 
>> subnet on each "PMIP" router, then it can be a solution for netlmm 
>> with home address = regional address.
> 
>> (The draft should also relax the constraint "one distinct IP link 
>> per mobile").
> 
> 
> This can probably be done with more input. Some how, the network on 
> the access link needs to ensure, each MN see's its own home prefix. 
> One way is to unicast the RA's and other minor techniques to isolate 
> the shared MN-AR communication from all other nodes.

The problem is there: one MN's prefix shouldn't be seen by other MNs.

Unicasting the RA can't be done because AR doesn't know to what address.

What other 'minor' techniques?

One possible solution to this is DHCP and MN's /128 on AR.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 11:01:13 -0800 (PST)

On Tue, 31 Oct 2006, Alexandru Petrescu wrote:

>> >  of things" mentioned many times, but so far I have not seen the issues 
>> >  enumerated. I know about the requirement for domain-wide proxy-DAD for 
>> >  the shared prefix/shared link model, but that's all I
>> >   know about.
>> > 
>>  Per-MN prefix relieves the home agent from dealing with any of the issues
>>  related to the node communication with link specific scope. The home agent
>>  will end up being the topological anchor point for that prefix, but it
>>  will not host that prefix on its link.
>>
>>  The home agent can just create a routing state for the prefix say cafe,
>>  just as in NEMO.
>

Absolutely. We hated that part in our NEMO implementation...

>>  If the prefix is a shared prefix across many nodes, and some of the nodes
>>  are currently attached to different links, being serviced by many proxy
>>  mobile agents, for DAD or other link specific communication, the home
>>  agent needs to be involved one way or the other. The same home network
>>  prefix needs to be advertised on multiple network links and that appears
>>  bit odd.
>

>From the MN's view point, the access link is the home link.
If the MN is allowed for IPv6 auto configuration, it need to
see the RA with its home prefix. So, there needs to be an
RA with the home prefix, emulating the home link for making
the MN believe, its @home.

> 'same' - NAI or MAC address, no issue.

Identifier is not the issue. If the DHCP server has allocated
an address for a MN, for a subsequent request and before the
address lease expires, the server can certainly allocate the
same address to the MN. However, if the DHCP request comes
after the lease has expired, the DHCP server will not have
any means to allocate the same home address to the mobile.
In the per-MN prefix model, there is no other node that is
requesting a DHCP address from some other mobile's home prefix.

Also, the big question is the function of the proxy as a relay
agent. There needs to be an hint in the DHCP request that enables
the DHCP server to allocate an address from the MN's prefix. That
becomes tricky in the per-MN-address model. In the per-MN-prefix
model, giaddr can be set to any address from the MN's home prefix,
the server will allocate the address from the MN's prefix and
the reply will get routed back correctly.

Sri

>>  In the per-mn-prefix model, the PMA can simply act as a DHCP relay agent,
>>  setting the giaddr value to any address from the mobile's home
>>  In general, atleast from the implementation point of view, the home agent
>>  need not deal with lot of special cases. If you look at the NEMO
>>  implementation, the HA is not required to implement too much of

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 11:03:35 -0800 (PST)

On Tue, 31 Oct 2006, Alexandru Petrescu wrote:

>> > >  Having glanced through 'draft-sgundave-mip6-proxymip6', I'll ask the 
>> > >  obvious question: isn't it true that the PMIP proposals (or, at least 
>> > >  the sgundave proposal) are about maintaining a stable *home* address 
>> > >  while the NETLMM/DT and NETLMM/DHCP proposals are about maintaing 
>> > >  stable *regional* addresses? If so, then is it possible that the two 
>> > >  solutions are complementary rather than one
>> > >   vs. the other?
>> > > 
>> >  "regional" addresses. For instance, if this draft makes optional the 
>> >  procedures to get mobile NAI, to look for Home Agent per mobile, and if 
>> >  it allows preconfigured HA address and same IP subnet on each "PMIP" 
>> >  router, then it can be a solution for netlmm with home address = 
>> >  regional address.
>> 
>>  This can probably be done with more input. Some how, the network on the
>>  access link needs to ensure, each MN see's its own home prefix. One way is
>>  to unicast the RA's and other minor techniques to isolate the shared MN-AR
>>  communication from all other nodes.
>

One way is to set the L2 destination to the MN's MAC address.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Oct 2006 11:04:28 -0800

Hi Sri,

You seem to be coming at this from a PMIP viewpoint, so

> say cafe, just as in NEMO.

That's fine, but I don't see anything wrong with:
'café::1/128 over tunnel 0' either - do you?

> links and that appears bit odd.

It shouldn't be a problem as long as the prefix is advertised
with 'L'=0.

> this might become bit tricky. I'm sure, you know more issues

Its not any different for DHCP than for SLAAC; for DHCP,
the MAG is a relay whether prefix-per-MN or shared prefix.

> to implement too much of logic for MNP's. This is just the

I'm still not seeing "a lot of special cases", and I don't
see a reason for dragging NEMO into this - at least not at
this point.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Oct 2006 20:14:01 +0100

Sri Gundavelli wrote:
[...]
>> Ok, got the problem, so how about advertising a full /128 (not a 
>> prefix in RA, but a /128 sent by a DHCP Server instead).  There 
>> wouldn't be this issue of advertising same prefix at different ARs.
>> 
>> 
> If the MN is allowed for IPv6 auto configuration, it need to see the
>  RA with its home prefix.

The RA could say 'M'=1, i.e. don't use stateless and use DHCP.

> So, there needs to be an RA with the home prefix, emulating the home
>  link for making the MN believe, its @home.

Even if RA tells M=1 (by rfc2461) then no need to emulate home link.

> Identifier is not the issue. If the DHCP server has allocated an 
> address for a MN, for a subsequent request and before the address 
> lease expires, the server can certainly allocate the same address to
>  the MN. However, if the DHCP request comes after the lease has 
> expired, the DHCP server will not have any means to allocate the same
>  home address to the mobile.

Sorry, disagree, specifying MAC address will make DHCP Server never
allocate that to any other MN, only to MN in question.  Regardless of
lease expired, not expired.  I don't see the link lease expiration - MN
identity.

> In the per-MN prefix model, there is no other node that is requesting
>  a DHCP address from some other mobile's home prefix.

Provided the home link 'moves' with the mobile, indeed.

> Also, the big question is the function of the proxy as a relay agent.
>  There needs to be an hint in the DHCP request that enables the DHCP
>  server to allocate an address from the MN's prefix.

The MAC address is that hint.

> That becomes tricky in the per-MN-address model. In the per-MN-prefix
> the server will allocate the address from the MN's prefix and the 
> reply will get routed back correctly.

Sorry, what's the giaddr field?  Can't find it in DHCPv6 rfc3315?

MN sets giaddr?  Or Server sets it?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Oct 2006 20:16:01 +0100

Sri Gundavelli wrote:
>>> the > >  obvious question: isn't it true that the PMIP proposals (or, 
>>> at least > >  the sgundave proposal) are about maintaining a stable 
>>> *home* address > >  while the NETLMM/DT and NETLMM/DHCP proposals are 
>>> about maintaing > >  stable *regional* addresses? If so, then is it 
>>> possible that the two > >  solutions are complementary rather than one
>>> > >   vs. the other?
>>> the >  procedures to get mobile NAI, to look for Home Agent per 
>>> mobile, and if >  it allows preconfigured HA address and same IP 
>>> subnet on each "PMIP" >  router, then it can be a solution for netlmm 
>>> with home address = >  regional address.
>>>
>>> per >  mobile").

Who tells AR the MN MAC address?  Neighbour Discovery - no.  Other l2 
means?  Which other?  Which l2.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 11:50:13 -0800 (PST)

Hi Fred,

I'm not against supporting per-mn-address model. But, I see
few issues with it. Specifically, per-MN-prefix model is simple
when it comes to dealing with DAD and DHCP. Comments inline ..

> 'café::1/128 over tunnel 0' either - do you?

Fine.

> It shouldn't be a problem as long as the prefix is advertised

Sure. But, when the mobile does DAD for its home address,
the packets need to be routed back to the home link and
the home agent has to deal with this. It needs to look up
the binding cache to detect the duplicate identifiers
or forward the packet to all the roaming mobiles. There
needs to be some logic at the home agent for handling this.
In the per-MN-prefix model, the DAD is contained to the
access link.

> the MAG is a relay whether prefix-per-MN or shared prefix.

Ok. You and Alex seem to think there is no issue with the
DHCP scheme in the per-MN-address model. If so, I'm fine.
No arguments. But, I'm bit unclear as how the DHCP addressing
will work, with out requiring the proxy mobile agent have
some special logic to deal with it.

Assume the DHCP server is on the home link, AR is the DHCP relay.
The mobile boots up in the access link, sends a DHCP request,
the access router/PMA needs to give a hint to the DHCP server,
indicating the DHCP server to allocate an address from a
given prefix block. What will be that hint ? Is that MAC
address as Alex says ? How will the DHCP reply get routed
back to proxy correctly ? For me, in the per-MN-prefix model,
the proxy mobile agent or the AR is just a natural relay
agent and with out any other logic.

> see a reason for dragging NEMO into this - at least not at

Sure. I agree, we dont have to drag NEMO into this.
I thought NEMO is a good example to relate too.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 11:54:16 -0800 (PST)

> The RA could say 'M'=1, i.e. don't use stateless and use DHCP.

Sure. If that's restriction is ok.

>>  Identifier is not the issue. If the DHCP server has allocated an address
>>  for a MN, for a subsequent request and before the address lease expires,
>>  the server can certainly allocate the same address to
>>  the MN. However, if the DHCP request comes after the lease has expired,
>>  the DHCP server will not have any means to allocate the same

Will the DHCP server cache that lease for ever ? I just wrote the
issue I see reply to Fred's email.

>>  model, giaddr can be set to any address from the MN's home prefix, the
>>  server will allocate the address from the MN's prefix and the reply will
>>  get routed back correctly.
>

When a DHCP request goes across links, the relay on the
link can specify the prefix block from where the dhcp
server needs to assign an address. One of fields is
giaddr ....

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 12:04:21 -0800 (PST)

On Tue, 31 Oct 2006, Alexandru Petrescu wrote:

> Sri Gundavelli wrote:
>
> Who tells AR the MN MAC address?  Neighbour Discovery - no.  Other l2 means? 
> Which other?  Which l2.
>

Hi Alex,

The proxy mip signalling is triggered after the AR/PMA detect
the mobile on its link after the access authentication. It will
certainly know the MN's MAC address, as part of the access
authentication procedures or when the mobile does a router
solicitation.

Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Oct 2006 14:51:18 -0800

> In the per-MN-prefix model, the DAD is contained to the

This is what I meant when I said:

  "I know about the requirement for domain-wide proxy-DAD
  for the shared prefix/shared link model, but that's all
  I know about."

What I was asking was, given that we already know about
this one are there any other issues we need to be aware
of when you say "a lot of things"?

> some special logic to deal with it.

Not exactly what I said; I don't think there is any issue
with the DHCP scheme in either the per-MN or shared prefix
models.

> Assume the DHCP server is on the home link, AR is the DHCP relay.

I'm a bit confused now when you say "home link"; others
have said that PMIP is about having the "home agent"
co-resident with the LMA in the localized mobility
management domain and that it only deals in regional
addresses not real home addresses in the MIP6 sense.
So, the "home link" would essentially be associated
with the LMA, right? Is that not what is intended?
 
> address as Alex says ? 

Generally, I would expect that the MN gets an RA first
before sending the DHCP Solicit; otherwise, how does it
know whether DHCP is supported on the link? Then, when
it moves to a new AR, the MN can issue DHCPv6
Confirm/Rebind before getting an RA but by that time
it already has address/prefix delegations.

> How will the DHCP reply get routed back to proxy correctly ?

In exactly the usual way for normal DHCPv6 relays, as
specified in RFC3315.

> For me, in the per-MN-prefix model,

Again, is the concern only about proxy/relay-DAD or are
there other things as you seemed to imply?

Thanks - Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 17:00:27 -0800 (PST)

Hi Fred,

>  for the shared prefix/shared link model, but that's all

Ok. My original comment was that the implementation logic
for handling the per-MN-prefix model is simpler that
handling the per-MN-address model. Sure, this is one
of the reasons and may be this is the only issue, as you
pointed out.

> with the DHCP scheme in either the per-MN or shared prefix

Ok. What is the required DHCP server configuration for supporting
/128 bit lengths.

a.) Will there be that many prefixes or DHCP pools  (/128) as that
many nodes ? Is it possible to manage, by just creating one
large DHCP pool ? If so, will the relay agent set the giaddr
field to the MN's address ? When I look at the potential size
of the network, where this gets deployed, the number of mobiles
will be in the order of 500,000. So, I'm not sure what is the
DHCP address pool configuration. A /128 pool configuration appears
too much of provisioning.

b.) Does the relay agent set the giaddr field to the address
of the MN itself.

May be there is no issue at all. Thanks for your comments.

> with the LMA, right? Is that not what is intended?

In PMIP, there is a home agent and a proxy agent. The mobile is
anchored at the home agent, exactly as specified in 3775. The
function in mobile node for creating a binding is now in the
access router and that we call it as proxy mobile agent, as
it is sending signalling messages on behalf of the mobile. I'm
trying to relate this to pure MIPv6 as supposed to NETLMM
terms.

> it already has address/prefix delegations.

Sure. That's the call flow we have in our doc. RS followed
by RA and DHCP.

> [email-masked]

Thanks
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Oct 2006 17:12:29 -0800

> Ok. What is the required DHCP server configuration for supporting

The server just delegates addresses (/128s) per normal DHCPv6.

> b.) Does the relay agent set the giaddr field to the address

As Alex pointed out, 'giaddr' is not found in RFC3315 but
the answers as to how the DHCPv6 relay operates are.

> trying to relate this to pure MIPv6 as supposed to NETLMM

Yes, I am OK with the functional elements of PMIP but I
am still not 100% certain as to where the PMIP "home agent"
lives? Is it in the MN's actual home network which could be
far away, or is it co-resident with the LMA in the MN's
current localized mobility management domain? Some have
seemed to imply that it is the latter.

Thanks - Fred