Subject: [netlmm] Link Local Addressing Semantics

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 5 Dec 2006 10:39:34 -0800

Folks,
We have had a lot of discussion on this topic under several threads, but
we have not yet explicitly reached an agreement. We do have agreement on
using a prefix-per-MN model itself as far as global addressing is
concerned, but the link local addressing semantics are still under
discussion. This decision affects the protocol as well as the MN-AR
interface document. Both shared link and P2P link semantics for link
local addresses have been under discussion. I'll attempt to summarize
the technical details on both sides here. I would like to hear other
technical thoughts and requirements from the WG participants. 

Preface
-------
At a high level, based on the multi-link subnet issues with shared
prefixes in NETLMM, it has been recommended by some that we adopt the
prefix-per-MN model for global addressing and point-to-point link
semantics for link local addressing. Some have expressed the opinion
that we should support shared link local behavior. I would like to hear
about requirements for the latter that would make the tradeoff with
multi-link subnet problems acceptable. As far as I can tell, the benefit
of on-link reachability is on broadcast media and when it is truly "on
link" - once a prefix has to traverse multiple links (with some of those
links potentially being non-broadcast links), I am not sure I see the
benefit of link-local reachability.  

1. Point-to-point link local semantics
--------------------------------------

* Avoids the multi-link subnet issues

* In particular, proxy ND functions are not needed. DAD for the link
local address may be needed upon link changes when the MN obtains RAs
with different link local addresses at every AR. 

* Protocols using link-local multicast become easier to operate - e.g.,
routing protocols, MLD, some service discovery  and name resolution
protocols, DHCP, etc. Some of these protocols are important for hosts,
while some others are more important to routers. For instance, requiring
MLD queries to be carried over multiple links would be undesirable in a
system. 

* Protocols relying on specific TTL values of 1 or 255 have no issues

2. Shared link local semantics
------------------------------

* Subject to multi-link subnet issues

* Proxy ND behavior needed in the AR and in the LMA

* More issues with link-local multicast - decision on how to treat
link-local multicast needs to be made on a case-by-case basis, depending
on the protocol. This has significant impact on the deployment of such
protocols and development of new protocols that depend on link-local
multicast

* TTL issues with link-local traffic traversing more than one hop

Vidya

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Dec 2006 21:46:36 +0200 (EET)

> 2. Shared link local semantics

This seems to have an implicit assumption, i.e., that when a host 
joins a shared link, AR/LMA will do Proxy ND on other links to ensure 
the uniqueness of the address, right?

I argue that this is not necessarily required.  If we examine how 
vanilla IPv6 ND works, when a host moves to a new link, its link-local 
(or global) address is not necessarily tested for DAD.  Whether this 
is done probably depends most on whether the interface went down while 
leaving a previous link and came back after re-attaching and that no 
packets were lost.  In other words, no matter what NETLMM protocol 
does, link-local addresses may conflict if two nodes sharing the same 
address join the same physical link (and it doesn't matter if they 
don't share the physical link whether there is NETLMM or not).

So, I'm not sure if NETLMM should be concerned about this particular 
scenario given that IIDs are typically pretty random.  If this needs 
scenario to be addressed, a targeted update to RFC 2461 might be in 
order.

That said, I nonetheless like the point-to-point model better because 
it makes fewer assumptions about applications and protocols.  I'd have 
liked to support shared links as well (so that more or less unmodified 
enterprise ethernets could easily use NETLMM if they wished), but that 
might be too difficult to achieve.

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

---

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 5 Dec 2006 15:25:13 -0600

I believe we should focus first on the p-2-p model. I think this will
make it easier for other standards such as 3gpp2 and 3gpp to look at the
netlmm solution. 
-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Tuesday, December 05, 2006 12:40 PM
To: [email-masked]
Subject: [netlmm] Link Local Addressing Semantics

Folks,

Preface
-------

Vidya

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Dec 2006 14:36:27 -0800

Pekka's reply seems to focus attention on the aspects

>> 2. Shared link local semantics

I don't think its fair to say that shared *links* are
necessarily "subject to multi-link subnet issues", but
rather that shared *prefixes* used inappropriately are
(independently of shared/p2p links). But, I don't think
this is necessary to debate further for the purpose of
this discussion.

>From what I understand, the proposal (which did not come
from me) is for a Relay-DAD service and not a full RFC4389
ND Proxy, because RFC4389 is incompatible with SEND in its
current manifestation. As I understand it, the proposed
Relay-DAD works as:

  1) MAG receives MN's NS(DAD) and ships it to LMA w/o
     decrementing Hop Limit
  2) LMA determines whether a colliding node exists on
     another link, where the node could be another MN
     or a MAG
  3) LMA ships NS(DAD) to MAG where colliding node resides
     - again, w/o decrementing Hop Limit
  4) MAG transmits NS(DAD) on the link with the colliding
     node, then ships the resulting NA(DAD) along the reverse
     path to the originating MAG - again, w/o decrementing
     Hop Limit

As I understand it, the situation is the same for both p2p
and shared links, because the colliding node could be a MAG
that the MN might move onto at some point in the future even
if the links are p2p. Maybe someone can confirm or correct
my understanding? 

> packets were lost.

An "in-service" DAD in which MNs rerun DAD every time their
link changes may not be compatible with some use-cases in
which the MN's link is changing all the time, since the
MNs would be forever re-DADing their addresses.

> In other words, no matter what NETLMM protocol 

A "pre-service DAD" such as the Relay-DAD described above
and in the MN-AR interface spec would protect against two
nodes sharing the same address from joining the same
physical link, as long as neither the NS(DAD) nor NA(DAD)
are lost. So, the probability of undetected collision 'U'
would then be: U = (P(collision) * (P(loss) * 2)) which
should be quite small. 

> scenario given that IIDs are typically pretty random.

I believe the expected IID generation mechanism is CGA?

> If this needs 

I don't quite get the tie-in with RFC2461?

> might be too difficult to achieve.

IMO, statements like "makes fewer assumptions" and "might
be too difficult to achieve" need to be qualified, e.g.,
is there really anything more to the concern than just
the Relay-DAD?

Fred
[email-masked]

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 5 Dec 2006 17:27:51 -0800

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 11:47 AM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [netlmm] Link Local Addressing Semantics
> 
> This seems to have an implicit assumption, i.e., that when a 
> host joins a shared link, AR/LMA will do Proxy ND on other 
> links to ensure the uniqueness of the address, right?
> 

The answer depends on whether the shared link semantics are restricted
to just under one AR or under the LMA. The above is true when shared
link local semantics are expected throughout the entire NETLMM domain
(i.e., under an LMA). 

> I argue that this is not necessarily required.  If we examine 
> how vanilla IPv6 ND works, when a host moves to a new link, 
> its link-local (or global) address is not necessarily tested 
> for DAD.  Whether this is done probably depends most on 
> whether the interface went down while leaving a previous link 
> and came back after re-attaching and that no packets were 
> lost.  In other words, no matter what NETLMM protocol does, 
> link-local addresses may conflict if two nodes sharing the 
> same address join the same physical link (and it doesn't 
> matter if they don't share the physical link whether there is 
> NETLMM or not).
> 

Agree with the above if the shared link local semantics are restricted
to one physical link in the case of NETLMM. If the assumption is that
just because the global address/prefix doesn't change under an LMA, the
entire NETLMM domain is to behave like a shared link for link local
purposes, we can't get away from doing proxy ND or some such thing. 

That said, I don't think NETLMM should consider shared link semantics
spanning the whole domain - that is quite problematic and I can't see
any value in that. 

> So, I'm not sure if NETLMM should be concerned about this 
> particular scenario given that IIDs are typically pretty 
> random.  If this needs scenario to be addressed, a targeted 
> update to RFC 2461 might be in order.
> 

I don't believe that is necessary for any typical case. And, as I said,
I don't think we should consider multi-link shared link local semantics.

> That said, I nonetheless like the point-to-point model better 
> because it makes fewer assumptions about applications and 
> protocols.  

I agree. 

> I'd have liked to support shared links as well 
> (so that more or less unmodified enterprise ethernets could 
> easily use NETLMM if they wished), but that might be too 
> difficult to achieve.
> 

Let's discuss this. There are a few different aspects that really need
to be discussed here - which entity is the default router? And, which
entity performs other typical edge functions - like MLD router or DHCP
relay agent, etc? I'll start a separate thread to talk about this to
make it easier to follow the discussion.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 5 Dec 2006 17:46:58 -0800

Fred,
Let's step back and answer one fundamental question - what is the
requirement to have shared link-local semantics in a NETLMM domain?
Without knowing the requirements, it is not feasible to figure out if
the tradeoffs are worth it. 

More inline. 

> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 2:36 PM
> To: Pekka Savola; Narayanan, Vidya
> Cc: [email-masked]
> Subject: RE: [netlmm] Link Local Addressing Semantics
> 
> Pekka's reply seems to focus attention on the aspects of this 
> that really matter; see below for follow-up: 
> 
> necessarily "subject to multi-link subnet issues", 

I was talking about shared link local semantics over multiple links, not
shared links themselves. 

>but rather 
> that shared *prefixes* used inappropriately are 
> (independently of shared/p2p links). But, I don't think this 
> is necessary to debate further for the purpose of this discussion.
>  
> From what I understand, the proposal (which did not come from 
> me) is for a Relay-DAD service and not a full RFC4389 ND 
> Proxy, because RFC4389 is incompatible with SEND in its 
> if the links are p2p. Maybe someone can confirm or correct my 
> understanding? 
> 

In the p2p case, this can be fixed by just regular IPv6 behavior - if
the MN realized the link change, it may do a DAD for the link-local
address. If the LMA is the default router and all MAGs echo the RA from
the LMA, the MN never sees a different link-local address. OTOH, for
shared link-local semantics under the LMA, this type of proxy/relay DAD
operation needs to occur, at least upon attachment to the NETLMM domain.

> which the MN's link is changing all the time, since the MNs 
> would be forever re-DADing their addresses.
> 
> > In other words, no matter what NETLMM protocol does, link-local 
> > addresses may conflict if two nodes sharing the same 
> address join the 
> > same physical link (and it doesn't matter if they don't share the 
> > physical link whether there is NETLMM or not).
> 
> A "pre-service DAD" such as the Relay-DAD described above and 
> in the MN-AR interface spec would protect against two nodes 
> sharing the same address from joining the same physical link, 
> as long as neither the NS(DAD) nor NA(DAD) are lost. So, the 
> probability of undetected collision 'U'
> particular 
> IMO, statements like "makes fewer assumptions" and "might be 
> too difficult to achieve" need to be qualified, e.g., is 
> there really anything more to the concern than just the Relay-DAD?
> 

Yes, please see the entire list I sent out. There are more protocols
that use link-local multicast than just ND. MLD is an example. Dave
Thaler's draft points out other examples as well. An IPv6 host is free
to run any of the other protocols that use link local multicast and
expect a certain TTL value. As to what *impacts* NETLMM, it is ND; as to
what is *impacted by* a NETLMM domain having shared link-local
semantics, it is all the protocols and applications that use link local
multicast. Irrespective of the size of that set, it would be bad to pose
restrictions or to have to specify the behavior for each one of those
protocols specifically when NETLMM is used. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 5 Dec 2006 19:05:05 -0800

> easily use NETLMM if they wished), but that might be too 

We've been discussing the topic of p2p vs shared link local semantics
focusing just on the functions that impact NETLMM. There are other
discussions with respect to access router and other link-local functions
typically feasible on shared media, but, we have not quite delved into
the details there yet. Technically, this is an architectural discussion,
but I believe we need to have this to understand the impacts of NETLMM
deployment in an IP-based system.  

There are several functions that typically reside in an access (edge)
router in an IP network: 

* Default router
* DHCP relay agent
* MLD router

There may be more functions if the AR is dual-stacked, but that is a
start. 

There are several options for the default router function: 

i) The AR (MAG) acts as the default router and hence, the MN needs to
learn the new default router upon link change before it can send
packets. 

In this case, the other functions can also be located in the AR/MAG, so,
it is not an issue. However, this is undesirable for systems looking for
low latency handoffs and some systems that are likely to use NETLMM are
not likely to adopt this model. 

ii) The LMA acts as the default router and hence, the MN always sees the
same default router in the NETLMM domain. 

While this is attractive from the default router function perspective
itself, I am not sure how the other functions can still be in the AR,
even though the LMA is the default router. If this is not feasible, it
takes away the benefit of having an all-IP network, in my view. MLD
queries having to traverse all the links from the LMA down is not a
scalable solution, for instance. This also makes the LMA the first
router that runs a multicast routing protocol, making the AR more or
less like a bridge. Turning an IP router into a bridge does not look
attractive to me. 

iii) A virtual link-local IP address and a virtual MAC address is shared
across the ARs (MAGs) and hence, the MN always sees the same default
router in the NETLMM domain. 

This provides an alternative that will allow the AR to be a real AR,
although, the ARs need to share a key for this virtual address in order
to run SeND.  

Apart from this, there is the question of whether applications such as
LLMNR or MDNS have a place in NETLMM domains over shared media like
ethernet. It is undesirable that these traverse multiple links - so, we
should not be extending any shared link semantics over multiple links.
However, in case i) above, for instance, if the MNs connect to the AR
via shared media, it is possible to use such applications. For cases ii)
and iii), I think it leads to issues with respect to making assumptions
about such applications. 

Thoughts?

Vidya

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Dec 2006 11:45:40 +0100

Pekka Savola wrote:
>> 2. Shared link local semantics ------------------------------
>> 
> I argue that this is not necessarily required.

I agree it is not necessarily required to do proxy DAD for link-local
addresses on other ARs wireless subnets.  The link-local address is
local to the link where active.  The AR will not forward packets to/from
it.  (1) Even if there's a duplicate address on another AR's wireless
subnet it will not clash with the one here, because traffic not
forwarded. (2) link-locals for links we're concerned here are clearly
derived from unique 48bit addresses, IEEE ensures that.  (1) and (2) are
enough guarantees.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Dec 2006 12:17:06 +0100

Narayanan, Vidya wrote:
> * Protocols using link-local multicast become easier to operate - 
> e.g., routing protocols, MLD, some service discovery  and name 
> resolution protocols, DHCP, etc.

What is "link-local multicast"?  Why ND is not mentioned?  A host won't
receive an RA unless it joins a link-local all-hosts multicast group.

Some routing protocols use multicast that spans subnets, not only local
to a link.  OSPF sends to all-routers-in-an-area-or-so, that group spans
subnets.  RIP sends to only neighbours, so this may be "link-local
multicast"?

Do you see a cell-phone running a routing protocol over that
point-to-point link.  Why claiming routing protocol operation as an
advantage of p2p links.

Also, if the link is point-2-point, then DHCP on host is not concerned
(the host doesn't run DHCP) - address assignment is done with IPv6 LCP
(eventually extended by Radius, Diameter) giving the fe80 and then RA.
  Thus why claiming DHCP operation as an advantage of point-to-point
links, sounds strange.

A name resolution protocol (DNS?) works across subnets too.  What part
of DNS you think is concerned  by link-local multicast?

On another hand, what is the link-local multicast model of the p2p links
this group considers?  Is that a link-layer multicast? (using link-layer
addressing, not IP addressing). Is this group concerned by link-layer
addressing.

There are many other reasons to propose work on the p2p links first,
instead of shared link models.  One is that apparently customers of this
work here prefer p2p links.  This is something that should be clarified
and put up front, maybe in the Charter.  That should suggest going along
the IPv6 PPP LCP line too.  It would avoid too much disgression.

Once we know the mobile's link is point-2-point and runs IPv6 PPP LCP
then things are much easier to discuss.

> Some of these protocols are important for hosts, while some others 
> are more important to routers. For instance, requiring MLD queries to
>  be carried over multiple links would be undesirable in a system.

Vidya, sorry for splitting the hair here, but I don't follow you here,
let me explain why.  Indeed some of these protocols are important for
hosts (say DHCP) and others for routers (say OSPF).  But some of these
protocols are run both by hosts and by routers (DHCP, MLD, ND).  And
some hosts and some routers run neither.  Only for OSPF can we say it's
mostly dedicated to routers, but even then some routers have only one
physical interface (e.g. a HA).

Why carry MLD queries over multiple links?  What needs it.  Why is it
undesirable?  Is it undesirable because some protocols are important for
hosts and some for routers?  MLD as specified is not carried across
multiple links.

I'm trying to understand...

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Dec 2006 10:57:37 -0800

Hi Vidya 

Thanks for the clarifications. I'm not going to have a lot
of time to devote to ongoing discussion, so I'll try to

> the tradeoffs are worth it.

Could be I have been confusing "shared links" with "shared
link-local semantics". I agree that *full* shared link-local
semantics across the entire NETLMM domain would be an onerous
scenario for large domains, and I really don't see much value

> I was talking about shared link local semantics over multiple links,
not

OK, that clarifies. I agree that full shared link-local
semantics over multiple links would be unnecessary and/or
undesireable in most (if not all) cases.

> the LMA, the MN never sees a different link-local address.

OK, so for p2p links you are suggesting an in-service DAD
approach whereby the MN reruns DAD upon link change. That
is fine as long as MNs will actually do this, but some have
suggested that re-DADing on link-change is not necessarily
the default behavior for unmodified IPv6 nodes?

> OTOH, for

Again, I agree that *full* shared link-local semantics would
be undesirable, e.g., we would not want for a MN's multicast
RS to be flooded across the entire NETLMM domain. The relay-DAD
proposal described in my previous message (which again did not
come from me) is for a pre-service DAD mechanism using *partial*
shared link-local semantics where only NS/NA(DAD) are relayed,
and then only to the links on which nodes with colliding
addresses reside; not the entire domain.
 
> protocols specifically when NETLMM is used. 

Right; I agree that *full* shared link-local semantics would
be undesireable for the NETLMM domain; link-local multicast
should be restricted to the local link as-expected by apps
with the possible exception of NS/NA(DAD) per the relay-DAD
proposal. It is possible to special-case the NS/NA(DAD)
messages while leaving the other link-locals alone, and I
don't see any issues for neighbor cache management or apps.

Whether relay-DAD is truly needed however is based on one's
tolerance for undetected address configuration collisions
within the laws of probability. If nodes use administratively-
configured interface IDs (e.g., EUI48) then there should
be no collisions to begin with. But, if nodes use randomly-
generated interface IDs (e.g., CGA) then P(collision) is
based on the random number generation algorithm and the
number of random bits, and P(undetected collision) for two
colliding nodes that begin on different links is  P(collision)
*times* the probability that the two colliding nodes will
move onto the same link at some future time.

P(collision) for randomly-generated interface IDs is easy
to calculate and should be quite small for CGAs, but the
probability of two nodes moving onto the same link at some
future time is totally dependent on the configuration of
the NETLMM domain and accidental nature of node movements.
Relay-DAD can give much greater assurance against undetected
collision, but even using that does not give absolute
guarantee. So, again, it comes down to what is our
tolerance level for undetected collision?

There is still a worst-case to consider in which nodes
configure self-generated interface IDs not based on some
agreed-upon random number generation (e.g., ::1). In that
case, a relay-DAD mechanism (plus the configuration of
the NETLMM domain and accidental nature of node movements)
are the *only* assurances against undetected collision.
Can we expect such worst-case behavior from IPv6 nodes,
or will it be all EUI-64s and CGAs?

Fred

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 6 Dec 2006 13:56:55 -0800

Hi Fred, 

<snipping heavily to focus on the relevant parts>

> in it. 

Good. This was not clear to me earlier. Now, the problem with allowing
shared link behavior is that a typical IPv6 node expects the shared link
to span the same topological scope as its IPv6 prefix/address. However,
that leads to multi-link subnet issues in NETLMM, since, the IPv6 prefix
of the MN is spanning several links here. Having shared link semantics
limited to just the last link (between AR and MN) means you have the
network behaving differently from what the applications and protocols on
the MN expect from IPv6 link local behavior.

The upper layers on the MN may assume that the same level of
reachability for link-local addresses exist due to the unchanged IP
prefix, even though the MN has switched links in reality. In keeping
with normal IP behavior, a prefix doesn't span multiple links, while
multiple prefixes may be present on a given link. Hence this problem
with NETLMM and link-local semantics. 

Vidya

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Dec 2006 14:16:36 -0800

Vidya,

I don't get how you are getting from point A to point B here;
shared links in a NETLMM domain do not in and of themselves
cause multilink subnet. What matters is the prefixes that are
advertised in RAs and which nodes receive those prefixes.
Prefix-per-MN can still be done on shared links using unicast
RAs, and RAs that carry no PIOs with 'A'=1 are also fine; MNs
can just use DHCP to get address/prefix delegations.

Also, IMO the term "multilink subnet" is increasingly being
used loosely and in a pejorative way; shared links do not
automatically mean multilink subnet.

Fred

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Wednesday, December 06, 2006 1:57 PM
To: Templin, Fred L; Pekka Savola
Cc: [email-masked]
Subject: RE: [netlmm] Link Local Addressing Semantics

Hi Fred, 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 6 Dec 2006 14:30:14 -0800

> Sent: Wednesday, December 06, 2006 2:17 PM
> To: Narayanan, Vidya; Pekka Savola
> Cc: [email-masked]
> cause multilink subnet. 

I didn't say that shared links alone cause multi-link subnets. There is
a disparity between a) the expected relationship between an IP prefix
and link-local semantics and b)the actual link-local semantics in a
NETLMM domain when link-local scope != scope of the IP prefix. 

Making the link-local scope equal to the scope of the IP prefix in
NETLMM introduces multi-link subnet issues. Not doing so creates the
disparity I mention above, thereby not being compatible with regular
IPv6 node behaviors. 

p2p link-local behavior avoids both problems. 

Vidya

> What matters is the prefixes that are 
> link-local 
> > semantics". I agree that *full* shared link-local semantics 
> across the 
> > entire NETLMM domain would be an onerous scenario for large 
> domains, 
> > and I really don't see much value in it.
> 
> Good. This was not clear to me earlier. Now, the problem with 
> allowing shared link behavior is that a typical IPv6 node 
> expects the shared link to span the same topological scope as 
> its IPv6 prefix/address. However, that leads to multi-link 
> subnet issues in NETLMM, since, the IPv6 prefix of the MN is 
> spanning several links here. Having shared link semantics 
> limited to just the last link (between AR and MN) means you 
> have the network behaving differently from what the 
> applications and protocols on the MN expect from IPv6 link 
> local behavior.
> 
> reachability for link-local addresses exist due to the 
> unchanged IP prefix, even though the MN has switched links in 
> reality. In keeping with normal IP behavior, a prefix doesn't 
> span multiple links, while multiple prefixes may be present 
> on a given link. Hence this problem with NETLMM and 
> link-local semantics. 
> 
> Vidya
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Dec 2006 14:54:58 -0800

I don't get how you think this is any different for p2p
vs shared links - there are still multiple links in the
NETLMM domain in either case, yet the MN gets to keep its
address/prefix delegations as it moves from link to link.
As the MN moves from link to link, it loses its association
with its old neighbors and gains an association with new
neighbors. So, what do you think is different? And, what
do you think breaks?

Fred

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Wednesday, December 06, 2006 2:30 PM
To: Templin, Fred L; Pekka Savola
Cc: [email-masked]
Subject: RE: [netlmm] Link Local Addressing Semantics

Vidya

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Dec 2006 15:46:23 +0100

Templin, Fred L wrote:
> Vidya,
> 
> I don't get how you are getting from point A to point B here; shared
> links in a NETLMM domain do not in and of themselves cause multilink
> subnet. What matters is the prefixes that are advertised in RAs and
> which nodes receive those prefixes. Prefix-per-MN can still be done
> on shared links using unicast RAs, and RAs that carry no PIOs with
> 'A'=1 are also fine; MNs can just use DHCP to get address/prefix
> delegations.

Do we use stateless autoconf or dhcp.  In case stateless autoconf is not
used then no need to unicast the RA, just multicast it but don't put a
prefix in it.

> Also, IMO the term "multilink subnet" is increasingly being used
> loosely and in a pejorative way; shared links do not automatically
> mean multilink subnet.

I agree.  I think that until we have a sketch of the MN-AR protocol we
can't say whether it is affected by the multilink subnet issues or not.

Alex

> 
> Fred [email-masked]
> 
> -----Original Message----- From: Narayanan, Vidya
> [mailto:[email-masked]] Sent: Wednesday, December 06, 2006 1:57
> PM To: Templin, Fred L; Pekka Savola Cc: [email-masked] Subject: RE:
> [netlmm] Link Local Addressing Semantics
> 
> Hi Fred,
> 
>> scenario for large domains, and I really don't see much value in
>> it.
> 
> allowing shared link behavior is that a typical IPv6 node expects the
> shared link to span the same topological scope as its IPv6
> prefix/address. However, that leads to multi-link subnet issues in
> NETLMM, since, the IPv6 prefix of the MN is spanning several links
> here. Having shared link semantics limited to just the last link
> (between AR and MN) means you have the network behaving differently
> from what the applications and protocols on the MN expect from IPv6
> link local behavior.
> 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 7 Dec 2006 11:29:31 -0800

Fred,

> Sent: Wednesday, December 06, 2006 2:55 PM
> I don't get how you think this is any different for p2p vs 
> shared links - there are still multiple links in the NETLMM 
> domain in either case, yet the MN gets to keep its 
> neighbors. So, what do you think is different? And, what do 
> you think breaks?
> 

I think I've said this in the last couple of emails, but let me try to
describe it again. If the link-local semantics were always p2p
semantics, the upper layers on the MN never have any expectations on the
link-local reachability of neighbors to begin with and so, it doesn't
matter that the link changed while the MN kept the same prefix/address.
OTOH, if the link exhibited shared semantics for link-local and the link
changed, the upper layers' and applications' expectations on
reachability are really misplaced and that loses the benefits those
applications get from having a shared link in the first place. 

Without knowledge of the requirements to support shared link-local
behavior, we are having this discussion in a vaccuum and I'm afraid we
will not make any progress. So, I urge you to step back and talk about
the requirements before we can have further discussions. 

Thanks,
Vidya

> > subnet.
> I didn't say that shared links alone cause multi-link 
> subnets. There is a disparity between a) the expected 
> relationship between an IP prefix and link-local semantics 
> and b)the actual link-local semantics in a NETLMM domain when 
> link-local scope != scope of the IP prefix. 
> 
> Making the link-local scope equal to the scope of the IP 
> prefix in NETLMM introduces multi-link subnet issues. Not 
> doing so creates the disparity I mention above, thereby not 
> being compatible with regular
> IPv6 node behaviors. 
> 
> > What matters is the prefixes that are advertised in RAs and which 
> > nodes receive those prefixes.
> > Prefix-per-MN can still be done on shared links using 
> unicast RAs, and 
> > RAs that carry no PIOs with 'A'=1 are also fine; MNs can 
> just use DHCP 
> > to get address/prefix delegations.
> > 
> > shared link behavior is that a typical IPv6 node expects the shared 
> > link to span the same topological scope as its IPv6 prefix/address. 
> > However, that leads to multi-link subnet issues in NETLMM, 
> since, the 
> > IPv6 prefix of the MN is spanning several links here. Having shared 
> > link semantics limited to just the last link (between AR 
> and MN) means 
> > you have the network behaving differently from what the 
> applications 
> > and protocols on the MN expect from IPv6 link local behavior.
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 08 Dec 2006 12:20:27 +0100

Narayanan, Vidya wrote:
> Fred,
> 
>> -----Original Message----- From: Templin, Fred L
>> [mailto:[email-masked]] Sent: Wednesday, December 06,
>> 2006 2:55 PM To: Narayanan, Vidya; Pekka Savola Cc: [email-masked]
>> I don't get how you think this is any different for p2p vs shared
>> links - there are still multiple links in the NETLMM domain in
>> either case, yet the MN gets to keep its address/prefix delegations
>> as it moves from link to link. As the MN moves from link to link,
>> it loses its association with its old neighbors and gains an
>> association with new neighbors. So, what do you think is different?
>> And, what do you think breaks?
>> 
> 
> I think I've said this in the last couple of emails, but let me try
> to describe it again. If the link-local semantics were always p2p 
> semantics, the upper layers on the MN never have any expectations on
> the link-local reachability of neighbors to begin with and so, it
> doesn't matter that the link changed while the MN kept the same
> prefix/address.

I don't get it...

On a p2p link, one p is AR's interface.  If link changes, AR's interface
has changed too.  That is a neighbour to the first p, and has changed,
no longer reachable.

So, even if that's a p2p link, with p2p semantics, the second p has
changed upon link change, and applications may be influenced in their
expectations of presence of neighbours.  For one, it must do a new MLD
JOIN again.

> OTOH, if the link exhibited shared semantics for link-local and the
> link changed, the upper layers' and applications' expectations on 
> behavior, we are having this discussion in a vaccuum and I'm afraid
> we will not make any progress.

I think it's not useful  the try to justify the use p2p links by
expectations of how _some_ of those p2p links work.  We don't even know
what those p2p links are (IP tunnels, ppp, l2tp, etc).

Alex

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 Dec 2006 15:36:02 +0100

Hi Vidya,

On Wednesday 06 December 2006 02:46, Narayanan, Vidya 
wrote:
> Fred,
> Let's step back and answer one fundamental question
> - what is the requirement to have shared link-local
> semantics in a NETLMM domain? Without knowing the
> requirements, it is not feasible to figure out if

The requirement was to be able to support shared link 
technologies in the domain.

This hasn't have anything to do with semantic, it is a 
characteristic of the link: If I have an 802.11 BS w/o 
VLAN support linked to a NetLMM AR via a Ethernet, the 
link to which MNs attach is shared.

We can debate whether or not we want to support that 
scenario.

> More inline.

Ditto :)

> > From: Templin, Fred L
> > I don't think its fair to say that shared *links*
> > are necessarily "subject to multi-link subnet
> > issues",
>
> I was talking about shared link local semantics over
> multiple links, not shared links themselves.

Ah!

Then I don't see a value in emulating a single link 
over multiple links, if this what you were talking 
about.

> > (independently of shared/p2p links). But, I don't
> > think this is necessary to debate further for the
> > purpose of this discussion.
> >
> > > This seems to have an implicit assumption, i.e.,
> > > that when a host joins a shared link, AR/LMA
> > > will do Proxy ND on other links
> >
> > to ensure
> >
> > From what I understand, the proposal (which did
> > not come from me) is for a Relay-DAD service and
> > not a full RFC4389 ND Proxy, because RFC4389 is
> > incompatible with SEND in its current
> > manifestation. As I understand it, the proposed
> > Relay-DAD works as:
> >
> >   1) MAG receives MN's NS(DAD) and ships it to LMA
> > w/o decrementing Hop Limit
> >   2) LMA determines whether a colliding node
> > exists on another link, where the node could be
> > another MN or a MAG
> >   3) LMA ships NS(DAD) to MAG where colliding node
> > resides - again, w/o decrementing Hop Limit
> >   4) MAG transmits NS(DAD) on the link with the
> > colliding node, then ships the resulting NA(DAD)
> > along the reverse path to the originating MAG -
> > again, w/o decrementing Hop Limit
> >
> > As I understand it, the situation is the same for
> > both p2p and shared links, because the colliding
> > node could be a MAG that the MN might move onto at
> > some point in the future even if the links are
> > p2p. Maybe someone can confirm or correct my
> > understanding?
>
> In the p2p case, this can be fixed by just regular
> IPv6 behavior - if the MN realized the link change,
> it may do a DAD for the link-local address.

The issue is that in the link change might be detected 
using DNA. And that detection is based on subnet 
prefixes announced by ARs in RAs. In a NETLMM domain a 
MN implementing DNA would conclude that the link 
*never* change. By default it would then not redo DAD.

> If the LMA is the default router and all MAGs echo
> the RA from the LMA, the MN never sees a different
> link-local address. 

In this scenario the MAG isn't any longer a router, 
that is an IP layer "bridge". This has known issues 
with SEND (like proxy ND -- RFC4389)

To make that work with SEND, the LMA would have to 
announce the link layer address of the MAG in RAs. 
This looks pretty much as if the MAG is a ND proxy.

> OTOH, for shared link-local 
> semantics under the LMA, this type of proxy/relay
> DAD operation needs to occur, at least upon
> attachment to the NETLMM domain.

Right.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 Dec 2006 15:47:04 +0100

On Wednesday 06 December 2006 22:56, Narayanan, Vidya 
wrote:
> > Could be I have been confusing "shared links" with
> > "shared link-local semantics". I agree that *full*
> > shared link-local semantics across the entire
> > NETLMM domain would be an onerous scenario for
> > large domains, and I really don't see much value
> > in it.
>
> Good. This was not clear to me earlier. Now, the
> problem with allowing shared link behavior is that a
> typical IPv6 node expects the shared link to span
> the same topological scope as its IPv6
> prefix/address. 

I am not sure about the above. I'd rather say that an 
IPv6 node expects its IPv6 prefix/address to have a 
scope smaller or equal to the scope of the shared 
link. 

> However, that leads to multi-link 
> subnet issues in NETLMM, since, the IPv6 prefix of
> the MN is spanning several links here. 

I don't agree that the IPv6 prefix of the MN spans 
several links in that case. The IPv6 prefix of the MN 
follows the MN, and consequently spans only the link 
to which the MN is attached.

> Having shared 
> link semantics limited to just the last link
> (between AR and MN) means you have the network
> behaving differently from what the applications and
> protocols on the MN expect from IPv6 link local
> behavior.
>
> The upper layers on the MN may assume that the same
> level of reachability for link-local addresses exist
> due to the unchanged IP prefix, even though the MN
> has switched links in reality. 

If the upper layer relies on the IP prefix to assume 
link hasn't changed, it can as well uses global 
addresses to communicate and maintain reachability. 

Now it uses link-locals, and its correspondent moves to 
a *different* link, then yes reachability is broken as 
they're on different links.

> In keeping with normal IP behavior, a prefix doesn't
> span multiple links, while multiple prefixes may be
> present on a given link. Hence this problem with
> NETLMM and link-local semantics.

Maybe we'd first need to describe what a "normal IP 
behavior" is; Dave Thaler's draft does describe only 
part of the IP subnet model.

--julien

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 Dec 2006 15:52:16 +0100

On Wednesday 06 December 2006 23:30, Narayanan, Vidya 
wrote:
> > [mailto:[email-masked]] Sent:
> > Wednesday, December 06, 2006 2:17 PM To:
> > Narayanan, Vidya; Pekka Savola
> > Cc: [email-masked]
> > I don't get how you are getting from point A to
> > point B here; shared links in a NETLMM domain do
> > not in and of themselves cause multilink subnet.
>
> I didn't say that shared links alone cause
> multi-link subnets. There is a disparity between a)
> the expected relationship between an IP prefix and
> link-local semantics and b)the actual link-local
> semantics in a NETLMM domain when link-local scope
> != scope of the IP prefix.
>
> Making the link-local scope equal to the scope of
> the IP prefix in NETLMM introduces multi-link subnet
> issues. Not doing so creates the disparity I mention
> above, thereby not being compatible with regular
> IPv6 node behaviors.

multi-link subnet means that one subnet spans multiple 
links.

I.e. subnet scope > link scope, and not "link-local 
scope != scope of the IP prefix".

So maybe we don't have multilink subnet issues? Or 
maybe we're talking about something different from 
multilink subnet issues? Something like issues with 
"anormal IP behavior"... 

My 2 cents: Let's first talk about what constitutes a 
normal IP behavior.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 Dec 2006 15:56:58 +0100

On Thursday 07 December 2006 20:29, Narayanan, Vidya 
> Fred,

[...]

> I think I've said this in the last couple of emails,
> but let me try to describe it again. If the
> link-local semantics were always p2p semantics, the
> upper layers on the MN never have any expectations
> on the link-local reachability of neighbors

The upper layer on the MN do have an expectation on the 
link-local reachibility of the (sole) neighbor of the 
MN: its router.

Two ways to avoid that in p2p model: 

- The default router never change, it is the LMA
- The domain fake an unchanging default router, i.e. 
same link-local address and link-layer address on 
every MAG. Plus same public-private key pair in case 
SEND is used.

> to begin with and so, it doesn't matter that the link
> changed while the MN kept the same prefix/address.
> OTOH, if the link exhibited shared semantics for
> link-local and the link changed, the upper layers'
> and applications' expectations on reachability are
> really misplaced and that loses the benefits those
> Without knowledge of the requirements to support
> shared link-local behavior, we are having this
> discussion in a vaccuum and I'm afraid we will not
> make any progress. So, I urge you to step back and
> talk about the requirements before we can have
> further discussions.

The requirement is to support last hop links which are 
shared, and can't be turned into p2p links (e.g. 
802.11 w/o VLAN support)

--julien

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Dec 2006 01:17:49 +0200

> We can debate whether or not we want to support that 
Julien has a valid scenario to consider. I just don't have a
good sense of how valuable that scenario is for the WG.
Similarly, I see the issues that Vidya lists, but I'm not sure
how to judge how serious they are without going through
applications that might be making such assumptions.

However, I have a management observation -- we have
been discussing this topic for a long time, at least since
the summer. Is there a way ahead that would allow the
p2p model to go ahead while allowing the extended
link local scope model to follow later, in an extension?

--Jari

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Dec 2006 08:51:13 -0800

Jari,

> link local scope model to follow later, in an extension?

I agree that there has been a lot of energy spent in
disproving allegations that there is somehow something
wrong with shared links, and that energy IMHO would have
better been spent by just documenting the shared link
behavior and be done with it.

However, my use case would be satisfied by a compromise
position that says, e.g., "DHCP must be used on shared
links that cannot assign per-MN VLANs, while either DHCP
or SLAAC may be used on other links.".

Also, based on all of the hard work it is IMHO necessary
to do this now as opposed to wait for an extension, at
which point all of the hard work would have to be repeated.

Fred

---

From: Julien Laganier <[email-masked]>
Date: Tue, 12 Dec 2006 18:34:23 +0100

On Tuesday 12 December 2006 00:17, Jari Arkko wrote:
> Vidya wrote:
> > I think I've said this in the last couple of
> > emails, but let me try to describe it again. If
> > the link-local semantics were always p2p
> > semantics, the upper layers on the MN never have
> > any expectations on the link-local reachability of
> > neighbors to begin with and so, it doesn't matter
> > that the link changed while the MN kept the same
> > prefix/address. OTOH, if the link exhibited shared
> > semantics for link-local and the link changed, the
> > upper layers' and applications' expectations on
> > reachability are really misplaced and that loses
> > the benefits those applications get from having a
> > shared link in the first place.
> >
> > This hasn't have anything to do with semantic, it
> > is a characteristic of the link: If I have an
> > 802.11 BS w/o VLAN support linked to a NetLMM AR
> > via a Ethernet, the link to which MNs attach is
> > shared.
> >
> > We can debate whether or not we want to support
> > that scenario.
>
> Julien has a valid scenario to consider. I just
> don't have a good sense of how valuable that
> scenario is for the WG.

Neither do I :) 

My point was to distinguish between what is semantic 
and what is intrinsic of a link.

> Similarly, I see the issues 
> that Vidya lists, but I'm not sure how to judge how
> serious they are without going through applications
> that might be making such assumptions.
>
> been discussing this topic for a long time, at least
> since the summer. Is there a way ahead that would
> allow the p2p model to go ahead while allowing the
> extended link local scope model to follow later, in
> an extension?

As I tried to explain in couple of my messages on this 
list, I do not think that saying the link is p2p 
solves the problem with link local addresses. 

This is because the issue is unrelated to link local 
*scope*, but rather has to do with link local 
*uniqueness* in an architecture (NetLMM) where the 
link moves with the MN, and the other nodes on that 
link may change over time.

To help with this discussion, Dave Thaler suggested 
that I use the term "domain-wide address uniqueness" 
rather than "relay/proxy DAD" because people then 
think of proxy ND, and finally of multilink subnets.

So let me try to restate in those terms why is 
"domain-wide address uniqueness" needed in the NETLMM 
architecture, whether the link is p2p or shared (or 
whatever :)

In NETLMM, a moving MN is given the illusion that it 
doesn't move at the network layer, by being able to 
use a stable addres to communicate. 

The DNA working group has specified a protocol by which 
a MN is able to detect if it changed link or not, so 
that it can reconfigure its IP address when a link 
change did occur. This movement detection is based on 
changing subnet prefixes. 

Because in NetLMM the subnet prefix that the MN is 
using won't change, the MN will always conclude that 
it didn't changed link, and therefore keep its 
previous IP address.

Because after a movement the MN may happen to be on the 
same link that other nodes with colliding addresses, 
there is a problem. Using per-MN subnet prefixes 
restrict this problem to collision of link-local 
addresses.

Now, p2p or shared link, when the MN moves, there will 
be at least one new node on that link: the new access 
router. If the new AR has a link-local address that 
collides with the link-local of the MN, this is 
problem.

That's why we need to enforce "domain-wide link-local 
address uniquenes", p2p or shared links. 

A generic way of enforcing it is to register link-local 
at the anchor point (not for routing, just 
registration) so that upon initial attachment of a MN 
to a domain, when the MN does DAD, the AR can ask the 
anchor point if there's a collision. In case there's 
no, fine. In case there's, the AR can defend the link 
local on behalf of its legitimate owner.

Now if the link is p2p I see two other ways of 
enforcing link-local address uniqueness: 1) The access 
router (well the default router for a MN) is the LMA, 
therefore it never changes and there's no risk of 
post-movement collision. 2) All access routers in the 
domain use the same link-local address (which is 
somewhat an emulation of 1.) therefore there's no risk 
of post-movement collision.

IMO the solutions specific to p2p links are quite 
inelegant, so I do not see why we shouldn't go for the 
generic solution, which hasn't multilink subnet 
issues, neither modifies link local scope. 

Now coming back to support of shared links, I really 
have no strong opinion on the matter, but still I'd 
like to observe that giving up for shared link support 
doesn't make it easier to solve the issues with 
link-local uniqueness.

--julien

PS: Sorry for the long note!

-- "Je n'ai fait cette lettre-ci plus longue que parce 
que je n'ai pas eu le loisir de la faire plus courte." 
                                       -- Blaise Pascal

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 12 Dec 2006 10:20:20 -0800 (PST)

Hi Julien,

> architecture, whether the link is p2p or shared (or

I know, we discussed about this in the past.

With the p2p link assumption, the nodes on the link
are the AR and the MN. Now, to ensure link-local address
uniqueness on this link, as the AR keeps changing, establishing
Domain-Wide uniqueness is rather an expensive solution.
Even the odds of a 64 bit identifier collision are so low,
but the general IETF's argument, "but, what if there is a
collision". This is a killer argument and can't beat it.
Looking beyond, I still expect a normal IPv6 host to deal
with this correctly with out requiring a domain-wide
link-local address uniqueness.

- When the mobile moves to a different link, we are ensuring
the L3 properties, home prefix ..etc stay the same. however
the node detects a new neighbor and looses the old neighbor.
The current IPv6 host can correctly deal with this. When the
node detects a link change, the interface flaps or shuts off
and comes up and thus triggering the DAD procedure. If there
is a link-local address collision with the new neighbor,
the mobile will correctly detect it. Now, if you bring the
DNAv6 in to this, there is a possibility the mobile will not
do DAD, if the L3 network properties remain the same, after
the link change. DNAv6 is a draft and secondly as you have
pointed out earlier, there are protocol config parameter for
controlling that behaviour.

or

- There are other ways such as assigning a special link-local
address for all the PMA's in the network. If a mobile configures
this special link-local address, the network treats this as
a misconfiguration.

There are other ways to solve this issue. The ND can provide
semantics for triggering a node to do DAD operation on a ad-hoc
basis. Such semantics can be used by the AR to trigger a newly
attached mobile node to force DAD operation. All of these
can come as extensions with out having any impact on the
current solution. IMHO, the base draft should be simple and
all the extensions for extensive link-local scope etc can come
later. Otherwise, we can never converge on this. My 2c.

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Dec 2006 10:38:27 -0800

I don't see anything in these last two that say p2p links
are *good* and shared links (w/o VLANs) are *bad*. Can we
put that much to rest?

Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 12 Dec 2006 10:45:43 -0800 (PST)

> are *good* and shared links (w/o VLANs) are *bad*. Can we

This is just about  scoping the work. Start with p2p
link assumption and extend it to shared links.

<snip from other email>

> links that cannot assign per-MN VLANs, while either DHCP

This can work too, if this is as simple as this.

Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Dec 2006 10:50:35 -0800

> link assumption and extend it to shared links.

Shared links do not bring complicating factors in terms
of the link-local uniqueness requirments, so they need
not be treated as second-class citizens.

> This can work too, if this is as simple as this.

I don't know of any reason why it wouldn't be; do you?

Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 12 Dec 2006 10:59:52 -0800 (PST)

> not be treated as second-class citizens.

Our view is that, this can be covered in an extension doc.
That way, we dont tie the main draft for ever with all
the details.

> I don't know of any reason why it wouldn't be; do you?

Not sure.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Dec 2006 11:06:43 -0800

> That way, we dont tie the main draft for ever with all

Can you give an example of what details would be
needed, because I can't think of any?

> I don't know of any reason why it wouldn't be; do you?

I'm not sure what you're not sure about. And, if you
are not sure, is it appropriate to be casting doubt?

Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 12 Dec 2006 12:07:40 -0800 (PST)

> are not sure, is it appropriate to be casting doubt?

Its not about casting doubts, trying to scope the work
and focus on most common use cases. If we address the
p2p scenario, other bodies like 3GPP2 or 3GPP can leverage
this as well, as some one commented on this mailing list
before. Later some one can extend this and address
the shared link scenario in entirity. Its just about the
document management for faster convergence. Any case, I
will discuss about this with other authors on this. Thanks !

Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Dec 2006 13:01:22 -0800

Hi Sri,

> will discuss about this with other authors on this. Thanks !

This is not targeted at you in particular, but if we
are being told that there is somehow something broken or
overly-complicated about shared links (which is what some
have been saying and/or implying) then that is  a technical
argument that needs to be challenged. But, if instead it is
just that there is a desire to intentionally leave shared
links out for whatever reason then that cannot be challenged
on a technical basis.

I am personally skeptical about a follow-on extension
document ever getting off the ground let alone making
progress. How would the rechartering be done? What would
happen if the working group simply decided to shut down
after the base document got out the door? How would all
of the hard work that has gone on over the past several
months in this working group be served? I appreciate your
offer to bring this up with co-authors, because it is very
difficult to get new efforts off the ground in the IETF
and I somehow doubt that a: "maybe we'll get to this
later" approach would ever produce any results.

Thanks - Fred

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 12 Dec 2006 16:07:01 -0800

All,
Let me try to summarize what has been under discussion in this thread
and propose some next steps. 

Summary: 
--------
* The motivation for shared link support is to allow the last hop to be
an ethernet/802.11-like link with no VLAN support. 

* There is no desire to have shared link-local semantics across the
entire NETLMM domain; the desire is only to allow last-hop shared links
between the MN and AR. 

* Support for shared last-hop links makes the link-local scope smaller
than the IPv6 prefix scope in the NETLMM domain, which is potentially
problematic for applications on normal IPv6 end nodes that use
link-local addresses. Such applications are typically not run over
point-to-point links, hence making the issue applicable only to the
shared link case. 

Next Steps: 
-----------

I propose continuing to explore the support for shared links offline and
feeding the results into the protocol and MN-AR documents when we work
it out. In the meantime, let's make progress on the documents for the
p2p case. At this point, I am not concluding whether or not shared links
should be part of the first pass protocol - it is difficult to make that
decision until we have understood the implications of shared links in
NETLMM on applications. If we determine that there is no significant
implication, it should be easy to add the last-hop shared link support
to the documents. If not, we have to evaluate the situation then to see
if it is worth supporting such a model. 

I am currently soliciting input from some APP area and IPv6 folks to get
clarity on this issue. Once I get some information, I will feed it back
to the group and also start a more extended offlist discussion on the
topic. 

I hope that this is an acceptable way to move forward, in the interest
of making progress. Please let me know if this is not acceptable for
some reason. 

Thanks,
Vidya

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Dec 2006 16:36:06 -0800

Vidya,

> point-to-point links, hence making the issue applicable only to the

You keep saying this, and still I don't see anything
"potentially problematic" that would not also be problematic
on a normal campus LAN. Suppose, e.g., the NETLMM domain
consisted of a single shared link to which all MNs attached.
There is no guarantee that the set of neighbors a MN sees at
time t0 will be the same as the set seen at time t1; indeed,
the two sets could be completely disjoint!

Applications that make assumptions about the persistence
of neighbors on the link are going to have troubles
regardless of the link type; that is why we have tools
like NUD. Forgive me for saying so, but this just looks
like more FUD being alleged against shared links. 

Fred

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Dec 2006 16:46:35 -0800

> point-to-point links, hence making the issue applicable only to the

This sounds good to me.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 12 Dec 2006 17:30:07 -0800

Fred, 

> Sent: Tuesday, December 12, 2006 4:36 PM
> To: Narayanan, Vidya; Sri Gundavelli
> Cc: [email-masked]
> Subject: RE: Discussion Summary and Next Steps (was RE: 
> [netlmm] Link Local Addressing Semantics)
> 
> Vidya,
> 
> Applications that make assumptions about the persistence of 
> neighbors on the link are going to have troubles regardless 
> of the link type; that is why we have tools like NUD. Forgive 
> me for saying so, but this just looks like more FUD being 
> alleged against shared links. 
> 

The two scenarios you compare above have some similarities, but also
have some important differences. One causes a link-local neighbor to be
unreachable to the MN because the neighbor is no longer on the link
(normal IPv6 case); the other causes all link-local neighbors to be
unreachable to the MN because the MN is no longer on the link (NETLMM
case). The latter scenario in a regular IPv6 case is not a problem,
since the upper layers of the MN know that the link changed, since the
prefix also changed. The problem in NETLMM arises because the upper
layers of the MN think that the link has not changed, while the link
changed in reality. 

One example of such an application is the Apple Bonjour/rendezvous stuff
- I am not an expert on it, but it appears to use link-local addressing
- the SRV records it uses stores v4 or v6 link locals. Bonjour is widely
deployed even outside of Apple, especially in printers and similar
devices. A host wouldn't expect printers to disappear from the link,
unless in the case of a failure, which is not a typical case. OTOH, if
the upper layers of the host know the link changed, they would not
expect connectivity to link-local addresses of such devices that were on
it's previous link. 

As I said, let's get more input from the applications aspect from the
larger IETF community and go from there. Meanwhile, let's continue
making progress here with the protocol and other aspects. 

Thanks,
Vidya

---

From: Jun Lei <[email-masked]>
Date: Wed, 13 Dec 2006 11:23:40 +0100

Hi, all:
 
       PMIPv6 seems to be a very promising network-based solution.
 
       Anyway, we still need to make efforts on clarifying some unclear mechanisms for PMIPv6 specification. Likely, the deployment of Proxy in access networks will be one of the focuses. Another is about the intra-/inter-domain handover (e.g., in addition to local movement, global mobility is also a kind of consideration). Is that right?
 
 Cheers
 
 Jun

>>>* Support for shared last-hop links makes the link-local 
>>>      
>>>
>>scope smaller 
>>    
>>
>>>than the IPv6 prefix scope in the NETLMM domain, which is 
>>>      
>>>
>>potentially 
>>    
>>

-- 
Jun Lei
PhD Student

Address:
Georg-August-Universitaet Goettingen
Institut fuer Informatik
Telematics Group
Lotzestrasse 16-18
37083 Goettingen 

Fax: +49 (551) 39-1 44 03
Tel: +49 (551) 39-1 35 78

Email: [email-masked]

---

From: <[email-masked]>
Date: Wed, 13 Dec 2006 11:52:31 -0600

>Summary: 
>--------
>* The motivation for shared link support is to allow the last 
>hop to be an ethernet/802.11-like link with no VLAN support. 
>
>* There is no desire to have shared link-local semantics 
>across the entire NETLMM domain; the desire is only to allow 
>last-hop shared links between the MN and AR. 
>
>* Support for shared last-hop links makes the link-local scope 
>smaller than the IPv6 prefix scope in the NETLMM domain, which 
>is potentially problematic for applications on normal IPv6 end 
>nodes that use link-local addresses. Such applications are 
>typically not run over point-to-point links, hence making the 
>issue applicable only to the shared link case. 
>
I have a couple of issues with this summary.

- There is a lot of speculation about how applications use link-local
  addresses. I don't think any application that are using link-local
  addresses today are equipped to handle mobility or even expected
  to work with mobility. So, exploring examples to justify this does
  not make sense to me.

- There are problems with P2P model (link-local address collisions)
  also with link-local address and mobility which was not mentioned
  here.

Though i am personally fine with working on P2P first, i am beginning
to feel that this may not be really that important or at least i have
not seen convincing arguments that this needs the most attention from
the working group at this stage. I guess there are other things to look
at and for now, i would ignore the issue and start focusing on the
real protocol issues.

2 cents
mohan

>Next Steps: 
>-----------
>
>I propose continuing to explore the support for shared links 
>offline and feeding the results into the protocol and MN-AR 
>documents when we work it out. In the meantime, let's make 
>progress on the documents for the p2p case. At this point, I 
>am not concluding whether or not shared links should be part 
>of the first pass protocol - it is difficult to make that 
>decision until we have understood the implications of shared 
>links in NETLMM on applications. If we determine that there is 
>no significant implication, it should be easy to add the 
>last-hop shared link support to the documents. If not, we have 
>to evaluate the situation then to see if it is worth 
>supporting such a model. 
>
>I am currently soliciting input from some APP area and IPv6 
>folks to get clarity on this issue. Once I get some 
>information, I will feed it back to the group and also start a 
>more extended offlist discussion on the topic. 
>
>I hope that this is an acceptable way to move forward, in the 
>interest of making progress. Please let me know if this is not 
>acceptable for some reason. 
>
>Thanks,
>Vidya
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 14 Dec 2006 17:26:58 +0100

Hi Sri,

On Tuesday 12 December 2006 19:20, Sri Gundavelli 
wrote:
> > As I tried to explain in couple of my messages on
> > this list, I do not think that saying the link is
> > p2p solves the problem with link local addresses.
> >
> > This is because the issue is unrelated to link
> > local *scope*, but rather has to do with link
> > local *uniqueness* in an architecture (NetLMM)
> > where the link moves with the MN, and the other
> > nodes on that link may change over time.
> >
> > To help with this discussion, Dave Thaler
> > suggested that I use the term "domain-wide address
> > uniqueness" rather than "relay/proxy DAD" because
> > people then think of proxy ND, and finally of
> > multilink subnets.
> >
> > "domain-wide address uniqueness" needed in the
> > NETLMM architecture, whether the link is p2p or
> > shared (or whatever :)
>
> are the AR and the MN. Now, to ensure link-local
> address uniqueness on this link, as the AR keeps
> changing, establishing Domain-Wide uniqueness is
> rather an expensive solution. 

I do not agree that is an expensive solution. 

The HA needs to maintain a list of link-local addresses 
in use by MNs in the domain.

Then when the AR sends a ProxyBU to the HA, it would 
include the link-local address of the MN in a new 
option. 

Upon reception of a ProxyBU for which no binding exists 
yet, the HA will search the list of link-local 
addresses already registered for the enclosed 
link-local address. If it founds an entry (i.e. the 
link-local address is already in use by a different 
MN) it will reply to the AR with a Binding Error 
message. If it doesn't found an entry then it will 
continue processing the ProxyBU before eventually 
creating a binding entry.

Upon reception of a ProxyBU for which a binding already 
exists, no further processing of the link-local 
address option would be required since link-local 
address uniqueness has already been checked upon 
initial binding creation.

> Even the odds of a 64 bit identifier collision are so
> low, but the generalIETF's argument, "but, what if
> there is a collision". This is a killer argument and
> can't beat it.
>
> Looking beyond, I still expect a normal IPv6 
> host to deal with this correctly with out requiring
> a domain-wide link-local address uniqueness.

Your expectations seems to differs from IPv6 and DNA WG 
(see below.)

> - When the mobile moves to a different link, we are
> ensuring the L3 properties, home prefix ..etc stay
> the same. however the node detects a new neighbor
> and looses the old neighbor. The current IPv6 host
> can correctly deal with this. When the node detects
> a link change, the interface flaps or shuts off and
> comes up and thus triggering the DAD procedure.
> If there is a link-local address collision with the
> new neighbor, the mobile will correctly detect it. 

If the interface goes down and up very quickly, how do 
you determine if you changed link or not without DNA. 
It is possible that a transient lost of connectivity 
occured while you're still attached to the same link. 
OTOH it is also possible that a link handover did 
occured and you'll have to reconfigure IP parameters.

The proper way to do that is to use DNA. Restarting DAD 
and the likes (MLD, router discovery) would make the 
handover slow. That's why IETF chartered the DNA 
working group, to make it possible to quickly identify 
if the link changed or not.

> Now, if you bring the DNAv6 in to this, there is a
> possibility the mobile will not do DAD, if the L3
> network properties remain the same, after the link
> change. DNAv6 is a draft and secondly as you have 
> pointed out earlier, there are protocol config
> parameter for controlling that behaviour.

Which essentially defeats the whole purpose of DNA, 
which is to make handover faster (i.e. not redo DAD 
when link hasn't changed.)

> or
>
> - There are other ways such as assigning a special
> link-local address for all the PMA's in the network.
> If a mobile configures this special link-local
> address, the network treats this as a
> misconfiguration.

But that is indeed *additional* complexity to PMIP: 
You'd need a mechanism to convey this unique special 
link-local to all the PMAs in the domain. 

> There are other ways to solve this issue. The ND can
> provide semantics for triggering a node to do DAD
> operation on a ad-hoc basis. Such semantics can be 
> used by the AR to trigger a newly attached mobile 
> node to force DAD operation. 

What does "on a ad-hoc basis" mean? 

And how? Do you mean updating RFC2461/2462? It happened 
already and the bis versions are going to draft 
standard.

> All of these can come as extensions with out having
> any impact on the current solution. IMHO, the base
> draft should be simple and all the extensions for
> extensive link-local scope etc can come later.

Do you mean that it is an extension to PMIPv6 to design 
mechanisms that allows it to work with IPv6?

Sure the base draft should be as simple as possible, 
yet it should not change what's expected by IPv6 nodes 
(we have extensive "no host involvement" in our PS and 
REQ drafts.) As "someone" once said:

   So einfach wie möglich. Aber nicht einfacher.

And again, this is unrelated to "extensive link-local 
scope" as you put it. This has to do with "link-local 
uniqueness".

> Otherwise, we can never converge on this. My 2c.

IMHO, convergence on something that doesn't fit with 
other IPv6 specs has no value: we'll get halted in 
IETF LC or IESG. My 2c :)

Best,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 14 Dec 2006 10:01:49 -0800 (PST)

Hi Julien,

> initial binding creation.

HA3---------HA4
        | 
HA1---[AR]--HA2

In the above scenario, when the AR is serving nodes anchored
at HA1, HA2, HA3, HA4, how does the link-local address
resolution work. Would each HA know about all the link-local
addresses of the mobiles in the other HA's ? So, its not just
as simple as maintaining a list at each HA. That works, if the
assumption is that there is only one HA in the proxy domain.
If you expect the AR to send PBU' to each of the HA's in
the domain, that have visitors from, it is indeed a very
expensive solution.

I'm not saying, this should not be solved later. Step#1,
lets have the base with a p2p link assumption and go
forward. With the current IPv6 hosts (no DNAv6 draft),
the DAD procedure will get trigerred correctly and the
link-local address issue on that p2p link won't be there.
Or, lets allocate a special link-local address for all
AR's in the PMIP domain and that will address your concerns
about not supporting hosts supporting DNAv6 draft.

Step#2, we can focus on domain-wide DAD or what ever is
required, while solving the shared link scenario's.

Some other comments below.

Regards
Sri

> link-local to all the PMAs in the domain.

Its about one time provisioning prior to the service
deployment.

> What does "on a ad-hoc basis" mean?

On a need basis. If the network (AR) detects that a
given node needs to DAD, it should have a sementic to
trigger that procedure. This can come out orthogonal
to 2461 or PMIP. If 2461bis is already done, it can
be a new draft.

>   So einfach wie möglich. Aber nicht einfacher.

:) I'll have to ask some one to translate this ..or may
be google language tool.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 14 Dec 2006 10:57:33 -0800

Folks,
Perhaps I'm missing the intent of this thread - but, why are we discussing domain-wide link local uniqueness? I thought that we have settled on the fact that even if shared link-local semantics are supported, it will only be supported on the last hop between the MN and AR. Domain-wide link-local behavior gets into multi-link subnet issues and I don't think we should be doing that now or later. 

Vidya 

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Thursday, December 14, 2006 10:02 AM
> To: Julien Laganier
> Cc: [email-masked]
> Subject: [netlmm] Re: Domain-wide Link-Local Address 
> Uniqueness (Was: Link Local Addressing Semantics)
> 
> 
> Hi Julien,
> 
> >> With the p2p link assumption, the nodes on the link are the AR and 
> >> the MN. Now, to ensure link-local address uniqueness on 
> this link, as 
> >> the AR keeps changing, establishing Domain-Wide uniqueness 
> is rather 
> >> an expensive solution.
> >
> > The HA needs to maintain a list of link-local addresses in 
> use by MNs 
> > in the domain.
> >
> > Then when the AR sends a ProxyBU to the HA, it would include the 
> > link-local address of the MN in a new option.
> >
> > Upon reception of a ProxyBU for which no binding exists yet, the HA 
> > will search the list of link-local addresses already registered for 
> > the enclosed link-local address. If it founds an entry (i.e. the 
> > MN) it will reply to the AR with a Binding Error message. If it 
> > doesn't found an entry then it will continue processing the ProxyBU 
> > before eventually creating a binding entry.
> >
> > Upon reception of a ProxyBU for which a binding already exists, no 
> > further processing of the link-local address option would 
> be required 
> > since link-local address uniqueness has already been checked upon 
> as simple as maintaining a list at each HA. That works, if 
> the assumption is that there is only one HA in the proxy domain.
> If you expect the AR to send PBU' to each of the HA's in the 
> domain, that have visitors from, it is indeed a very 
> expensive solution.
> 
> I'm not saying, this should not be solved later. Step#1, lets 
> have the base with a p2p link assumption and go forward. With 
> the current IPv6 hosts (no DNAv6 draft), the DAD procedure 
> will get trigerred correctly and the link-local address issue 
> on that p2p link won't be there.
> Or, lets allocate a special link-local address for all AR's 
> in the PMIP domain and that will address your concerns about 
> not supporting hosts supporting DNAv6 draft.
> 
> >> Even the odds of a 64 bit identifier collision are so low, but the 
> >> generalIETF's argument, "but, what if there is a 
> collision". This is 
> with this 
> >> correctly with out requiring a domain-wide link-local address 
> >> uniqueness.
> >
> > Your expectations seems to differs from IPv6 and DNA WG (see below.)
> >
> ensuring the L3 
> >> properties, home prefix ..etc stay the same. however the 
> node detects 
> >> a new neighbor and looses the old neighbor. The current 
> IPv6 host can 
> >> correctly deal with this. When the node detects a link change, the 
> >> interface flaps or shuts off and comes up and thus 
> triggering the DAD 
> >> procedure.
> >> If there is a link-local address collision with the new 
> neighbor, the 
> >> mobile will correctly detect it.
> >
> > If the interface goes down and up very quickly, how do you 
> determine 
> > if you changed link or not without DNA.
> > It is possible that a transient lost of connectivity occured while 
> > you're still attached to the same link.
> > OTOH it is also possible that a link handover did occured 
> and you'll 
> > have to reconfigure IP parameters.
> >
> > The proper way to do that is to use DNA. Restarting DAD and 
> the likes 
> > (MLD, router discovery) would make the handover slow. 
> That's why IETF 
> > chartered the DNA working group, to make it possible to quickly 
> > identify if the link changed or not.
> >
> >> Now, if you bring the DNAv6 in to this, there is a possibility the 
> >> mobile will not do DAD, if the L3 network properties 
> remain the same, 
> >> after the link change. DNAv6 is a draft and secondly as you have 
> > Which essentially defeats the whole purpose of DNA, which 
> is to make 
> > handover faster (i.e. not redo DAD when link hasn't changed.)
> >
> >> or
> >>
> >> If a mobile configures this special link-local address, 
> the network 
> >> treats this as a misconfiguration.
> >
> Its about one time provisioning prior to the service deployment.
> 
> 
> 
> >> attached mobile node to force DAD operation.
> >
> On a need basis. If the network (AR) detects that a given 
> node needs to DAD, it should have a sementic to trigger that 
> procedure. This can come out orthogonal to 2461 or PMIP. If 
> 2461bis is already done, it can be a new draft.
> 
> 
> 
> > And how? Do you mean updating RFC2461/2462? It happened already and 
> > the bis versions are going to draft standard.
> >
> >> All of these can come as extensions with out having any 
> impact on the 
> >> current solution. IMHO, the base draft should be simple 
> and all the 
> >> extensions for extensive link-local scope etc can come later.
> >
> > Do you mean that it is an extension to PMIPv6 to design mechanisms 
> > that allows it to work with IPv6?
> >
> > Sure the base draft should be as simple as possible, yet it 
> should not 
> > change what's expected by IPv6 nodes (we have extensive "no host 
> > involvement" in our PS and REQ drafts.) As "someone" once said:
> >
> :) I'll have to ask some one to translate this ..or may be 
> google language tool.
> 
> 
> > And again, this is unrelated to "extensive link-local scope" as you 
> > put it. This has to do with "link-local uniqueness".
> >
> > IMHO, convergence on something that doesn't fit with other 
> IPv6 specs 
> > has no value: we'll get halted in IETF LC or IESG. My 2c :)
> >
> > Best,
> >
> > --julien
> >
>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 14 Dec 2006 11:12:35 -0800 (PST)

Vidya,

Thanks for the clarification. It is not currently
required in p2p scenario and that's my point. The
scenario clarifies the complexity of establishing
a domain-wide uniqueness and that its not a maintance
of a list on the HA as Julien pointed out. Now to my
comment, we can do that later, I will take that back.
We can revisit that later and I'll leave it at that.

Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Dec 2006 15:22:06 -0800

Why not just have RAs on shared links include a PIO with
'A' and 'L' = 0 as a landmark prefix for the link so MNs
will be able to detect link change at L3?

Fred

---

From: Julien Laganier <[email-masked]>
Date: Fri, 15 Dec 2006 09:45:22 +0100

Hi Vidya,

On Thursday 14 December 2006 19:57, Narayanan, Vidya 
wrote:
> Folks,
> Perhaps I'm missing the intent of this thread - but,
> why are we discussing domain-wide link local
> uniqueness?

Probably you missed that message of mine:

<http://www1.ietf.org/mail-archive/web/netlmm/current/msg01157.html>

Which explains why in NETLMM domain-wide link local 
uniqueness needs to be enforced, whatever the 
carachetristci of the last-hop link (i.e. p2p or 
shared.)
 
> I thought that we have settled on the 
> fact that even if shared link-local semantics are
> supported, it will only be supported on the last hop
> between the MN and AR. Domain-wide link-local
> behavior gets into multi-link subnet issues and I
> don't think we should be doing that now or later.

No, no and no.

I think it is getting quite annoying that these 
"multi-link subnet issues" pops here and there without 
reason. Enforcing link-local uniqueness in the domain 
does not imply any of:

   - link-local scope spans more than onelink
   - one subnet spans more than one link
   - ... 

(If you really want to spot multi-link subnet issues, 
maybe the MIPv6 spec is the right place ;-)

--julien

> > Subject: [netlmm] Re: Domain-wide Link-Local
> > Address Uniqueness (Was: Link Local Addressing
> > Semantics)
> >
> >
> > Hi Julien,
> >
> > >> With the p2p link assumption, the nodes on the
> > >> link are the AR and the MN. Now, to ensure
> > >> link-local address uniqueness on
> >
> > this link, as
> >
> > > Then when the AR sends a ProxyBU to the HA, it
> > > would include the link-local address of the MN
> > > in a new option.
> > >
> > > Upon reception of a ProxyBU for which no binding
> > > exists yet, the HA will search the list of
> > > link-local addresses already registered for the
> > > enclosed link-local address. If it founds an
> > > entry (i.e. the link-local address is already in
> > > use by a different MN) it will reply to the AR
> > > with a Binding Error message. If it doesn't
> > > found an entry then it will continue processing
> > > the ProxyBU before eventually creating a binding
> > > entry.
> > >
> > > Upon reception of a ProxyBU for which a binding
> > > already exists, no further processing of the
> > > link-local address option would
> >
> > be required
> >
> > > since link-local address uniqueness has already
> > > been checked upon initial binding creation.
> >
> > HA3---------HA4
> >
> > HA1---[AR]--HA2
> >
> > In the above scenario, when the AR is serving
> > nodes anchored at HA1, HA2, HA3, HA4, how does the
> > link-local address resolution work. Would each HA
> > know about all the link-local addresses of the
> > mobiles in the other HA's ? So, its not just as
> > simple as maintaining a list at each HA. That
> > works, if the assumption is that there is only one
> > HA in the proxy domain. If you expect the AR to
> > send PBU' to each of the HA's in the domain, that
> > have visitors from, it is indeed a very expensive
> > solution.
> >
> > I'm not saying, this should not be solved later.
> > Step#1, lets have the base with a p2p link
> > assumption and go forward. With the current IPv6
> > hosts (no DNAv6 draft), the DAD procedure will get
> > trigerred correctly and the link-local address
> > issue on that p2p link won't be there.
> > Or, lets allocate a special link-local address for
> > all AR's in the PMIP domain and that will address
> > your concerns about not supporting hosts
> > supporting DNAv6 draft.
> >
> > Step#2, we can focus on domain-wide DAD or what
> > ever is required, while solving the shared link
> > scenario's.
> >
> > >> Even the odds of a 64 bit identifier collision
> > >> are so low, but the generalIETF's argument,
> > >> "but, what if there is a
> >
> > collision". This is
> >
> > >> a killer argument and can't beat it.
> > >>
> > >> host to deal
> > >> correctly with out requiring a domain-wide
> > >> correctly deal with this. When the node detects
> > >> a link change, the interface flaps or shuts off
> > >> and comes up and thus
> >
> > triggering the DAD
> >
> > >> procedure.
> > > It is possible that a transient lost of
> > > connectivity occured while you're still attached
> > > to the same link. OTOH it is also possible that
> > > a link handover did occured
> >
> > and you'll
> >
> > > chartered the DNA working group, to make it
> > > possible to quickly identify if the link changed
> > > or not.
> > >
> > >> Now, if you bring the DNAv6 in to this, there
> > >> is a possibility the mobile will not do DAD, if
> > >> the L3 network properties
> >
> > remain the same,
> >
> > >> after the link change. DNAv6 is a draft and
> > >> secondly as you have pointed out earlier, there
> > >> are protocol config parameter for controlling
> > >> that behaviour.
> > >
> > link-local address
> > >> for all the PMA's in the network.
> > >> address,
> > > But that is indeed *additional* complexity to
> > > PMIP: You'd need a mechanism to convey this
> > > unique special
> >
> > link-local to all
> >
> > > the PMAs in the domain.
> >
> > >> There are other ways to solve this issue. The
> > >> ND can provide semantics for triggering a node
> > >> to do DAD operation on a ad-hoc basis. Such
> > >> semantics can be used by the AR to trigger a
> > >> newly attached mobile node to force DAD
> > >> operation.
> > >
> > On a need basis. If the network (AR) detects that
> > a given node needs to DAD, it should have a
> > sementic to trigger that procedure. This can come
> > out orthogonal to 2461 or PMIP. If 2461bis is
> > already done, it can be a new draft.
> >
> > > And how? Do you mean updating RFC2461/2462? It
> > > happened already and the bis versions are going
> > > to draft standard.
> > >
> > > Do you mean that it is an extension to PMIPv6 to
> > > design mechanisms that allows it to work with
> > > IPv6?
> > >
> > > change what's expected by IPv6 nodes (we have
> > > extensive "no host involvement" in our PS and
> > :) I'll have to ask some one to translate this
> > : ..or may be
> >
> > google language tool.
> >
> > > And again, this is unrelated to "extensive
> > > link-local scope" as you put it. This has to do
> > > with "link-local uniqueness".
> > >

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Fri, 15 Dec 2006 11:28:54 +0100

Hi Mohan,

>   to work with mobility. So, exploring examples to justify this does

The question is if an application is required to "handle" mobility or
be aware of the IP layer mobility. In general I would say no.

However I agree that the particular case of applications using
link-local addresses is somehow problematic and can be seen as a
borderline case. They will not work even using Mobile IPv6, therefore
is this issue really in the scope of NETLMM work?

>   also with link-local address and mobility which was not mentioned

Could you please elaborate further on this please?

--Gerardo

---

From: Julien Laganier <[email-masked]>
Date: Fri, 15 Dec 2006 11:39:19 +0100

Hi Gerardo,

On Friday 15 December 2006 11:28, Gerardo Giaretta 
wrote:
> Hi Mohan,
>
> > >Summary:
> > >--------
> > >* The motivation for shared link support is to
> > > allow the last hop to be an ethernet/802.11-like
> > > link with no VLAN support.
> > >
> > >* There is no desire to have shared link-local
> > > semantics across the entire NETLMM domain; the
> > > desire is only to allow last-hop shared links
> > > between the MN and AR.
> > >
> > >* Support for shared last-hop links makes the
> > > link-local scope smaller than the IPv6 prefix
> > > scope in the NETLMM domain, which is potentially
> > > problematic for applications on normal IPv6 end
> > > nodes that use link-local addresses. Such
> > > applications are typically not run over
> > > point-to-point links, hence making the issue
> > > applicable only to the shared link case.
> >
> > - There is a lot of speculation about how
> > applications use link-local addresses. I don't
> > think any application that are using link-local
> > addresses today are equipped to handle mobility or
> > even expected to work with mobility. So, exploring
> > examples to justify this does not make sense to
> > me.
>
> The question is if an application is required to
> "handle" mobility or be aware of the IP layer
> mobility. In general I would say no.
>
> However I agree that the particular case of
> applications using link-local addresses is somehow
> problematic and can be seen as a borderline case.
> They will not work even using Mobile IPv6, therefore
> > - There are problems with P2P model (link-local
> > address collisions) also with link-local address
> > and mobility which was not mentioned here.
>

Which explains why in NETLMM domain-wide link local 
uniqueness needs to be enforced, whatever the 
characteristics of the last-hop link (i.e. p2p or 
shared.)

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 15 Dec 2006 12:39:52 +0100

Hi Vidya,

On Wednesday 13 December 2006 01:07, Narayanan, Vidya 
wrote:
> All,
> Let me try to summarize what has been under
> discussion in this thread and propose some next
> steps.

Let me disagree with the summary you made below. I 
won't comment the next steps since I think we first 
have to agree on what the problem is.

> Summary:
> --------
> * The motivation for shared link support is to allow
> the last hop to be an ethernet/802.11-like link with
> no VLAN support.
>
> link-local scope smaller than the IPv6 prefix scope
> in the NETLMM domain

How comes? My understanding is that:
   - the link-local scope spans one link.
   - the IPv6 prefix scope, in the per-MN prefix model,
     is limited to the MN since the MN only has 
     configured an interface with an address under that
     prefix.

Hence it rather seems that:

    link-local scope >= IPv6 prefix scope

which is exactly the opposite of what you're saying. I 
must be missing something....

> , which is potentially problematic for applications
> on normal IPv6 end nodes that use link-local
> addresses. Such applications are typically not run
> over point-to-point links, hence making the issue

I do not think it makes sense to categorize 
applications based on the link over which they run, 
and to draw out of that issues with specific types of 
links.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 15 Dec 2006 08:57:27 -0800 (PST)

Hi Julien,

> characteristics of the last-hop link (i.e. p2p or

I did not see your comments to my earlier mail. But, lets
agree or disagree on few things, this is more like a
summary. I want to make sure, others who are not following
the thread closely do not come to some incorrect conclusions
on this one minor issue.

1. Do you agree, when the MN-AR link is a p2p link and
if the mobile is not DNAv6-draft capable, there is no
issue of link-local address collision of the mobile with
the AR on the access link ?

2. In your opinion, we must assume the mobile is DNAv6
capable ? DNAv6 is still a draft.

3. Do you agree, if we configure a special link-local
address for all the PMA's in the PMIP domain, we have
a work around for this issue. And that will satisfy your
requirement#2 ?

4. In your opinion, configuring special link-local address is
a bad idea ? Why ?

5. Do you agree, on a p2p link, with the MN and AR being
the only two nodes, the odds of a 64 bit link-local address
identifier collision is extremly low and in fact most IP
hosts still use EUI-64 (MAC Address) based identifiers ????
However, I do realize, the solution must be perfect. But,
I want to agree upon the magnitude of this issue and if
we are spending more time than what is required on this one
minor issue.

Regards
Sri

---

From: <[email-masked]>
Date: Fri, 15 Dec 2006 12:02:36 -0600

>>
>> >Summary:
>> >--------
>> >* The motivation for shared link support is to allow the 
>last hop to 
>> >be an ethernet/802.11-like link with no VLAN support.
>> >
>> >entire NETLMM domain; the desire is only to allow last-hop shared 
>> >links between the MN and AR.
>> >
>> >smaller than the IPv6 prefix scope in the NETLMM domain, which is 
>> >potentially problematic for applications on normal IPv6 end nodes 
>> >that use link-local addresses. Such applications are typically not 
>> >run over point-to-point links, hence making the issue 
>applicable only 
>> >to the shared link case.
>> >
>The question is if an application is required to "handle" 
>mobility or be aware of the IP layer mobility. In general I 
>would say no.
>
>link-local addresses is somehow problematic and can be seen as 
>a borderline case. They will not work even using Mobile IPv6, 
>therefore is this issue really in the scope of NETLMM work?
>
In MIPv6 case, the MN discovers that the link has changed whereas
in NETLMM the MN discovers that link has not changed even though
it changed in reality.  AFAICT, the application stops working in
both cases because you used link-local addresses. The user
sees that the application stopped working but in MIPv6 case the user
can figure out that it stopped working because the node
changed the link whereas in the NETLMM case the user sees that
the node did not change links (at layer 3) but did change 
point-of-attachment at layer 2. Does it really matter ?

>Could you please elaborate further on this please?
Julien already sent a pointer.  

-mohan

>> the working group at this stage. I guess there are other things to 
>> look at and for now, i would ignore the issue and start focusing on 
>> the real protocol issues.
>>
>> 2 cents
>> mohan
>>
>>
>>
>>
>> >Next Steps:
>> >-----------
>> >
>> >I propose continuing to explore the support for shared 
>links offline 
>> >and feeding the results into the protocol and MN-AR 
>documents when we 
>> >work it out. In the meantime, let's make progress on the documents 
>> >for the p2p case. At this point, I am not concluding whether or not 
>> >shared links should be part of the first pass protocol - it is 
>> >difficult to make that decision until we have understood the 
>> >implications of shared links in NETLMM on applications. If we 
>> >determine that there is no significant implication, it 
>should be easy 
>> >to add the last-hop shared link support to the documents. 
>If not, we 
>> >have to evaluate the situation then to see if it is worth 
>supporting 
>> >such a model.
>> >
>folks to 
>> >get clarity on this issue. Once I get some information, I will feed 
>> >it back to the group and also start a more extended offlist 
>> >discussion on the topic.
>> >

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 15 Dec 2006 10:46:42 -0800 (PST)

Hi Mohan,

> Julien already sent a pointer.

I could summarize it below, on the discussions I had with Julien
on the issues related to the link local address collision on the
MN-AR P2P link. Can you please add to this summary, any other
points that are of contentious nature ? I want to make sure, we
identify all the issues around a MN-AR link, with P2P link
assumption.

Regards
Sri

---

From: <[email-masked]>
Date: Fri, 15 Dec 2006 18:44:05 -0600

>I could summarize it below, on the discussions I had with 
>Julien on the issues related to the link local address 
>collision on the MN-AR P2P link. Can you please add to this 
>summary, any other points that are of contentious nature ? I 
>want to make sure, we identify all the issues around a MN-AR 
>link, with P2P link assumption.
>
My point was that the summary was incomplete without stating the
problems with P2P links. Below, you are proposing a solution to
address the problem so that P2P links can be chosen as the
first step. I don't agree with what you are proposing below.
Before we answer those, we should ask some basic questions as
to why shared links are left out ? (whether completely or just in
the beginning does not matter).

Working group agreed on prefix-per MN model (i think) sometime back to
avoid multi-link subnet issues. This is completely orthogonal
to whether the link is shared or P2P. Lot of discussion happened
sometime back and not worth repeating. Though we chose the
prefix-per MN model, there are still problems with link-local
addressing semantics when it comes to P2P or shared links.

	- P2P has link-local address collision problem
	- Shared links seems to have problem with applications that
       use link-local addresses fails because it does not know that
       it moved to a new link (See my other responses in this
       thread).

So, we are leaving out shared links just for this reason ? Or 
I am missing something else ? Sure, you can find an *acceptable*
solution for P2P. But then one could argue that the issue with
shared links and link-local addresses is non-existent today and
you can always state the assumption clearly and move on which
would make no difference to any application that cares about
mobility.

-mohan

>Regards
>Sri
>
>
>
>
>>
>> I did not see your comments to my earlier mail. But, lets agree or 
>> disagree on few things, this is more like a summary. I want to make 
>> sure, others who are not following the thread closely do not come to 
>> some incorrect conclusions on this one minor issue.
>>
>> 1. Do you agree, when the MN-AR link is a p2p link and if the mobile 
>> is not DNAv6-draft capable, there is no issue of link-local address 
>> collision of the mobile with the AR on the access link ?
>>
>address for all 
>> the PMA's in the PMIP domain, we have a work around for this issue. 
>> And that will satisfy your
>> requirement#2 ?
>>
>> 4. In your opinion, configuring special link-local address is a bad 
>> idea ? Why ?
>>
>> 5. Do you agree, on a p2p link, with the MN and AR being the 
>only two 
>> nodes, the odds of a 64 bit link-local address identifier 
>collision is 
>> extremly low and in fact most IP hosts still use EUI-64 (MAC 
>Address) 
>> based identifiers ????
>> However, I do realize, the solution must be perfect. But, I want to 
>> agree upon the magnitude of this issue and if we are spending more 
>> time than what is required on this one minor issue.
>>
>>
>> Regards
>> Sri
>>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 16 Dec 2006 18:54:06 +0100

Hi Sri, please allow me to interfere.

> collision of the mobile with the AR on the access link ?

In principle, yes.  I agree no risk of link-local address collision on a
point-to-point link, the world is small there, only 2 points.

But it very much depends on the links these are.  If they're ppp IPv6
links, then the AR makes sure the link-local identifiers on each of the
links are unique, so indeed no issue.

If the point-to-point links are some form of tunnel (IP in IP) then
there's no standard way to decide their link-local addresses, so one
can't say about uniqueness.

If the point-to-point links are bluetooth PAN profile (p2p 'transformed'
into LAN) then all point-to-point end interfaces on the AR have the same
link-local address, derived from the unique hardware interface MAC
address, so the risk of duplicates could be high - a mobile self-assigns
itself AR's ll address so the AR can't assign it, so the other mobiles
can't communicate.

> 4. In your opinion, configuring special link-local address is a bad 

IMHO - no, not a bad idea.  But should be documented.  If it becomes
common practice then it should work.  How are the addresses derived,
etc.  This is in fact needed for many other things, for example sending
RAs over tunnels.

> 5. Do you agree, on a p2p link, with the MN and AR being the only two
>  nodes, the odds of a 64 bit link-local address identifier collision 
> is extremly low and in fact most IP hosts still use EUI-64 (MAC 
> Address) based identifiers ?

If we know on that p2p link what's the rule to assign link-local
addresses - then yes, I agree.  But an AR doing p2p links to its mobiles
won't have a MAC address for each of those p2p links, so something else
should be needed - if we know that then I can say I agree or not.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Mon, 18 Dec 2006 17:32:46 +0100

Hi Sri,

> > Which explains why in NETLMM domain-wide link
> > local uniqueness needs to be enforced, whatever
> > the characteristics of the last-hop link (i.e. p2p
> > or shared.)
>
> I did not see your comments to my earlier mail. But,
> lets agree or disagree on few things, this is more
> like a summary. I want to make sure, others who are
> not following the thread closely do not come to some
> incorrect conclusions on this one minor issue.

Sure.

> 1. Do you agree, when the MN-AR link is a p2p link
> and if the mobile is not DNAv6-draft capable, there
> is no issue of link-local address collision of the
> mobile with the AR on the access link ?

No I do not agree. The reaction of an IPv6 
implementation to a sequence of link_down / link_up 
events is unspecified.

> 2. In your opinion, we must assume the mobile is
> DNAv6 capable ? DNAv6 is still a draft.

Yes. DNAv6 has been devised for *mobile* hosts. So I'd 
expect that in the future most of the hosts will be 
DNAv6 enabled.

Yes it is still a draft, but so is your proposal. 

IMHO any IETF WG should coordinate appropriately with 
other WGs when there is a technical intersection 
between what they specify. Hence, since the DNAv6 
solution has been on the table for a while, I'd expect 
the charge of coordination to be on author of new 
drafts, i.e. 

> 3. Do you agree, if we configure a special
> link-local address for all the PMA's in the PMIP
> domain, we have a work around for this issue. And
> that will satisfy your requirement#2 ?

That should work, but it needs to be documented in the 
proposal (e.g. All PMA's in the PMIP domain MUST be 
configured with a single link-local address assigned 
to their interface exposed to mobile nodes.)

However it has some drawbacks which I am listing below 
as answer to your question number 4.:

> 4. In your opinion, configuring special link-local
> address is a bad idea ? Why ?

I would not be so strong as to say that it is bad idea. 
But it certainly has drawbacks, which should also be 
documented in the proposal. The drawbacks that come to 
my mind (there might be more) are:

- It is a hack :) i.e. an inelegant piece of the 
overall design put forth to solve a problem induced by 
interactions of the NETLMM architecture with DNAv6.

- Administrative burden to manually configure the 
link-local on each AR (otherwise one should design a 
mechanism to transport this unique link-local address 
from a central administrative point to each of the 
PMAs)

- When SEND is used, it requires to configure a single 
public-private key pair so that the link-local CGA 
derived from that pair is the same everywhere. This 
constitutes yet another administrative burden, 
complicated by its security implications:

   - If one of the AR is compromised, all of the SEND 
keys for other PMAs are compromised as well.

   - The transport of the public-private key pair to 
each of the PMAs must guarantee confidentiality and 
integrity of the key pair.

Maybe people on the list have other drawbacks in mind.

> 5. Do you agree, on a p2p link, with the MN and AR
> being the only two nodes, the odds of a 64 bit
> link-local address identifier collision is extremly
> low and in fact most IP hosts still use EUI-64 (MAC
> Address) based identifiers ???? 

So far, the design rationale w.r.t. address uniqueness 
has been not to rely on a supposed identifier 
uniqueness without explicit checking (c.f. DAD, PPP 
link-local assignment.) 

Sure we could decide it is different for NETLMM, but 
for that I'd need an explanation of what makes NETLMM 
different in that respect. I don't have that.

> However, I do realize, the solution must be perfect.
> But, I want to agree upon the magnitude of this issue
> and if we are spending more time than what is
> required on this one minor issue.

See above. If this issue is "minor" in NETLMM, we need 
to explain why.

Best,

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 18 Dec 2006 09:20:02 -0800

> implementation to a sequence of link_down / link_up 

I agree with Julien on this. There may be some perfect-world
scenario, e.g., all ARs advertise a "landmark" prefix for the
link and all MNs use the advertised landmarks to discover link
change. But, unless this is specified in some document that
is covered under IPv6 Node Requirements I don't see universal
support for it as likely in widely-deployed implementations.

> > However, I do realize, the solution must be perfect.

Where is it said that the solution "*must* be perfect"?
There are plenty of things that could go wrong resulting
in a dropped call that would be much more likely than an
undetected address collision occurring on the same link.
I don't see it possible for us to say that something is
"perfect", so we need to ask how good does it need to
be to be deemed "good enough"?

Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Dec 2006 09:21:13 -0800 (PST)

Hi Mohan,

> the beginning does not matter).

This list is for identifying the issues around p2p links and
the potential work arounds we have around them. If we will
support shared links or not, that decision should not have
any impact on this list.

> solution for P2P. But then one could argue that the issue with

Yes. There are not that many issues around it and we can converge
faster. Also, from the use cases, p2p links seem to be more common,
looking at PP2 and PP and so the desire to complete the base for
that model. Nothing stops the WG to extend support for shared links
later. Also, some people have concerns that some applications will
have issues in the shared link model and so for these two above
reasons, we wanted to skip shared links. However, Vidya is trying
to get some input from other WG's on this topic and if we get positive
feedback, we have no problem adding support for shared links and
offcourse with the per-mn prefix model and no split links.

Thanks
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Dec 2006 09:29:45 -0800 (PST)

Hi Alex,

Thanks for your response.

On Sat, 16 Dec 2006, Alexandru Petrescu wrote:

>>  1. Do you agree, when the MN-AR link is a p2p link and if the mobile is
>>  not DNAv6-draft capable, there is no issue of link-local address collision
>>  of the mobile with the AR on the access link ?
>

Ok.

>>  4. In your opinion, configuring special link-local address is a bad idea ?
>>  Why ?
>

Ok. Good to know, you are ok with this. So, we have this option. I agree,
this assignment can be done more generically as well.

Thanks
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Dec 2006 09:38:03 -0800 (PST)

Hi Julien,

> implementation to a sequence of link_down / link_up

Per, RFC2462 section 5.3. Identifies the events that
will trigger link-local address formation. One of the
event is interface reinitialization. This is more so
in P2P, all known implementations currently work
this way.

Ok.

> to their interface exposed to mobile nodes.)

Good to know, you are agreeing that this should work, with
some drawbacks.

> my mind (there might be more) are:

Sure. I agree, we can document the drawbacks.

Ok.

Thanks
Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 18 Dec 2006 13:34:12 -0800

Hi Julien,
It turns out I did miss the second half of that previous message of yours. Sorry about that - that led to the confusion between "Domain-wide Link-Local Address Uniqueness" and "Domain-wide Link-Local Behavior". 

I see that there has been a lot of further good discussion on this topic. I will try to continue from there, rather than starting from an older email. 

Thanks,
Vidya

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Friday, December 15, 2006 12:45 AM
> To: Narayanan, Vidya
> Cc: Sri Gundavelli; [email-masked]
> Subject: Re: [netlmm] Re: Domain-wide Link-Local Address 
> > Perhaps I'm missing the intent of this thread - but, why are we 
> > discussing domain-wide link local uniqueness?
> 
> uniqueness needs to be enforced, whatever the carachetristci 
> of the last-hop link (i.e. p2p or
> shared.)
>  
> > I thought that we have settled on the fact that even if shared 
> > link-local semantics are supported, it will only be 
> supported on the 
> > last hop between the MN and AR. Domain-wide link-local 
> behavior gets 
> > into multi-link subnet issues and I don't think we should be doing 
> > that now or later.
> 
> No, no and no.
> 
> I think it is getting quite annoying that these "multi-link 
> subnet issues" pops here and there without reason. Enforcing 
> link-local uniqueness in the domain does not imply any of:
> 
> (If you really want to spot multi-link subnet issues, maybe 
> the MIPv6 spec is the right place ;-)
> 
> --julien
> 
> > > Subject: [netlmm] Re: Domain-wide Link-Local Address Uniqueness 
> > > (Was: Link Local Addressing
> > > Semantics)
> > >
> > >
> > > Hi Julien,
> > >
> > > >> With the p2p link assumption, the nodes on the link are the AR 
> > > >> and the MN. Now, to ensure link-local address uniqueness on
> > >
> > > this link, as
> > >
> include the 
> yet, the 
> > > > HA will search the list of link-local addresses already 
> registered 
> > > > for the enclosed link-local address. If it founds an 
> entry (i.e. 
> > > > the link-local address is already in use by a different MN) it 
> > > > will reply to the AR with a Binding Error message. If 
> it doesn't 
> > > > found an entry then it will continue processing the 
> ProxyBU before 
> > > > eventually creating a binding entry.
> > > >
> exists, no 
> > > In the above scenario, when the AR is serving nodes 
> anchored at HA1, 
> > > HA2, HA3, HA4, how does the link-local address resolution work. 
> > > Would each HA know about all the link-local addresses of 
> the mobiles 
> > > in the other HA's ? So, its not just as simple as 
> maintaining a list 
> > > at each HA. That works, if the assumption is that there 
> is only one 
> > > HA in the proxy domain. If you expect the AR to send PBU' 
> to each of 
> > > the HA's in the domain, that have visitors from, it is 
> indeed a very 
> > > expensive solution.
> > >
> > > Step#1, lets have the base with a p2p link assumption and go 
> > > forward. With the current IPv6 hosts (no DNAv6 draft), the DAD 
> > > procedure will get trigerred correctly and the link-local address 
> AR's in the 
> > > PMIP domain and that will address your concerns about not 
> supporting 
> > > hosts supporting DNAv6 draft.
> > >
> > > Step#2, we can focus on domain-wide DAD or what ever is required, 
> > > while solving the shared link scenario's.
> > >
> > > >> Even the odds of a 64 bit identifier collision are so low, but 
> > > >> the generalIETF's argument, "but, what if there is a
> > >
> > > collision". This is
> > >
> > > >> correctly deal with this. When the node detects a link change, 
> > > >> the interface flaps or shuts off and comes up and thus
> > >
> > > triggering the DAD
> > >
> > > >> procedure.
> occured while 
> > > > you're still attached to the same link. OTOH it is also 
> possible 
> > > > that a link handover did occured
> > >
> > > and you'll
> > >
> > > >> Now, if you bring the DNAv6 in to this, there is a possibility 
> > > >> the mobile will not do DAD, if the L3 network properties
> > >
> > > remain the same,
> > >
> > > > PMIP: You'd need a mechanism to convey this unique special
> > >
> > > link-local to all
> > >
> > > > the PMAs in the domain.
> > >
> node needs 
> > > to DAD, it should have a sementic to trigger that procedure. This 
> > > can come out orthogonal to 2461 or PMIP. If 2461bis is 
> already done, 
> > > it can be a new draft.
> > >
> > > > And how? Do you mean updating RFC2461/2462? It happened already 
> > > > and the bis versions are going to draft standard.
> > > >
> > > > And again, this is unrelated to "extensive link-local scope" as 
> > > > you put it. This has to do with "link-local uniqueness".
> > > >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 18 Dec 2006 18:08:59 -0800

Hi Julien,
Please see inline.  

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Monday, December 18, 2006 8:33 AM
> To: Sri Gundavelli
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: Discussion Summary and Next Steps (was RE: 
> [netlmm] LinkLocalAddressing Semantics)
> 
> uniqueness needs 
> > > to be enforced, whatever the characteristics of the last-hop link 
> > > (i.e. p2p or shared.)
> >
> No I do not agree. The reaction of an IPv6 implementation to 
> a sequence of link_down / link_up events is unspecified.
> 
> Yes. DNAv6 has been devised for *mobile* hosts. So I'd expect 
> that in the future most of the hosts will be
> DNAv6 enabled.
> 
> IMHO any IETF WG should coordinate appropriately with other 
> WGs when there is a technical intersection between what they 
> specify. Hence, since the DNAv6 solution has been on the 
> table for a while, I'd expect the charge of coordination to 
> be on author of new drafts, i.e. 
> 

A documentation of interaction with DNA behavior is appropriate for the
MN-AR interface document. However, I don't think an inter-dependency
between NETLMM and DNA needs to be there for the protocol. 

> > And that will satisfy your requirement#2 ?
> 
> configured with a single link-local address assigned to their 
> interface exposed to mobile nodes.)
> 

Realistically, domain-wide uniqueness for link-local addresses is hard
to achieve and should be avoided. The synchronization problems that Sri
was mentioning are quite undesirable to have to deal with. Further, when
networks running both PMIP and MIP/HMIP are deployed, such
synchronization issues become even more undesirable. Having
infrastructure co-ordination of link-local addresses defeats one of the
main purposes of link-local addresses - being able to communicate
without the help of the infrastructure. 

We are left with two choices here for the p2p case - one where the ARs
all advertise the same link-local address (case under discussion) and
another where the LMA serves as the default router. The latter takes
away some of the advantages of having an all-IP network, since now, the
edge router functions are pushed to the core. It also potentially makes
functions like MLD router part of the LMA, rather than the AR - this is
not at all desirable in an IP network. So, the solution under discussion
here seems like the most viable choice to me. More notes on that below. 

> However it has some drawbacks which I am listing below as 
> answer to your question number 4.:
> 
> documented in the proposal. 

Sure. These should be documented. 

> The drawbacks that come to my 
> mind (there might be more) are:
> 
> - It is a hack :) i.e. an inelegant piece of the overall 
> design put forth to solve a problem induced by interactions 
> of the NETLMM architecture with DNAv6.
> 

I don't think this is a solution specifically introduced to solve the
interaction issues with DNA. Many systems that are likely to deploy
network-based mobility are sensitive to latency and over-the-air
messaging upon handoffs. So, a solution that requires discovery of a new
default router upon handoff will be unacceptable. 

It is not an ideal solution, but, considering the latency and messaging
needs of such systems, it is probably the best solution we have. 

> - Administrative burden to manually configure the link-local 
> on each AR (otherwise one should design a mechanism to 
> transport this unique link-local address from a central 
> administrative point to each of the
> PMAs)
> 

I don't think we need to state this as a drawback (we do need to state
the behavior clearly). This is not much different from knowing which LMA
to use. In a network where dynamic configuration upon boot-up is done,
this is one extra piece of information. For networks that already rely
on lot of manual configuration also, it is really the same thing. I
would also think that most networks have the capability of pushing
configuration out to ARs (not each AR needs to be separately
configured). 

> public-private key pair so that the link-local CGA derived 
> from that pair is the same everywhere. This constitutes yet 
> another administrative burden, complicated by its security 
> implications:
> 
>    - If one of the AR is compromised, all of the SEND keys 
> for other PMAs are compromised as well.
> 
>    - The transport of the public-private key pair to each of 
> the PMAs must guarantee confidentiality and integrity of the key pair.
> 

In my view, the above drawback with respect to SeND is the biggest
drawback of this solution. We need to make note of this clearly in the
document. Until multi-key SeND or SeND using some sort of group key is
available, the key needs to be shared across the ARs for this virtual
link-local address. 

With respect to possible AR compromise, we have a lot more to worry
about and document than just SeND :) 

> the only two 
> So far, the design rationale w.r.t. address uniqueness has 
> been not to rely on a supposed identifier uniqueness without 
> explicit checking (c.f. DAD, PPP link-local assignment.) 
> 
> Sure we could decide it is different for NETLMM, but for that 
> I'd need an explanation of what makes NETLMM different in 
> that respect. I don't have that.
> 

If we settle on the above solution, this should not be an issue, right? 

Vidya

> > But, I want to agree upon the magnitude of this issue and if we are 
> > spending more time than what is required on this one minor issue.
> 
> See above. If this issue is "minor" in NETLMM, we need to explain why.
> 
> Best,
> 
> --julien
>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Dec 2006 16:32:25 +0100

Hi Vidya,

I'm cutting through your message below to answer you 
questions:

On Tuesday 19 December 2006 03:08, Narayanan, Vidya 
wrote:
> > Yes. DNAv6 has been devised for *mobile* hosts. So
> > I'd expect that in the future most of the hosts
> > will be DNAv6 enabled.
> >
> > IMHO any IETF WG should coordinate appropriately
> > with other WGs when there is a technical
> > intersection between what they specify. Hence,
> > since the DNAv6 solution has been on the table for
> > a while, I'd expect the charge of coordination to
> A documentation of interaction with DNA behavior is
> appropriate for the MN-AR interface document.
> However, I don't think an inter-dependency between
> NETLMM and DNA needs to be there for the protocol.

My point was that if part of a solution (including the 
protocol) makes it impossible to run DNA, or requires 
change to DNA, then it should be sorted out by the 
proponent of that solution (hence the protocol), IMHO. 

Then I'd more or less agree with you: text on 
inter-dependency between NETLMM and DNA does not 
necessarily belongs to the protocol spec. It is 
entirely possible that this text can be part of the 
MN-AR interface, or even the DNA spec itself. 

However if the coordination between DNA and NETLMM also 
requires support from the protocol itself (as was the 
case with one of the method to avoid collision between 
MN and PMA's link-local addresses) then it should 
certainly be part of the protocol spec.

> > > link-local address for all
> >
> > > the PMA's in the PMIP domain, we have a work
> > > around for this issue. And that will satisfy
> > > your requirement#2 ?
> >
> > That should work, but it needs to be documented in
> > the proposal (e.g. All PMA's in the PMIP domain
> > MUST be configured with a single link-local
> > address assigned to their interface exposed to
> > mobile nodes.)
>
> Realistically, domain-wide uniqueness for link-local
> addresses is hard to achieve and should be avoided.

We might disagree on what realistically means w.r.t. 
domain-wide uniqueness for link-local addresses. 
Anyway...

> The synchronization problems that Sri was mentioning
> are quite undesirable to have to deal with. 

I'll reply to Sri in another note.

> Further, when networks running both PMIP and MIP/HMIP
> are deployed, such synchronization issues become even
> more undesirable. 

MIP/HMIP should not be impacted at all by NETLMM, since 
NETLMM will essentially hide intra-NETLMM-domain 
movements to MIP/HMIP implementations on the MNs.

So I don't see what makes this undesirable.

> Having infrastructure co-ordination of link-local
> addresses defeats one of the main purposes of
> link-local addresses - being able to communicate

My understaning of the main purpose of link-local 
addresses is different. I thought link-local addresses 
where not devised for general-purpose communication, 
but for configuration, discovery and bootstrapping 
processes, where a priori reachability cannot be 
assumed (e.g. address configuration / DHCP,  duplicate 
address detection, address resolution, router 
discovery, multicast listener discovery, etc.)

> We are left with two choices here for the p2p case -
> one where the ARs all advertise the same link-local
> address (case under discussion) and another where
> the LMA serves as the default router. 

Plus the case where we can enforce, by use of the 
protocol, link-local address uniqueness in the set 
(MN_i, AR_1, AR_2, ..., AR_n), i.e. we're only 
avoiding collisions between one MN and ARs of the 
domain. But let me discuss that issue with Sri in 
another note.

> The latter takes away some of the advantages of
> having an all-IP network, since now, the edge router
> functions are pushed to the core. 

The LMA is specialized network element anyway (not just 
an IP router.), so the network can still be all-IP, it 
is just that these edge functions will live in the LMA 
rather than on the AR. 

> It also potentially makes functions like MLD router
> part of the LMA, rather than the AR - this is not at
> all desirable in an IP network. 

I didn't investigate in details the implications on 
multicast to have the LMA be the default router. On a 
first spot I don't see much problems (i.e. multicast 
function couls stay on the edge) but probably that 
deserve much more attention (and another thread.)

> So, the solution under discussion here seems like the
> most viable choice to me. More notes on that below.
>
> > However it has some drawbacks which I am listing
> > below as answer to your question number 4.:
> >
> > > 4. In your opinion, configuring special
> > > link-local address is a bad idea ? Why ?
> >
> > I would not be so strong as to say that it is bad
> > idea. But it certainly has drawbacks, which should
> > also be documented in the proposal.
>

Ok.

> > overall design put forth to solve a problem
> > induced by interactions of the NETLMM architecture
> > with DNAv6.
>
> I don't think this is a solution specifically
> introduced to solve the interaction issues with DNA.
> Many systems that are likely to deploy network-based
> mobility are sensitive to latency and over-the-air
> messaging upon handoffs. So, a solution that
> requires discovery of a new default router upon
> handoff will be unacceptable.

But not discovering a new default router upon handoff 
presumably requires link-layer support. In such cases 
the link-layer can be designed to hide L2 handoff so 
such router discovery isn't required (i.e. the 
interface doesn't flap from L3 point-of-view so DNA 
isn't used.)

So on the contrary I do think this is introduced to 
deal specifically with scenarios where no such link 
layer support exists, therefore mandating DNA for 
as-smooth-as-possible handoff.
 
> It is not an ideal solution, but, considering the
> latency and messaging needs of such systems, it is
> probably the best solution we have.
>
> > link-local on each AR (otherwise one should design
> > a mechanism to transport this unique link-local
> > address from a central administrative point to
> > each of the
> > PMAs)
>
> I don't think we need to state this as a drawback
> (we do need to state the behavior clearly). This is
> not much different from knowing which LMA to use. In
> a network where dynamic configuration upon boot-up
> is done, this is one extra piece of information. For
> networks that already rely on lot of manual
> configuration also, it is really the same thing. I
> would also think that most networks have the
> capability of pushing configuration out to ARs (not
> each AR needs to be separately configured).

I think knowing which LMA to use is different from 
knowing which link-local address to configure on ARs. 

Knowing which link-local address to use is a pure 
configuration information. In contrast, finding a LMA 
can rely, in addition to configuration techniques, on 
discovery techniques such as anycast addressing, SRV 
records, etc.

> > - When SEND is used, it requires to configure a
> > single public-private key pair so that the
> > link-local CGA derived from that pair is the same
> > everywhere. This constitutes yet another
> > administrative burden, complicated by its security
> > implications:
> >
> >    - If one of the AR is compromised, all of the
> > SEND keys for other PMAs are compromised as well.
> >
> >    - The transport of the public-private key pair
> > to each of the PMAs must guarantee confidentiality
> > and integrity of the key pair.
>
> In my view, the above drawback with respect to SeND
> is the biggest drawback of this solution. We need to
> make note of this clearly in the document. Until
> multi-key SeND or SeND using some sort of group key
> is available, the key needs to be shared across the
> ARs for this virtual link-local address.

Ok.

> With respect to possible AR compromise, we have a
> lot more to worry about and document than just SeND
> :)
>
> > > 5. Do you agree, on a p2p link, with the MN and
> > > AR being the only two nodes, the odds of a 64 bit
> > > link-local address identifier collision is
> > > extremly low and in fact most IP hosts still use
> > > EUI-64 (MAC Address) based identifiers ????
> >
> > So far, the design rationale w.r.t. address
> > uniqueness has been not to rely on a supposed
> > identifier uniqueness without explicit checking
> > (c.f. DAD, PPP link-local assignment.)
> >
> > Sure we could decide it is different for NETLMM,
> > but for that I'd need an explanation of what makes
> > NETLMM different in that respect. I don't have
> > that.
>

Right.

Best,

--julien