Subject: [netlmm] PMIPv6 - Some high level points for protocol design

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

All,
I want to reiterate some of the points relevant to network-based
mobility design that Jari mentioned at the San Diego meeting and have
also already been agreed to on the list. Even though consensus on some
of these points were not specifically in the context of PMIPv6, the
discussions are applicable to network-based mobility in general and are
not specific to the protocol. 

1. "No changes to MIP6 HA" is NOT a goal of this design. Minimal changes
to the HA is a reasonable goal - however, what is being defined is a
PMIPv6 "protocol" and NOT a "proxy agent for MIP6". 

2. The prefix-per-MN model for global addressing still holds. Shared
prefixes with individual address allocation for MNs is not an acceptable
model, given all the discussions that we have had on the list for quite
a long time. 

3. The protocol must comply with the requirements and threats documents
already approved. 

4. Keeping the requirements from other SDOs in mind is certainly
important; however, the protocol design must also keep the general IETF
model in focus. We are not designing or optimizing for a specific SDO to
be inline with specific architectural considerations/separations that
may be unique to a given SDO. The protocol designed must be generically
applicable for network-based IP mobility. SDO-specific optimizations are
not part of the charter. 

Thanks,
Vidya

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Feb 2007 12:00:03 +0100

Narayanan, Vidya wrote:
[...]
>  prefixes with individual address allocation for MNs is not an 
> acceptable model, given all the discussions that we have had on the 
> list for quite a long time.

Vidya, since you mention this, can we we spun off a thread on the
prefix-per-MN model.  I'm surprised you say shared prefixes is not
acceptable because: (1) draft-sgundave allows it, (2) prefix-per-MN is
recommended by one INFROMATIONAL RFC and (3) prefix-per-MN is
recommended by an IAB draft that offers an alternative to it which is to
enhance the links to be multicast capable.

And because prefix-per-MN has a potential negative consequence on
address waste.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Thu, 1 Feb 2007 17:12:44 +0100

Hi Alex,

On Thursday 01 February 2007 12:00, Alexandru Petrescu 
wrote:
> Narayanan, Vidya wrote:
> [...]
>
> > 2. The prefix-per-MN model for global addressing
> > still holds. Shared prefixes with individual
> > address allocation for MNs is not an acceptable
> > model, given all the discussions that we have had
> > on the list for quite a long time.
>
> Vidya, since you mention this, can we we spun off a
> thread on the prefix-per-MN model.  I'm surprised
> you say shared prefixes is not acceptable because:
> (1) draft-sgundave allows it, (2) prefix-per-MN is
> recommended by one INFROMATIONAL RFC and (3)
> prefix-per-MN is recommended by an IAB draft that
> offers an alternative to it which is to enhance the
> links to be multicast capable.

As far as I remember the per-MN-prefix has been so far 
a consensus in the WG. That probably means shared 
prefixes are not acceptable.

Regarding your points: 

1) draft-sgundave is not a WG draft. If it becomes one, 
it will have to reflect the WG consensus.

2) the WG consensus to go for per-MN-prefix is not 
based on RFC3314 (although it might be a hint) but 
rather on an analysis of the issues introduced by 
shared-prefix model, in light of 
draft-thaler-multilink-subnet-issues (which BTW is 
considered to be published as an INFORMATIONAL RFC)

3) the alternative that you name -- extending 
link-scoped multicast to all links where the shared 
prefix is used -- is not scalable to scenarios 
considered for NetLMM as per our -ps draft: large 
campuses and advanced cellular networks. In these 
scenario nobody is going to deploy a technology where 
I can do ping ff02::1 (or NS a solicited node 
multicast) if that is going to reach all people in 
this campus or cellular network.

> And because prefix-per-MN has a potential negative
> consequence on address waste.

The negative consequence on address waste does not come 
from prefix-per-MN, but rather from the limit placed 
on subnet prefix length (cannot be more than 64) If it 
is possible to assign /112 per MN then the waste is 
not that much, right?

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Feb 2007 17:50:45 +0100

Julien Laganier wrote:
> Hi Alex,
> 
> On Thursday 01 February 2007 12:00, Alexandru Petrescu wrote:
>> Narayanan, Vidya wrote: [...]
>> 
>>> 2. The prefix-per-MN model for global addressing still holds.
>>> Shared prefixes with individual address allocation for MNs is not
>>> an acceptable model, given all the discussions that we have had 
>> acceptable because: (1) draft-sgundave allows it, (2) prefix-per-MN
>> is recommended by one INFROMATIONAL RFC and (3) prefix-per-MN is
>> recommended by an IAB draft that offers an alternative to it which
>> is to enhance the links to be multicast capable.
> 
> As far as I remember the per-MN-prefix has been so far a consensus in
> the WG. That probably means shared prefixes are not acceptable.

That may take WiFi-based deployments out of netlmm support discussion.

Today's WiFi deployments don't use prefix per mobile (IPv4): many use 
DHCP assignment of addresses within a subnet.

> Regarding your points:
> 
> 1) draft-sgundave is not a WG draft. If it becomes one, it will have
> to reflect the WG consensus.

Agreed.

> 2) the WG consensus to go for per-MN-prefix is not based on RFC3314
> (although it might be a hint) but rather on an analysis of the issues
> introduced by shared-prefix model, in light of 
> draft-thaler-multilink-subnet-issues (which BTW is considered to be
> published as an INFORMATIONAL RFC)

Yes.

> 3) the alternative that you name -- extending link-scoped multicast
> to all links where the shared prefix is used -- is not scalable to
> scenarios considered for NetLMM as per our -ps draft: large campuses
> and advanced cellular networks.

I'm sorry, it's not an alternative _I_ named.  It's in same multilink
subnet issues.  It's about making links to be multicast capable.

draft-iab-multilink-subnet-issues-03.txt:
>   Loop prevention: If physical loops cannot exist within the subnet, 
>         then removing the TTL/Hop Limit decrement is not an issue.  
>         Otherwise, protocol designers can (for example) retain the 
>         decrement but use a separate prefix per link, or use some form 
>         of bridging protocol instead (e.g., [BRIDGE] or [RBRIDGE]). 
> 
>    Limiting broadcast (including all-hosts multicast): If there is no 
>         efficiency requirement to prevent broadcast from going to other 
>         on-link hosts, then flooding it within the subnet is not an 
>         issue.  Otherwise, protocol designers can (for example) use a 
>         separate prefix per link, or flood broadcast other than ARP 
>         within the subnet (ARP is covered below in section 4.3).    
> 
>    Limiting the scope of other multicast (including IPv6 Neighbor 
>         Discovery): If there is no efficiency requirement to prevent 
>         multicast from going to other on-link hosts, then flooding 
>         multicast within the subnet is not an issue.  Otherwise, 
>         protocol designers can (for example) use a separate prefix per 
>         link, or use IGMP/MLD snooping [RFC4541] instead.

Remark there's always an 'or' clause and prefix-per-link (ie per mobile 
IMHO) is not exclusive.

I don't propose to make the entire netlmm domain a single link, nor a
single subnet.

I'm talking about the nature of the link between MN and AR - only.  If 
that link is multicast capable then no need of prefix-per-MN, at least 
the multilink-subnet-issues draft seems to says so, in my wishful 
reading maybe.

> In these scenario nobody is going to deploy a technology where I can
> do ping ff02::1 (or NS a solicited node multicast) if that is going
> to reach all people in this campus or cellular network.

I agree ff02::1 shouldn't span the entire netlmm domain including their 
wireless links.

> The negative consequence on address waste does not come from
> prefix-per-MN, but rather from the limit placed on subnet prefix
> length (cannot be more than 64) If it is possible to assign /112 per
> MN then the waste is not that much, right?

Even if we have a /112 prefix per mobile (and not just /64) there's 
still address waste, because it means that if that /112 can cover only 
one mobile 16 other mobiles aren't possible.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Feb 2007 09:47:59 -0800

About models other than prefix-per-MN:

1) Shared prefix advertised with 'A'=1; 'L'=0
I though the only question here was whether domain-wide
proxy/relay DAD was needed (i.e., the same as for link-
locals), and that there was going to be some consultation
with application area directors on this subject?

2) Shared prefix advertised with 'A'=0; 'L'=0
In this case, the MN can use DHCP to get addresses from
the prefix for assignment on the wireless interface and/or
prefix delegations for assignment on downstream links. (For
address assignment the MN can be a simple host, but for
prefix delegation the MN must be a router.) Or, the MN
could ignore the prefix and operate per case 3 as follows: 

3) No prefixes advertised
The same as for case 2, except that the MN can assign the
addresses on either the wireless interface (i.e. the same
as for case 2) or a virtual interface such as a loopback
interface. Assignment on a loopback interface works when
the MN configures both a DHCP client that listens on the
loopback interface and a DHCP relay that relays between
the loopback interface and the wireless interface, but it
would require the MN to be a router.

I have seen some talk on the DNA list about cases 2) and
3) but haven't been able to keep up with the discussion
there; maybe someone could summarize?

Fred
[email-masked]

---

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

> PMIPv6 "protocol" and NOT a "proxy agent for MIP6".

I dont see the finer line betwen the two. This is a protocol
extension to MIP6. Leveraging the infrastructure, protocol
and messaging sementics.

> model, given all the discussions that we have had on the list for quite

We took the same stand in the initial version of the draft. Later,
we have added support for Shared-Prefix model and the MN obtaining
the address configuration using DHCP. We dont see any issues, unless
the WG has a different opinion.

Also, for IPv4 HoA support, we dont any option other than Shared-Prefix
model. Given that, we rather be consistent and support both the models.

Do you agree, if there are no issues supporting Shared-Prefix model,
why not keep it ?

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 1 Feb 2007 15:14:34 -0800

Alex,
I think you may be mixing the prefix-per-MN global addressing model with
the link-local semantics we were discussing for the MN-AR link. The
prefix-per-MN model is only applicable for the global address of the MN
- in this case, the MN doesn't even need to know that was a prefix
uniquely assigned to it - if it is only used to configuring one IP
address from a prefix received, it could still do that. The NETLMM/PMIP
domain manages it as a unique prefix on a per-MN basis. This is to avoid
the entire domain being one shared subnet. 

The link-local behavior on the MN-AR link is still pending. I'll address
that separately. 

Thanks,
Vidya 

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Thursday, February 01, 2007 8:51 AM
> To: Julien Laganier
> Cc: [email-masked]; Narayanan, Vidya
> Subject: Re: prefix-per-MN
> 
> Julien Laganier wrote:
> > Hi Alex,
> > 
> >>> Shared prefixes with individual address allocation for 
> MNs is not an 
> >> recommended by an IAB draft that offers an alternative to 
> it which is 
> >> to enhance the links to be multicast capable.
> > 
> Today's WiFi deployments don't use prefix per mobile (IPv4): 
> many use DHCP assignment of addresses within a subnet.
> 
> > Regarding your points:
> > 
> > 3) the alternative that you name -- extending link-scoped 
> multicast to 
> > all links where the shared prefix is used -- is not scalable to 
> I'm sorry, it's not an alternative _I_ named.  It's in same 
> multilink subnet issues.  It's about making links to be 
> multicast capable.
> 
> I don't propose to make the entire netlmm domain a single 
> link, nor a single subnet.
> 
> I'm talking about the nature of the link between MN and AR - 
> only.  If that link is multicast capable then no need of 
> prefix-per-MN, at least the multilink-subnet-issues draft 
> seems to says so, in my wishful reading maybe.
> 
> > do ping ff02::1 (or NS a solicited node multicast) if that 
> is going to 
> > reach all people in this campus or cellular network.
> 
> I agree ff02::1 shouldn't span the entire netlmm domain 
> including their wireless links.
> 
> Even if we have a /112 prefix per mobile (and not just /64) 
> there's still address waste, because it means that if that 
> /112 can cover only one mobile 16 other mobiles aren't possible.
> 
> Alex
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 02 Feb 2007 10:51:22 +0100

Narayanan, Vidya wrote:
> Alex, I think you may be mixing the prefix-per-MN global addressing
> model with the link-local semantics we were discussing for the MN-AR
> link. The prefix-per-MN model is only applicable for the global
> address of the MN - in this case, the MN doesn't even need to know
> that was a prefix uniquely assigned to it - if it is only used to
> configuring one IP address from a prefix received, it could still do
> that. The NETLMM/PMIP domain manages it as a unique prefix on a
> per-MN basis. This is to avoid the entire domain being one shared
> subnet.

Vidya, thanks for the message.

There's indeed intertwining between the prefix-per-MN recommendation and
the nature of the link MN-AR.

Without considering link-local semantics one isn't in the scope of
draft-multilink-subnet-issues, so its recommendation doesn't apply, do
you agree.

The global address of MN is treated differently on the MN-AR link if
that link has multicast capabilities or not.  If it hasn't, and if it's
ptp link, then draft-multilink-subnet-issues recommends to either (1)
use prefix-per-mobile (a global address) or (2) use bridging or make it
multicast capable.  That's my reading of it, and I agree with it as such.

> The link-local behavior on the MN-AR link is still pending. I'll
> address that separately.

Ok, I'll wait for that.  They're intertwined anyways.

Alex

---

From: Anand Bedekar <[email-masked]>
Date: Sun, 04 Feb 2007 12:46:57 -0600

On 2/1/2007 3:48 AM, Narayanan, Vidya wrote:
<snip>
> PMIPv6 "protocol" and NOT a "proxy agent for MIP6". 
<snip>

Vidya,

I agree with this. I think it does still make sense to examine how
many changes to the MIP6 protocol and HA behaviour are being called for 
in order to support various aspects of PMIP operation.

I think this also relates to several of the other points you have
raised, which are right at the boundary of what MIP6/HA can currently 
do, e.g.
- whether there should be support for IPv4 data inside a MIPv6 tunnel,
- whether PMIP HoA can be allowed to be the same as CMIP HoA, etc.

A lot of these are desirable in some form for PMIP operation, but the 
question seems to be what should be in the scope of NetLMM WG's output 
and what should be left out. Plus, some of these may not be needed by 
various SDOs who may want to incorporate the NetLMM WG's output into 
their spec. I think one way to tackle the scope issues is to have some 
finer granularity on the feature set, so as to allow SDOs thinking of 
adopting NetLMM WG's output to choose what matches with their 
system/deployment scenarios.

I think one way of going about breaking down the feature set is to
identify those that can be supported without any extensions to the MIP6 
protocol or modifications to HA behaviour, and those that can be 
supported through extensions/modifications (and document the 
implications of such exts/mods). I would even go further and suggest 
that the output of the WG (IETF drafts and eventual RFCs) should be 
divvied up along these lines - a base draft/RFC identifying how a 
solution for NetLMM based on PMIP can be implemented without any 
exts/mods to MIP6/HA, and then additional (one or more) drafts/RFCs 
identifying specific extensions to the base to support specific features 
and their implications. This way, NetLMM WG can support a fairly broad 
variety of features, without having to define it all in one fell swoop. 
This would also allow SDOs thinking of adopting NetLMM WG's
output to choose what matches with their system/deployment scenarios.

An alternative is of course a single jumbo draft that incorporates
a lot of things - if we decide to go that way then conflicts over what's
in scope and what's out are inevitable. Even for such a draft, a  clear
separation (either by sections, or appendices, or whatever) along these
lines would be good. In any case, when we decide what MUST be supported
and what MAY be optionally supported, etc., we should take into
consideration what exts/mods to HA/MIP6 are required (and their impacts)
in the "MUST" specification.

I'd like to hear what you and the WG folks think about this.

Thanks,
Anand

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 11:42:03 +0100

Anand Bedekar wrote:
> On 2/1/2007 3:48 AM, Narayanan, Vidya wrote: <snip>
>> 1. "No changes to MIP6 HA" is NOT a goal of this design. Minimal 
>> changes to the HA is a reasonable goal - however, what is being 
>> defined is a PMIPv6 "protocol" and NOT a "proxy agent for MIP6".
> <snip>
> 
> Vidya,
> 
> many changes to the MIP6 protocol and HA behaviour are being called 
> for in order to support various aspects of PMIP operation.
> 
>  do, e.g. - whether there should be support for IPv4 data inside a 
> MIPv6 tunnel, - whether PMIP HoA can be allowed to be the same as 
> CMIP HoA, etc.
> 
>  question seems to be what should be in the scope of NetLMM WG's 
> output and what should be left out. Plus, some of these may not be 
> needed by various SDOs who may want to incorporate the NetLMM WG's 
> output into their spec.

For example, I'm not sure how P-MIPv6 reliance on IP-in-IP tunnel (the
MIPv6 MH-HA tunnel) interacts with one SDO's necessity of using GRE
tunnels (l2 in l3).

> I think one way to tackle the scope issues is to have some finer 
> granularity on the feature set, so as to allow SDOs thinking of 

I agree.

> identify those that can be supported without any extensions to the 
> MIP6 protocol or modifications to HA behaviour, and those that can be
> implications of such exts/mods).

I am pretty sure that there is no MIP6 feature that can be re-used
unmodified in a proxy-MIP6 context, without development of another
necessary feature.

For example, if we want AR to send an unmodified BU on behalf on MN then
we need a mechanism for AR to be authorized by MN to do that.

If we want AR to do DHAAD on behalf of MN then we need a means for AR to
communicated that subnet info to MN.

If we want AR to send even a unmodified 3775-BU (considering it _has_
been auorized by MN to do so) then we need a means for AR to detect that
MN needs to do that.

> I would even go further and suggest that the output of the WG (IETF 
> drafts and eventual RFCs) should be divvied up along these lines - a 
> base draft/RFC identifying how a solution for NetLMM based on PMIP 
> can be implemented without any exts/mods to MIP6/HA, and then 
> additional (one or more) drafts/RFCs identifying specific extensions 
> to the base to support specific features and their implications. This
>  way, NetLMM WG can support a fairly broad variety of features, 
> without having to define it all in one fell swoop. This would also 
> allow SDOs thinking of adopting NetLMM WG's output to choose what 
> matches with their system/deployment scenarios.

I agree.  Dividing the work and offering SDO a menu to choose from is a
good approach.  To see how to divide that work...

> An alternative is of course a single jumbo draft that incorporates a
>  lot of things - if we decide to go that way then conflicts over 
> what's in scope and what's out are inevitable. Even for such a draft,
>  a  clear separation (either by sections, or appendices, or whatever)
>  along these lines would be good. In any case, when we decide what 
> MUST be supported and what MAY be optionally supported, etc., we 
> should take into consideration what exts/mods to HA/MIP6 are required
>  (and their impacts) in the "MUST" specification.

I oppose this alternative.  A jumbo draft will obviously not cover all
necessary features and will slow adoption.

I think criteria  for dividing the works are the following: (1) what are
the tunnels/routes between ARs and LMA (IP-in-IP? MIP6? GRE? L2TP?) (2)
what is the nature of link between MN and AR (ptp or shared?) (3) what
is the means for AR to detect movement of MN (4) what is the security
mechanism to be used (AAA-based, IPsec-based, cert-based) and (5) what
is the address acquisition mechanism.

Ideally, a base draft should be able to support all feature
combinations, ie a base should work with IP-in-IP tunnel with ptp MN-AR
with AAA-based auth with ND triggers and SLAAC.

But same base draft should work also with L2TP tunnels with WiFi MN-AR
link and IPsec auth and DHCP.

Alex

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 12 Feb 2007 22:01:46 -0800

Hi Sri,
 
> We took the same stand in the initial version of the draft. 
> Later, we have added support for Shared-Prefix model and the 
> MN obtaining the address configuration using DHCP. We dont 
> see any issues, unless the WG has a different opinion.
> 

The WG has already had a different opinion and this has been a closed
topic with consensus. Using per-MN global IPv6 addresses with multiple
MNs sharing the global prefix brings the multi-homing issues, which is
what the group decided to avoid. And, revisiting this decision was one
of the main points we said we would avoid in light of shifting the
direction towards PMIP.  

> Also, for IPv4 HoA support, we dont any option other than 
> Shared-Prefix model. Given that, we rather be consistent and 
> support both the models.
> 

Due to the address limitations of IPv4, this is true. However, it is
also true that there are fewer relevant protocols/applications that use
link-local or such single hop behavior in IPv4. For instance, nodes use
DHCP for dynamic address configuration - autoconfiguration using an
NDP-like mechanism is not something that is used. So, that also makes it
simpler to use the shared global prefix model for IPv4. 

Vidya

> Do you agree, if there are no issues supporting Shared-Prefix 
> model, why not keep it ?
> 
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 12 Feb 2007 22:47:44 -0800 (PST)

> simpler to use the shared global prefix model for IPv4.

No issue on supporting Shared-Prefix model for IPv4. That is
practical and understood. Now, the same question for IPv6
Share-Prefix mode, I realize the WG has already made a decision
and under the light of some other discussions and some other specs
guiding that decision. The current view, we can support the
Shared-prefix model for the Stateful Address configuration mode
in DHCP, with out any issues. Now, if our assumption is wrong and
if there are good reasons not to support, we support the WG decision.
But, lets make sure there is a good reason not to support this
scenario. Its a useful scenario and we already have it.

By no means, our idea is to hold on to scenario's what we think
should be supported, but rather the thinking that if we understand
the issues to good extent, if it is a useful scenario and if we can
document and provide proper guidance to the implementors, I ask,
why not ???

Sri

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 13 Feb 2007 16:18:03 +0100

Narayanan, Vidya wrote:

>Hi Sri,
> 
>  
>
>>>2. The prefix-per-MN model for global addressing still 
>>>      
>>>
>>holds. Shared 
>>    
>>
What we should try to avoid is running again into details
and associated discussion to solve all issues with
shared-prefix operation, such as DAD, etc.
But I don't think we should explicitly exclude shared-prefixes,
as it might be useful in some networks. If we relax the requirement
to solve all issues coming with shared-prefixes and to provide a
fully-fledged solution to them, I don't see a problem with adding
shared-prefix support in the base specification. I think a reference
to (or even mandating) DHCP takes a lot of pain from this issue.

What do you think?

marco

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Feb 2007 17:04:13 +0100

Marco Liebsch wrote:
>>>> acceptable model, given all the discussions that we have had on
>>>> the list for quite a long time.
>>>> 
>>>> 
>>> Later, we have added support for Shared-Prefix model and the MN
>>> obtaining the address configuration using DHCP. We dont see any
>>> issues, unless the WG has a different opinion.
>>> 
>>> 
>> 
>> The WG has already had a different opinion and this has been a
>> closed topic with consensus. Using per-MN global IPv6 addresses
>> with multiple MNs sharing the global prefix brings the multi-homing
>> issues, which is what the group decided to avoid. And, revisiting
>> this decision was one of the main points we said we would avoid in
>> light of shifting the direction towards PMIP.
>> 
> What we should try to avoid is running again into details and
> associated discussion to solve all issues with shared-prefix
> operation, such as DAD, etc. But I don't think we should explicitly
> exclude shared-prefixes, as it might be useful in some networks. If
> we relax the requirement to solve all issues coming with
> shared-prefixes and to provide a fully-fledged solution to them, I
> don't see a problem with adding shared-prefix support in the base
> specification. I think a reference to (or even mandating) DHCP takes
> a lot of pain from this issue.
> 
> What do you think?

I agree with your perspective in this shared-prefix discussion.

I support referencing DHCP enhancements when we talk shared-prefix
discussion and I think it can take a lot of pain from this issue.

Alex