Subject: Re: How does "per-MN prefix model" simplify things? (was: RE: [netlmm] Re: PMIP follow-up questions)

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 1 Nov 2006 07:39:04 -0800 (PST)

Alex, per-MN prefix is something you need to use in order to avoid the multilink subnet issues Dave Thaler described in draft-iab-multilink-subnet-issues. Sri said it simplies things when MN is assigned a per-MN prefix at the home link for PMIPv6 which is one of the examples Dave gives in the draft.
per-MN prefix 
model IS actually needed (for both PMIPv6 and netlmm).

--behcet

----- Original Message ----
From: Alexandru Petrescu <[email-masked]>
To: Sri Gundavelli <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>; [email-masked]; "Soliman, Hesham" <[email-masked]>; Basavaraj Patil <[email-masked]>
Sent: Wednesday, November 1, 2006 8:10:37 AM
Subject: Re: How does "per-MN prefix model" simplify things? (was: RE: [netlmm] Re: PMIP follow-up questions)

Hi Sri,

I will continue the discussion - partly to not leave questions unreplied 
and partly  maybe helping determine how the per-MN prefix model is 
solving things.  My background intention is to show that per-MN prefix 
model is not actually needed.  This is something I've posted several 
times, I may need to stop.

And, if there are protocols to be modified to support sharing a /64
prefix among several point-to-point mobiles, then these are ND and DHCP.

Sri Gundavelli wrote:
> 
> 
> On Tue, 31 Oct 2006, Alexandru Petrescu wrote:
> 
>> 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.
>>>>>> 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.
>> 
>> The RA could say 'M'=1, i.e. don't use stateless and use DHCP.
> 
> 
> Sure. If that's restriction is ok.

Yes, although I don't see why naming it a restriction.  Do you think it
is a restriction to prefer DHCP instead of stateless autoconf, it seems.

>>> 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.
> 
> Will the DHCP server cache that lease for ever ? I just wrote the 
> issue I see reply to Fred's email.

In one current manual configurations the MAC address is hard-written in
server's configuration file, not in the lease files - I thought about
that.  It's not about lease.  The MAC-IP relation is fixed forever.

>>> 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.
>> 
>> Sorry, what's the giaddr field?  Can't find it in DHCPv6 rfc3315?
>> 
>> MN sets giaddr?  Or Server sets it?
>> 
> 
> 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 ....

Somehow yes, I also see a potential DHCP issue here.   The DHCP issue is
that it allocates an address necessarily part of Relay's prefix; or, we
want the address to be allocated from the home subnet prefix instead.

I still don't know what the giaddr field is.  I do know however that
Relay's prefix must be part of any allocation to a MN under that Relay.
  That's written in DHCP Server's file: if Server receives a Request from
a Relay it will check its preconfig table find the prefix of that Relay
and allocate an address in that space.  Not sure where giaddr fits in
this picture.

However, I think a Server implementation will be able to allocate a /128
that is not necessarily correspondent to that Relay's prefix, but
corresponds to the MN's MAC address.  Maybe this requires modifs to DHCP
spec - I don't know.  In addition to allocating an address out of the
Relay's prefix, the address should also be added in Relay's routing
table.  This is where a netlmm-like protocol can help.

Alex

_______________________________________________
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: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Nov 2006 17:32:47 +0100

Behcet Sarikaya wrote:
> Alex, per-MN prefix is something you need to use in order to avoid 
> the multilink subnet issues Dave Thaler described in 
> draft-iab-multilink-subnet-issues.

I'm wondering whether these recommendations are for link-layer designers
or for network-layer designers.

The draft doesn't say per-mobile-prefix is needed when using
point-to-point links.

The draft says that _if_ moving from a multilink subnet model to a 
better model one should use prefix-per-link, or improve ND multicast etc.

Now, MIP6 may be qualified as multilink subnet model (debatable IMHO).

But moving a /128 around a lmm is not a multilink subnet model at all.
It may be qualified as a host route (with inefficiency, route churning).
  But even then, these inefficiencies are present in a per-mobile-prefix
model too.

> Sri said it simplies things when MN is assigned a per-MN prefix at
> the home link for PMIPv6 which is one of the examples Dave gives in
> the draft. per-MN prefix model IS actually needed (for both PMIPv6
> and netlmm).

Maybe we can summarize somewhere why we need it.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Nov 2006 09:08:04 -0800

> Alex, per-MN prefix is something you need to use in
> order to avoid the multilink subnet issues Dave Thaler
> described in draft-iab-multilink-subnet-issues.

Yes, per-MN is one way to avoid multilink subnet. A second
way is to assign no prefixes at all on the access link and
just use link-local with prefix delegation for assignment
on downstream links. A third way is shared prefix with
'L' bit set to 0.

> Sri said it simplies things when MN is assigned a
> per-MN prefix at the home link for PMIPv6 which is one
> of the examples Dave gives in the draft.

I think Sri and I agreed that the only thing that seems
to be of issue is proxy/relay-DAD.

> per-MN prefix  model IS actually needed (for both PMIPv6
> and netlmm).

See above; it is not the only way.

Fred
[email-masked]
 
--behcet

----- Original Message ----
From: Alexandru Petrescu <[email-masked]>
To: Sri Gundavelli <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>; [email-masked];
"Soliman, Hesham" <[email-masked]>; Basavaraj Patil
<[email-masked]>
Sent: Wednesday, November 1, 2006 8:10:37 AM
Subject: Re: How does "per-MN prefix model" simplify things? (was: RE:
[netlmm] Re: PMIP follow-up questions)

Hi Sri,

  That's written in DHCP Server's file: if Server receives a Request
from

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Nov 2006 18:33:51 +0100

> to be of issue is proxy/relay-DAD.

I dont think one needs to DAD an address (1) acquired by DHCP and (2) 
valid on a point-to-point link behind a router - there can't be any 
duplicate in this space.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Nov 2006 09:40:48 -0800

> I dont think one needs to DAD an address (1) acquired
> by DHCP and (2) valid on a point-to-point link behind
> a router - there can't be any duplicate in this space.

Not quite; if all nodes use DHCP then there is no problem
but if some nodes use SLAAC and others use DHCP then you
still need DAD. DAD is also needed to check link-locals for
uniqueness before DHCP is run - unless we want to consider
having link-locals registered with the DHCP server instead
of doing DAD? Idea there is:

  1) MN creates tentative link-local
  2) MN issues Solicit with tentative link-local in an IA_NA
     option
  3) DHCP server replies that it is OK to use the tentative
  4) MN assigns the link-local to the interface

Again though, this only works if all nodes use DHCP...

Fred

---

From: "James Kempf" <[email-masked]>
Date: Wed, 1 Nov 2006 13:02:30 -0800

Fred/Sri,

So I take it from this that in order to maintain shared link semantics for 
link locals the PMIP would also need to do proxy/relay DAD too?

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Behcet Sarikaya" <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 01, 2006 9:08 AM
Subject: RE: How does "per-MN prefix model" simplify things? (was: 
RE:[netlmm]Re: PMIP follow-up questions)

Fred

--behcet

----- Original Message ----
From: Alexandru Petrescu <[email-masked]>
To: Sri Gundavelli <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>; [email-masked];

Hi Sri,

Alex

---

From: "James Kempf" <[email-masked]>
Date: Wed, 1 Nov 2006 13:04:40 -0800

No, actually, it must be DADed per 2641 (and bis) but the expectation is 
that there will be no response.

            jak

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Nov 2006 13:09:06 -0800

Hi James,

> So I take it from this that in order to maintain shared
> link semantics for  link locals the PMIP would also need
> to do proxy/relay DAD too?

My understanding about shared links sematics for access links
is that the considerations are independent of the particular
protocol that is run in the backhaul network. So, the
proxy/relay DAD would be needed for PMIP too if shared links
*and* SEND/CGA were to be supported. (Maybe there is some other
way to avoid address duplication for SEND/CGA on shared links
w/o proxy/relay DAD, but I haven't found it yet.)

You mentioned a while back that there were some discussions
involving IAB and/or IESG members that indicated there might
be some barrier to acceptance of a proxy/relay DAD solution.
Can you say anything more about that?

Thanks - Fred

---

From: "James Kempf" <[email-masked]>
Date: Wed, 1 Nov 2006 13:50:05 -0800

>Can you say anything more about that?

Primarily DaveT's multi-link subnet draft. I think it would be prudent to 
discuss the issue with him before the WG makes a decision. Also, I think we 
should check with Jari to find out what he thinks. It is necessary that Jari 
agree with anything the WG comes up with if we are to get IESG approval.

            jak

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Nov 2006 13:57:57 -0800

> Primarily DaveT's multi-link subnet draft.

OK.

> I think it would
> be prudent to  discuss the issue with him before the WG makes
> a decision. Also, I think we should check with Jari to find
> out what he thinks. It is necessary that Jari agree with
> anything the WG comes up with if we are to get IESG approval.

I sent a message out to Dave a while back, and I asked Jari
for his comments on this list and the Autoconf list, but so
far no further information.

I realize people are be busy and will likely be even busier
still at the meeting, so is it possible we could have some
discussion about this here on the list now?

Thanks - Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 1 Nov 2006 14:35:37 -0800 (PST)

> link locals the PMIP would also need to do proxy/relay DAD too?

Not required if pmip chooses per-mn-prefix model. The prefix will
be hosted on the access link for this case.

Sri

>           jak
>
> ----- Original Message ----- From: "Templin, Fred L" 
> <[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Nov 2006 14:38:36 -0800

> Not required if pmip chooses per-mn-prefix model.
> The prefix will be hosted on the access link for
> this case.

Not required for non-link-locals but still required
for link-locals if you want to preserve shared-link
semantics (which I do).

The main thing is that this is no different for PMIP
than for NETLMM/DT or NETLMM/DHCP, and I think James
got to the point that this is a bigger-picture issue.

Thanks - Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 1 Nov 2006 14:44:52 -0800 (PST)

> for link-locals if you want to preserve shared-link

Sure. If the shared-link assumption is a must ...

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 1 Nov 2006 14:59:57 -0800

> Sure. If the shared-link assumption is a must ...

And why wouldn't it be? On many media types, it is good
to have neighbors on the link other than the provider's
router. Are you suggesting that on all media types we
should slap blinders on the MNs so that they will only
ever see the provider's router and never talk to their
neighbors that might be right next door?

In good neighborhoods, neighbors *talk to each other*
even though they might not dress alike, act alike or
think alike. Take that away, and you are impinging on
some basic freedoms.

Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 1 Nov 2006 15:03:05 -0800 (PST)

Hi Fred,

> for link-locals if you want to preserve shared-link

Sorry ...one step back...

I'm not sure, why I would need to do proxy or relay
dad on the access link.

1. The RA's have to be unicasted. Each MN has to see
its own home prefix. We discussed about unicasting the
RA's to each MN.

2. For DAD, the identifiers that is used in LLA, 
the MN must do the DAD on that access link.
Not sure, why I would need to do relay dad ?  It
can certainly communicate with all the nodes on that
link and resolve that. Where is the need for proxy DAD ?

Sri

---

From: "James Kempf" <[email-masked]>
Date: Wed, 1 Nov 2006 22:40:47 -0800

Fred,

We're talking about machines here not people. Please try to keep some 
perspective. Thanx.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Behcet Sarikaya" 
<[email-masked]>; "Alexandru Petrescu" <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, November 01, 2006 2:59 PM
Subject: RE: How does "per-MN prefix model" simplify things? 
(was:RE:[netlmm]Re:PMIP follow-up questions)

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Nov 2006 08:40:16 -0800

James,

I am giving an analogy that is appropriate to the scenario
of multiple machines attached to the same shared media in
response to a provocative post. Maybe *you* try to not take
things too literally.

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Wednesday, November 01, 2006 10:41 PM
To: Templin, Fred L; Sri Gundavelli
Cc: Behcet Sarikaya; Alexandru Petrescu; [email-masked]
Subject: Re: How does "per-MN prefix model" simplify things?

Fred,

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Behcet Sarikaya" 
<[email-masked]>; "Alexandru Petrescu"
<[email-masked]>; 
<[email-masked]>
Sent: Wednesday, November 01, 2006 2:59 PM
Subject: RE: How does "per-MN prefix model" simplify things? 
(was:RE:[netlmm]Re:PMIP follow-up questions)

Fred