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

From: Pekka Savola <[email-masked]>
Date: Wed, 1 Nov 2006 10:05:14 +0200 (EET)

On Tue, 31 Oct 2006, Templin, Fred L wrote:
> > 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.

You don't need to special-case the link-local traffic handling.  For 
example, link-local multicasts don't create problems at the router. If 
you don't see the benefits, you may be thinking that the router must 
act as a bridge (at least for certain kinds of packets) or simply drop 
link-local packets that go would go outside the link but are in the 
same "subnet".  If so, it is not clear how well that would scale to 
subnets with a large number of users.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 01 Nov 2006 15:10:37 +0100

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

---

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

Pekka,

> act as a bridge (at least for certain kinds of packets)

Right, and this reduces to exactly the proxy/relay-DAD
issue as I have been saying in my earlier messages. I
am still waiting to hear if there are any issues other
than this one and so far I haven't heard any.

> or simply drop 
> same "subnet".

I don't understand "link-local packets...in the same
"subnet"". As far as I can tell, link-local multicast
is independent of (subnet) prefixes assigned on the
link. 

> If so, it is not clear how well that would scale to 

I agree that it would be poor practice to flood the
link-local multicasts to the entire domain. But, there
is no need for that in the proxy/relay-DAD case; the
only links that need to be involved are the link on
which DAD is being run and the link on which the
duplicate address occurs. And, in most cases there
won't be any duplicate address and hence no nodes
on other links disturbed.

Thanks - Fred
[email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 1 Nov 2006 08:58:39 -0800 (PST)

Hi Alex,

On Wed, 1 Nov 2006, Alexandru Petrescu wrote:

> 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.
>

Sure. We certainly close the loop on this. Comments inline ...

>> > > > > > 
>> > >  If the MN is allowed for IPv6 auto configuration, it need to see the 
>> > >  RA with its home prefix.
>> > 

Stateless Addr configuration is one of the most important features of
IPv6 and keeping that feature in PMIP model is important. If you
look at MIPv4, the handoff latency in MN-CCOA mode is primarily
due to DHCP. The MN is waiting for a routable address from the DHCP
for few secs, in most cases ?

It is really an operator choice as what kind of addressing models
they like to permit on their network. IMHO, designing the protocol
for permitting all schemes is a good idea and to turn a given scheme
is the choice of the operator.

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

It is really implementation dependent. I dont think its kept for
ever. We need to check the specs.

I think we need to step back a bit on the assumed  configuration
when allocating /128 bit prefix/address to each mobile. Part of the
confusion is comming from the implicit assumptions. In the /128 bit
allocation model, an operator would allocate this fixed /128 bit
prefix/address to each mobile in the network. Now, when the mobile
boots up any where in the network and when using DHCP, it must obtain
the same address from the DHCP server, as that is configured in AAA
or some other policy store ? Is that a reasonable assumption ?

Now, I'm bit confused how you would ensure the mobile gets the same 
address as that is configured in AAA ? In the per-mn-prefix model,
the MN always gets the address from its own prefix block and is
the sole requestor and the address allocation scheme is predictable.

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

Its link-addr option. I'm sorry, I was using the DHCPv4 terms

>>  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 ....
>

As I pointed above, this comes back to the DHCP pool
configuration and the relation to the per-MN profile
in the AAA.

link-addr option is the hint and I think there is no
issue there, allocating an address from that pool. Now,
I dont know how that works with /128 bit pools.

Sri

---

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

Sri, thanks for the message.  You're pointing out important things, on
which I have oppinion, I can reply if that doesn't disturb.

Sri Gundavelli wrote:
>> 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.
>> 

Agreed.

>>>>>>>>>> If the MN is allowed for IPv6 auto configuration, 
>>>>>>>>>> it
>>> need to see the > >  RA with its home prefix.
>> 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.
>> 
> 
> look at MIPv4, the handoff latency in MN-CCOA mode is primarily due 
> to DHCP. The MN is waiting for a routable address from the DHCP for 
> few secs, in most cases ?

[Off-topic]

YEs, I completely agree MIP4 handovers over wifi are slow due to address
acquisition (and link-layer scanning, but out of discussion).

However, they are slow because too: (1) the MIP4 spec is very vague
about movement detection, not offering a clear interaction mechanism
with DHCP - implementers wonder how should they do.  MIP6 is clearer on
that.  (2) Most DHCPv4 implementations are not made to support
handovers, don't reply quickly, queue the replies etc.

Both DHCPv4 spec and MIP4 specs could be improved largely to give
quicker handovers.  FMIPv4 unfortunately doesn't really address the
issue of simple handovers, but of more sophisticated handovers.

[/off-topic]

It's not because MIP4 handovers are slow that stateless
autoconfiguration is a superior autoconfiguration means.  Handovers
based on RA can be slow too.

Mobiles need to support DHCPv6 because operator needs a centralized way
to manage addresses, which RA doesn't offer.

>  is the choice of the operator.

I agree.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 1 Nov 2006 09:17:48 -0800 (PST)

> which I have oppinion, I can reply if that doesn't disturb.

Sure. We should sync up.

>>  IPv6 and keeping that feature in PMIP model is important. If you look at
>>  MIPv4, the handoff latency in MN-CCOA mode is primarily due to DHCP. The
>>  MN is waiting for a routable address from the DHCP for few secs, in most
>>  cases ?
>
> [Off-topic]
>

I agree. These are contributing to the latency as well.

Thanks
Sri

---

From: Pekka Savola <[email-masked]>
Date: Wed, 1 Nov 2006 20:08:30 +0200 (EET)

On Wed, 1 Nov 2006, Templin, Fred L wrote:
> > or simply drop link-local packets that go would go outside the 
> > link but are in the same "subnet".
> 

This refers to the expectations of protocol designers and application 
writers.  If a host sends out link-local multicast packet with TTL=1, 
the application/protocol may expect that it'll in fact be delievered 
to other nodes in the 'subnet'.  This is the assumption of LLMNR, MDNS 
and such protocols.

One could possibly argue that there has been no such intent when 
protocols/apps that use link-local (multicast or unicast) addresses 
were designed, not supporting those in different links but the same 
subnet is OK. 

This is exactly what draft-iab-multilink-subnet-issues is about, see 
Section 2.

Is there something you disagree with in that draft?

---

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

> and such protocols.

"s/subnet/link" above and I could understand it.

> This is exactly what draft-iab-multilink-subnet-issues is about, see 

Yes, I have read it several times including the most
recent version.

> Is there something you disagree with in that draft?

No; I agree with the draft. With reference to the above,
Section 2.1 says:

   "Furthermore, a subnet is sometimes considered to 
    be only a subset of a link, when multiple subnets are
    assigned to the same link."

By my read of that text, that means that a link-scoped
multicast sent on a link could be received by interfaces
that do not configure the same prefixes as those assigned
to the sending interface.

In other words, subnet-scope <= link-scope.

Fred

---

From: Julien Laganier <[email-masked]>
Date: Sat, 4 Nov 2006 17:06:45 +0000

On Wednesday 01 November 2006 19:28, Templin, Fred L 
wrote:
> [...]
> No; I agree with the draft. With reference to the
> above, Section 2.1 says:
>
>     be only a subset of a link, when multiple
> subnets are assigned to the same link."
>
> By my read of that text, that means that a
> link-scoped multicast sent on a link could be
> received by interfaces that do not configure the
> same prefixes as those assigned to the sending
> interface.
>

+1

--julien

6 12:06:43 -0500
From: Julien Laganier <[email-masked]>
To: [email-masked]
Subject: Re: How does "per-MN prefix model" simplify things? (was:
	RE:[netlmm]Re: PMIP follow-up questions)
Date: Sat, 4 Nov 2006 17:06:45 +0000
Cc: "Templin, Fred L" <[email-masked]>

On Wednesday 01 November 2006 19:28, Templin, Fred L 
wrote:
> [...]
> No; I agree with the draft. With reference to the
> above, Section 2.1 says:
>
>     be only a subset of a link, when multiple
> subnets are assigned to the same link."
>
> By my read of that text, that means that a
> link-scoped multicast sent on a link could be
> received by interfaces that do not configure the
> same prefixes as those assigned to the sending
> interface.
>

+1

--julien

---

From: Pekka Savola <[email-masked]>
Date: Sat, 4 Nov 2006 20:23:15 +0200 (EET)

> > In other words, subnet-scope <= link-scope.

The text says (emphasis), 'subnet is _sometimes_ considered to be only 
a subset of a link..'.

You're only addressing the case where that 'sometimes' applies.  When 
it doesn't, subnet-scope >= link-scope -- which seems to be what some 
are proposing for NETLMM.  And that might bring some issues mentioned 
in the multilink subnet issues draft.

On Fri, 3 Nov 2006, Templin, Fred L wrote:
> I presume you had no problem with what I said below
> given the non-response.

No, I just don't think it's worth the time to argue this point, 
because you and me seem to read the multilink-subnet-issues draft 
completely differently.  This hopefully will be discussed at the 
face-to-face meeting (which I won't be able to attend) by DaveT et al.

(FWIW, my reading is that proxy/relay-DAD etc. behaviour is strongly 
discouraged, and it also breaks assumptions of protocol and 
application writers wrt the 'span' of TTL or a subnet.)

> On a related subject that relates to the NETLMM subnet
> model, from reading RFC3627 it seems that you have an
> expectation that two routers on a point-to-point link
> should configure addresses on their interfaces from a
> common prefix, e.g., 2001:DB8::/64. But, could it also be
> possible that the two routers configure addresses from
> *different* prefixes and still have everything work OK?
>
> Do you think this subject should be addressed in a (bis)?

With point-to-point links the addresses certainly don't need to come 
from the same prefix, but the DAD issue with the subnet-router anycast 
issue might or might not come up depending on the DAD implementation 
optimizations (mentioned in the multilink subnet draft) or lack 
thereof.  I don't think this warrants a revision.

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 5 Nov 2006 22:16:15 -0800

Pekka,

> completely differently.

I won't address the rest of your message for now, but the above
strikes me as a rather broad statement. I don't know by what
basis you can say "completely differently" based on the limited
discussion we have had thus far. Do you think you've read all
things right and I've read everything wrong or something like
that?

Fred

---

From: Pekka Savola <[email-masked]>
Date: Mon, 6 Nov 2006 09:25:02 +0200 (EET)

> things right and I've read everything wrong or something like

No.  In fact, when I drafted the earlier message, I had already 
written a speculation of how you'd have understood the multilink 
subnet issues draft to come to your (apparent) conclusion about per-MN 
addressing model and agreement with the draft.  But as I'm not a 
mind-reader and speculation about your interpretation would be more 
likely wrong than right, I deleted it.  Instead I just wrote how I 
interpreted it; feel free to expand how you concile per-MN addressing 
model and "agree[ment] with [multilink-subnet-issues] draft."