Subject: [netlmm] Addressing Model Discussion Conclusion

From: "Roberts Phil-APR042" <[email-masked]>
Date: Wed, 9 Aug 2006 09:25:30 -0400

The WG has been discussing what kind of addressing model to use for
NETLMM for the past few weeks. It seems from the email like most people
favor the prefix per mobile node model over a shared link model, though
there is still a lack of shared understanding about the details of how
the prefix per mobile node model should be implemented. From the
discussion, it does seem though as if there are fewer technical issues
with using that model for the kinds of deployments that are envisioned
for NETLMM at least initially. Is there anybody at this time that has
any significant issues with making the prefix per mobile node the
default NETLMM model initially? 

Note that this does not preclude people bringing forth further work down
the line on the shared link model once we have the initial charter
complete and are ready to recharter. 

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Aug 2006 16:11:21 +0200

Hi Phil,

On Wednesday 09 August 2006 15:25, Roberts Phil-APR042 wrote:
> NETLMM for the past few weeks. It seems from the email like most
> people favor the prefix per mobile node model over a shared link
> model, though there is still a lack of shared understanding about
> the details of how the prefix per mobile node model should be
> implemented. 

My understanding of discussions that have happened so far is 
different. I thought we've discussed two different issues:

	- subnet prefix shared by all MNs in a domain vs. per-MN
	  subnet prefix (the latter to avoid multilink subnet issues.)

	- shared link (e.g. Ethernet) vs. point-to-point link (e.g. 
	  Cellular.)

So it seems people favors an approach in which a subnet prefix is 
assigned per MN, rather than shared by all MNs in the domain.

However I do not think we've discussed too much about the shared vs. 
point-to-point link issue. From what I remember Jari Arkko asked if 
we should not first concentrate on an approach that works for 
point-to-point, while Pekka Savola wanted us to consider WLAN 
scenarios.

> From the discussion, it does seem though as if there 
> are fewer technical issues with using that model for the kinds of
> deployments that are envisioned for NETLMM at least initially.

I agree (and yes that also seems to be the consensus in the WG) that 
the pre-MN subnet prefix has less issues, notably w.r.t. multilink 
subnets issues.

> Is there anybody at this time that has any significant issues with
> making the prefix per mobile node the default NETLMM model
> initially?

So to be clear:

	- I agree to base NetLMM on a per-MN subnet prefix (I do not see
          much value in having a subnet prefix shared amongst all MNs
          in the domain.) 

	- I don't think that it is necessary to rule out shared link at this
	  stage: So far, discussions on the INT area mailing list (in
	  particular input from Dave Thaler) haven't indicated that there
          is a major incompatibility between NetLMM with per-MN subnet
	  prefix and shared links.

Best,

--julien

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 9 Aug 2006 20:27:01 +0530

Hi,

When one or more unique prefixes are used per MN, MN and AR
should be on p2p link, So I am wondering how is this p2p link is
modeled. Is there a plan to use any p2p protocols below the IP layer
or it is assumed that the layer 2 provides a p2p connection so that
the AR sees each MN at different interface?

-Syam

On 8/9/06, Roberts Phil-APR042 <[email-masked]> wrote:
>
>
>
> The WG has been discussing what kind of addressing model to use for NETLMM
> for the past few weeks. It seems from the email like most people favor the
> prefix per mobile node model over a shared link model, though there is still
> a lack of shared understanding about the details of how the prefix per
> mobile node model should be implemented. From the discussion, it does seem
> though as if there are fewer technical issues with using that model for the
> kinds of deployments that are envisioned for NETLMM at least initially. Is
> there anybody at this time that has any significant issues with making the
> prefix per mobile node the default NETLMM model initially?
>
>
>
> Note that this does not preclude people bringing forth further work down the
> line on the shared link model once we have the initial charter complete and
> are ready to recharter.
>
>
>
>
>
>

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 9 Aug 2006 12:20:19 -0500

Hi Syan,

I think p2p link or shared link is independent of how the network prefix
will be assigned to the MT. In both shared and p2p we still could assign
a unique network prefix to the MT.

-----Original Message-----
From: Syam Madanapalli [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 9:57 AM
To: Roberts Phil-APR042
Cc: [email-masked]
Subject: Re: [netlmm] Addressing Model Discussion Conclusion

Hi,

When one or more unique prefixes are used per MN, MN and AR should be on
p2p link, So I am wondering how is this p2p link is modeled. Is there a
plan to use any p2p protocols below the IP layer or it is assumed that
the layer 2 provides a p2p connection so that the AR sees each MN at
different interface?

-Syam

On 8/9/06, Roberts Phil-APR042 <[email-masked]> wrote:
> model, though there is still a lack of shared understanding about the 
> details of how the prefix per mobile node model should be implemented.

> From the discussion, it does seem though as if there are fewer 
> technical issues with using that model for the kinds of deployments 
> that are envisioned for NETLMM at least initially. Is there anybody at

> this time that has any significant issues with making the prefix per 
> mobile node the default NETLMM model initially?
>
>
>
> Note that this does not preclude people bringing forth further work 
> down the line on the shared link model once we have the initial 
> charter complete and are ready to recharter.
>
>
>
>
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Aug 2006 10:26:35 -0700

I agree with Julien that shared/individual prefix and
shared/pt-2-pt link are two separate subjects.

About shared/individual prefix, that subject is already
covered under "Multilink Subnet Considerations" in
('draft-ietf-netlmm-mn-ar-if-01.txt', Section 5). I am
currently working on some new text for that section and
waiting for guidance on how to move forward with that.

Fred
[email-masked]   

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 7:11 AM
To: [email-masked]
Subject: Re: [netlmm] Addressing Model Discussion Conclusion

Hi Phil,

So to be clear:

	- I don't think that it is necessary to rule out shared link at
this
	  stage: So far, discussions on the INT area mailing list (in
	  particular input from Dave Thaler) haven't indicated that
there
          is a major incompatibility between NetLMM with per-MN subnet
	  prefix and shared links.

Best,

--julien

---

From: "James Kempf" <[email-masked]>
Date: Wed, 9 Aug 2006 10:39:38 -0700

Syam,

That is TBD. We are currently just attempting to get agreement on what the 
default addressing model should be, at least initially. There is currently 
an ongoing discussion about how to do the subnet to link mapping on the INT 
area list. The issue goes much further than NETLMM, as there are several 
other working groups grappling with the same problem.

            jak

----- Original Message ----- 
From: "Syam Madanapalli" <[email-masked]>
To: "Roberts Phil-APR042" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 09, 2006 7:57 AM
Subject: Re: [netlmm] Addressing Model Discussion Conclusion

>> NETLMM
>> the

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 09 Aug 2006 11:09:42 -0700

> a unique network prefix to the MT.

in a shared link, how do you restrict the MN to just
one prefix. the MN would would see all the prefixes.
a plain IPv6 MN may start configuring address from
all the prefixes it sees.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 9 Aug 2006 11:28:45 -0700

The same way it is done in RFC 3314.

            jak

---

From: "Syam Madanapalli" <[email-masked]>
Date: Thu, 10 Aug 2006 00:05:52 +0530

Hi Khalil,

If you are assigning one more unique prefixes on a shared link,
then the purpose of assigning unique prefix is lost as you
still need to do DAD for LLAs and will not be able to send multicast
RAs. It may be architecturally incorrect to have unique prefixes per
MN without p2p links.

- Syam

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 9 Aug 2006 12:11:45 -0700 (PDT)

Hi Phil,
  I think the charter envisages netlmm on various link types including 802.11 links.
  Because of this, the discussion on addressing model does not seem to make sense, at least to me.

Regards,

--behcet 

----- Original Message ----
From: Roberts Phil-APR042 <[email-masked]>
To: [email-masked]
Sent: Wednesday, August 9, 2006 8:25:30 AM
Subject: [netlmm] Addressing Model Discussion Conclusion

             The WG has been discussing what kind of addressing model to use for NETLMM for the past few weeks. It seems from the email like most people favor the prefix per mobile node model over a shared link model, though there is still a lack of shared understanding about the details of how the prefix per mobile node model should be implemented. From the discussion, it does seem though as if there are fewer technical issues with using that model for the kinds of deployments that are envisioned for NETLMM at least initially. Is there anybody at this time that has any significant issues with making the prefix per mobile node the default NETLMM model initially? 
     
   Note that this does not preclude people bringing forth further work down the line on the shared link model once we have the initial charter complete and are ready to recharter.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 9 Aug 2006 13:17:07 -0700

RFC3314 is meant for 3gpp networks, that have virtual p2p links with
each mobile. It is not written for regular shared links. 

Vidya 

> From: James Kempf [mailto:[email-masked]] 
> Sent: Wednesday, August 09, 2006 11:29 AM
> To: Vijay Devarapalli; Mohamed Khalil
> Cc: [email-masked]

---

From: Hugo Santos <[email-masked]>
Date: Wed, 9 Aug 2006 22:30:50 +0100

Hi Vijay,

> all the prefixes it sees.

    If the access routers don't multicast Router Advs isn't this  
issue resolved? The MN no longer "sees" the various prefixes on-link.  
The MN would only see the prefix that would be alloced to it  
specified by the access router via a unicast RA following a MN- 
originated Router Solicitation (possible loss-related problems  
here?). Also, L2-based information (and events) could be used to L2- 
unicast RAs to each of the attached terminals.

    Additionally, i remember someone mentioning that multicast usage  
in this setup wouldn't be possible, but although from a control point  
of view we could see a virtual p2p link between MN and AR in the  
shared medium, we could still see it as shared from a data-path POV.

    Hugo

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 09 Aug 2006 14:37:37 -0700

Hugo Santos wrote:
>    If the access routers don't multicast Router Advs isn't this issue 
> resolved? The MN no longer "sees" the various prefixes on-link. The MN 
> would only see the prefix that would be alloced to it specified by the 
> access router via a unicast RA following a MN-originated Router 
> Solicitation (possible loss-related problems here?). 

you would need to update router discovery. see section 6.2.6
of RFC 2461.

    A router MAY choose to unicast the
    response directly to the soliciting host's address (if the
    solicitation's source address is not the unspecified address), but
    the usual case is to multicast the response to the all-nodes group.

Vijay

---

From: Hugo Santos <[email-masked]>
Date: Thu, 10 Aug 2006 02:09:59 +0100

Vijay,

>    the usual case is to multicast the response to the all-nodes group.

   Yes, if we wanted to keep a single RA to signal all the information
 to the terminal (being a default router and prefix-information) then
 yes, to guarantee proper behavior this MAY would have to be changed to
 a MUST. I was considering changes to routers would be acceptable since
 we are already making some to accomodate for other stuff.  But there
 are alternatives; 2461 states that the router doesn't need to advertise
 all of the information in every RA, in fact "default router discovery"
 and "prefix discovery" are distinct things. The MN-alloced prefix is
 not a prefix to be used for auto-configuration in the context 2461 uses
 it, and as such doesn't need to be in the Prefix List sent to the
 all-nodes group. Within standard behaviour we could have the AR reply
 with a RA with potentialy no prefixes -- it just advertises itself as a
 default router. A NETLMM extension would then make the router generate
 an additional unicast RA to MN with the alloced prefix information. I
 think that a RS is also not necessary and that the router could react
 solely based on L2 events. This might not be compatible with DNA (using
 partial information), but if we are considering DNA, why not introduce
 (router-only) required changes to 2461?

   Let me know if i'm missing something,

      Hugo

---

From: Julien Laganier <[email-masked]>
Date: Thu, 10 Aug 2006 08:17:25 +0200

On Wednesday 09 August 2006 20:09, Vijay Devarapalli wrote:
> Mohamed Khalil wrote:
> > Hi Syan,
> >
> > I think p2p link or shared link is independent of how the network
> > prefix will be assigned to the MT. In both shared and p2p we
> > still could assign a unique network prefix to the MT.
>

Hi Vijay,

You would specify that a *NetLMM* AR doesn't send multicast RAs with 
prefix information. To convey the prefix information it would instead 
send to a given MN a unicast RA containing the subnet prefix it's 
been assigned with.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 10 Aug 2006 08:21:28 +0200

Hi Syam,

The purpose of asssigning a per-MN subnet prefix isn't to avoid DAD of 
LLAs (How could *global* prefix assignment possibly have an influence 
on *link-local* addresses collisions?)

In the NetLMM context asssigning a per-MN subnet prefix insures that 
no subnet prefix ever spans more than one link, thus avoiding 
multilink subnet issues as discussed in Dave Thaler's draft.

--julien

On Wednesday 09 August 2006 20:35, Syam Madanapalli wrote:
> still need to do DAD for LLAs and will not be able to send
> multicast RAs. It may be architecturally incorrect to have unique
> prefixes per MN without p2p links.
>
> - Syam
>
> > modeled. Is there a plan to use any p2p protocols below the IP
> > layer or it is assumed that the layer 2 provides a p2p connection
> > so that the AR sees each MN at different interface?
> >
> > -Syam
> >
> > > The WG has been discussing what kind of addressing model to use
> > > for NETLMM for the past few weeks. It seems from the email like
> > > most people favor the prefix per mobile node model over a
> > > shared link model, though there is still a lack of shared
> > > understanding about the details of how the prefix per mobile
> > > node model should be implemented.
> > >
> > > technical issues with using that model for the kinds of
> > > Is there anybody at
> > > this time that has any significant issues with making the
> > > Note that this does not preclude people bringing forth further
> > > work down the line on the shared link model once we have the
> > > initial charter complete and are ready to recharter.
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 10 Aug 2006 08:25:55 +0200

Hi Behcet,

As I explained in another note, having per-MN subnet prefix would 
avoid multilink subnet issues (which seems strongly desirable, to put 
it mildly.) 

I think it's okay to choose an addressing model as long as it is 
implementable on various link types. So far it seems that the per-MN 
subnet prefix model would be implementable on shared links, including 
802.11, so the discussion makes sense IMHO.

Best,

--julien

On Wednesday 09 August 2006 21:11, Behcet Sarikaya wrote:
> Hi Phil,
>   I think the charter envisages netlmm on various link types
> including 802.11 links. Because of this, the discussion on
> addressing model does not seem to make sense, at least to me.
>
> Regards,
>
> --behcet
>
>              The WG has been discussing what kind of addressing
> model to use for NETLMM for the past few weeks. It seems from the
> email like most people favor the prefix per mobile node model over
> a shared link model, though there is still a lack of shared
> understanding about the details of how the prefix per mobile node
> model should be implemented. From the discussion, it does seem
> though as if there are fewer technical issues with using that model
> for the kinds of deployments that are envisioned for NETLMM at
> least initially. Is there anybody at this time that has any
> significant issues with making the prefix per mobile node the

---

From: Julien Laganier <[email-masked]>
Date: Thu, 10 Aug 2006 08:30:27 +0200

Hi Vijay, 

More below,

On Wednesday 09 August 2006 23:37, Vijay Devarapalli wrote:
> > issue resolved? The MN no longer "sees" the various prefixes
> > on-link. The MN would only see the prefix that would be alloced
> > to it specified by the access router via a unicast RA following a
> > MN-originated Router Solicitation (possible loss-related problems
> > here?).
>
>     solicitation's source address is not the unspecified address),
>     but the usual case is to multicast the response to the all-nodes
>     group.

No we do not need to update router discovery / RFC2461. Per 2461 
sending unicast RAs is allowed (this is a MAY above) so we are 
allowed to do it, and we can specify in a NetLMM spec that a MAG MUST 
send unicast RAs.

--julien

---

From: "Syam Madanapalli" <[email-masked]>
Date: Thu, 10 Aug 2006 13:11:44 +0530

Hi julien,

> multilink subnet issues as discussed in Dave Thaler's draft.

True. If you have multiple links the RFC 2461/2462 naturally works by
which you get a unique prefix for an MN if there is only one MN on that
link (p2p link), we do not need to any extra work.

I am just saying, a unique prefix per MN in a shared link may not be a
good idea. If you want to assign an unique prefix each MN, what needs to be
done is just emulate p2p links, that's all, that current standards just works.

Thanks,
Syam

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Aug 2006 11:07:13 +0300

Julien Laganier wrote:

>point-to-point link issue. 
>
Right. I believe the chairs are asking for consensus about the first issue.
My own opinion is that we should choose the per-node subnet prefix(es)
model.

But we do have other open issues as well, such as whether we want
to support shared links, whether the link local scope can be larger than
the global prefix scope, etc. Those issues need to be decided as well, but
perhaps we can close the first issue at least.

--Jari

---

From: "Syam Madanapalli" <[email-masked]>
Date: Thu, 10 Aug 2006 13:44:36 +0530

Hi julien,

> allowed to do it, and we can specify in a NetLMM spec that a MAG MUST

This may lead comaptibility problems, as routers need to be modified
for NetLMM. Also, as per current ND specification mutlicast RAs are required
to update the router and prefix lifetimes. Because you cannot send multicast
RAs, the unicast RAs may generate lot of traffic on the air interface.

-Syam

---

From: Julien Laganier <[email-masked]>
Date: Thu, 10 Aug 2006 11:08:58 +0200

Hi Syam,

> > >     solicitation's source address is not the unspecified
> > > address), but the usual case is to multicast the response to
> > > the all-nodes group.
> >
> > allowed to do it, and we can specify in a NetLMM spec that a MAG
> > MUST send unicast RAs.
>
> This may lead comaptibility problems, as routers need to be
> modified for NetLMM. 

But a NetLMM router is not a plain router, it's a specialized network 
element called a MAG that implements NetLMM.

> Also, as per current ND specification 
> mutlicast RAs are required to update the router and prefix
> lifetimes. Because you cannot send multicast RAs, the unicast RAs
> may generate lot of traffic on the air interface.

As you know the prefix lifetime can be set to infinite, while the 
router lifetime can be as long as 9000 seconds and interval between 
RAs as long as 1800 seconds. I don't think that characterize a "a lot 
of traffic" on the air interface.

If it does then we should advocate your draft on relaxing those 
constraints on ND configuration ;)

<draft-madanapalli-ipv6-periodic-rtr-advts-00.txt>

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 10 Aug 2006 11:21:31 +0200

On Thursday 10 August 2006 10:07, Jari Arkko wrote:
> >> most people favor the prefix per mobile node model over a shared
> >> link model, though there is still a lack of shared understanding
> >> about the details of how the prefix per mobile node model should
> >> be implemented.
> >
> >However I do not think we've discussed too much about the shared
> > vs. point-to-point link issue.
>
> Right. I believe the chairs are asking for consensus about the
> first issue. My own opinion is that we should choose the per-node
> subnet prefix(es) model.
>
> to support shared links, whether the link local scope can be larger
> than the global prefix scope, etc. Those issues need to be decided
> as well, but perhaps we can close the first issue at least.

Right. The NetLMM WG should agree whether or not to support shared 
links, while the issue regarding link local vs global scope should be 
agreed on on the INT area ML, IMHO.

Regarding the shared link support, FWIW goal #7 of our requirements 
draft calls for wireless link technology agnosticism.

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 10 Aug 2006 07:35:33 -0700 (PDT)

I disagree, per-MN subnet prefix reduces IPv6 addressing to 64 bits, i.e. in half. It is a waste of the address usage. Shared subnet prefix should be used where possible, isn't it natural to do so? That's what founding father's did.
  Netlmm is about keeping the address, so you get the address using whichever subnet prefix model and then get to keep it, n'est-ce pas?
--behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: [email-masked]; Behcet Sarikaya <[email-masked]>
Cc: Roberts Phil-APR042 <[email-masked]>
Sent: Thursday, August 10, 2006 1:25:55 AM
Subject: Re: [netlmm] Addressing Model Discussion Conclusion

Hi Behcet,

Best,

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 10 Aug 2006 11:41:00 -0700

> allowed to do it, and we can specify in a NetLMM spec that a MAG MUST 

sure you can do this but its not enough. you would
need to modify a bunch of things for this to work.

- override the MAY in RFC 2461 and say that a NETLMM
   MAG MUST alway send a unicast router advertisement
   in response to a router solicitation.

- NETLMM MAG should not include any prefix information
   in the unsolicited router advertisements.

- relax the SHOULD in section 4.2 of RFC 2461
     A router SHOULD include all its on-link prefixes
     (except the link-local prefix) so that multihomed
     hosts have complete prefix information about on-
     link destinations for the links to which they
     attach.

- if for some reason, the MN needs the non link local
   address of the MAG, the MAG would need to configure
   a global address from each of the prefixes allocated
   to the MNs. if the MN never needs to see the global
   address of the MAG, then this is not needed.

- an unsolicited router advertisement cannot be avoided
   since this is needed by the MN to obtain the link
   layer address of the MAG (through the source link
   layer address option in the router advertisement).
   now we have to figure out what the timer should be
   for the unsolicited router advertisements.

let me know if I missed something.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Fri, 11 Aug 2006 09:04:40 +0200

Vijay,

On Thursday 10 August 2006 20:41, Vijay Devarapalli wrote:
> >> address), but the usual case is to multicast the response to the
> >> all-nodes group.
> >

Agree with most of what you proposed below. Just a terminology point 
however. We do not need to update/modify/override/relax anything in 
2461; we're just using the flexibility provided by 2461 (there are no 
MUST preventing anything of what is needed.) What we'd need is to 
specify what behavior we want to have in the context of that 
flexibility.

>    in response to a router solicitation.

Yes.

>    in the unsolicited router advertisements.

Yes. Other solutions would be:
  - Unicast unsolicited RAs
  - Disable unsolicited RAs, but that would require infinite router 
lifetime as per draft-madanapalli-ipv6-periodic-rtr-advts-00.txt. Not 
sure this draft will be adopted.

>      link destinations for the links to which they

Well, most likely we're going to advertise prefixes as "not on-link" 
i.e. 'L' bit is reset, so perhaps it is somehow consistent with the 
above.

>    address of the MAG, then this is not needed.

Yes. I don't see why a MN would ever need the MAG global address. And 
perhaps the MAG doesn't even need a global address, but for remote 
management purposes.

>    for the unsolicited router advertisements.

I don't understand why the MN need an *unsolicited* RA. If the MN has 
DNA it will issue an RS when it gets link_UP trigger, and the MAG 
will reply with a *solicited* RA containing its link-local and 
link-layer addresses.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 11 Aug 2006 10:23:14 +0200

Hi Behcet,

You said it yourself: "Shared subnet prefix should be used where 
possible [...]"

In the NetLMM context it does not seem to be possible to use a shared 
subnet prefix because that would means the subnet spans multiple 
links.

This has issues, see <draft-thaler-intarea-multilink-subnet-issues>

Best,

--julien

On Thursday 10 August 2006 16:35, Behcet Sarikaya wrote:
> I disagree, per-MN subnet prefix reduces IPv6 addressing to 64
> bits, i.e. in half. It is a waste of the address usage. Shared
> subnet prefix should be used where possible, isn't it natural to do
> so? That's what founding father's did. Netlmm is about keeping the 
> address, so you get the address using whichever subnet prefix model
> and then get to keep it, n'est-ce pas? --behcet
>
> avoid multilink subnet issues (which seems strongly desirable, to
> put it mildly.)
>
> implementable on various link types. So far it seems that the
> per-MN subnet prefix model would be implementable on shared links,
> including 802.11, so the discussion makes sense IMHO.
>
> Best,
>
> --julien
>
> > email like most people favor the prefix per mobile node model
> > over a shared link model, though there is still a lack of shared
> > though as if there are fewer technical issues with using that
> > model for the kinds of deployments that are envisioned for NETLMM
> > at least initially. Is there anybody at this time that has any

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 11 Aug 2006 07:51:17 -0700 (PDT)

Ooh, I see.
That means netlmm is not only "disturbing" regular IP routing, it is also doing the same thing to the regular IP addressing!
Wow, I hope we knew all these implications before taking on such a path.

--behcet

----- Original Message ----
From: Julien Laganier <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Friday, August 11, 2006 3:23:14 AM
Subject: Re: [netlmm] Addressing Model Discussion Conclusion

Hi Behcet,

Best,

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Aug 2006 08:42:47 -0700

>>    in the unsolicited router advertisements.

I don't see anything wrong with including prefix information
options with both 'A', 'L' = 0.

Fred

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Aug 2006 10:50:40 -0700

> specify what behavior we want to have in the context of that 

call it whatever you want. point is you need additional
specification in the NETLMM WG. with a mobile node and a
access router that implements RFC 2461 you can't restrict
the MN to one prefix on a shared link.

> i.e. 'L' bit is reset, so perhaps it is somehow consistent with the 

the 'L' bit set to 1 says the prefix are on-link. 'L' bit
set to 0 says nothing. the prefix may or may not be on-link. :)

       L              1-bit on-link flag.  When set, indicates that this
                      prefix can be used for on-link determination.  When
                      not set the advertisement makes no statement about
                      on-link or off-link properties of the prefix.  For
                      instance, the prefix might be used for address
                      configuration with some of the addresses belonging
                      to the prefix being on-link and others being off-
                      link.

> will reply with a *solicited* RA containing its link-local and 

two things to consider

1. are you going to require DNA between the MN and the MAG
for NETLMM to work?
2. if there is more than one MAG on the access link, every
MAG would receive this router solicitation. then you have
to figure out which one manages the MN. maybe multiple MAG
on a shared link has not been discussed enough so far.

things would be lot simpler if you assume point-to-point
links.

Vijay

---

From: Christian Vogt <[email-masked]>
Date: Sat, 12 Aug 2006 13:26:48 +0200

> [...]
> [...]

I might be missing something, but if we require MNs and MAGs to use DNA,
then this issue is somewhat mitigated because DNA-capable MAGs would
unicast RAs in the default case anyway.

Specifically, MNs conforming to the current version of the DNA protocol
[1] send an RS with included TSLLAO upon handoff.  The TSLLAO allows the
receiving ARs to unicast their RAs to the RS's IP source address, i.e.,
the MN's Optimistic link-local IP address (which is in Optimistic state
shortly after the handoff).  An additional NS/NA exchange is not
necessary then.

    [1]  draft-ietf-dna-protocol-01.txt

So, according to [1], we already have an RS-plus-unicast-RA exchange
upon handoff, at least in the default case.  Yet, a set of modifications
is still required, although those affect the DNA protocol rather than
RFC 2461:

(1)  According to [1], MNs SHOULD use the TSLLAO, but they may not.  If
they don't, the responding RAs need to be multicast.  For NETLMM, this
needs to be changed.  Two possible solutions:

- Require MNs to use the TSLLAO.

- Have the MAG initiate an NS/NA exchange to obtain the MN's link-local
IP address.

- Have the MAG retrieve the MN's MAC address from the RS's link-layer
frame, provided the link layer at hand permits this.

- MAGs may use FRD [2], as mentioned earlier on the list.

    [2]  draft-ietf-dna-frd-01.txt

(2)  ARs conforming to [1] must periodically multicast RAs in order to
do FastRA.  This rule will have to be either relaxed or somehow extended
for NETLMM MAGs.  Three solution to solve this problem have been
suggested on this list so far AFAICT (and more than once):

- Always limit the number of MAGs per link to a single (possibly
virtual) one.  FastRA then becomes trivial and does no longer require
periodic RAs.

- Have multiple on-link MAGs periodically send multicast RAs without
PIOs.  This should be possible since, for the purpose of FastRA, the
multicast RAs are only used by MAGs to obtain neighboring MAGs'
link-local IP addresses.  (As per DNA, ARs also learn each others
prefixes through periodic multicast RAs so that they can include LPIOs
in their RAs.  But that's certainly a behavior that we don't want for a
prefix-per-MN NETLMM architecture anyway.)

- Allow periodic multicast RAs with PIOs, but reset the L bit in all PIOs.

(3)  [1] requires ARs to use a token bucket for unicast RA
transmissions.  When the token bucket is empty, the ARs send multicast
RAs instead of unicast ones.  This may not happen in NETLMM, of course,
so the token bucket mechanism must be relaxed.  This should be feasible
in NETLMM for 2 reasons:

- Assuming that there is a single (possibly vitual) MAG per MN in
NETLMM, an DoS attacker willing to jam the link cannot solict multiple
RAs with a single RS as it could on a plain IPv6 link with multiple ARs.
 While the attacker may get signifiant amplification in plain IPv6---it
sends a single message, and many more messages are transmitted to the
link as a consequence---, the amplification is less dramatic if only one
AR responds.  The threat of DoS is hence relaxed to some extent, and the
token bucket mechanism is no longer so strictly necessary.

- This DoS issue is no longer such a big threat as soon as MNs are
authenticated.  In NETLMM, an RS securely identifies a MN (most likely
by use of a SEND-based IP address ownership proof plus a binding between
the IP address and the MN's network access identity).  MAGs may hence
keep track of the rate at which a particular MN sends RSs.  If a MN
sends them to rapidly, then the responsible MAG may simply stop sending
RAs to that MN (and /not/ fall back to multicast RAs).

There are certainly other things in DNA which will have to be changed.
But FWIW, as long as the changes affect ARs/MAGs only, and DNA-compliant
MNs continue to function fine in a NETLMM domain, then I don't think
there is a problem.  In this regard, I concur with Julien (and others)
who expressed this same opinion on the list earlier.

Best,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

Vijay Devarapalli wrote:
>> sending unicast RAs is allowed (this is a MAY above) so we are allowed
>> to do it, and we can specify in a NetLMM spec that a MAG MUST send
>> unicast RAs.
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 15 Aug 2006 10:05:58 -0700

The underlying L2 technology has nothing to do with the way subnet 
information is conveyed to the end host. In fact, the relationship  between 
the two is something that needs to be discussed going forward.

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Vijay Devarapalli" 
<[email-masked]>; "Mohamed Khalil" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 09, 2006 1:17 PM
Subject: RE: [netlmm] Addressing Model Discussion Conclusion

Vidya

> deployments
> prefix per

---

From: "James Kempf" <[email-masked]>
Date: Tue, 15 Aug 2006 10:19:53 -0700

DNA already updates it (Section 5.1.5 of draft-ietf-dna-protocol-01.txt):

   The usual response to a Router Solicitation SHOULD be a unicast RA.

NETLMM needs DNA for other reasons (router NUD on handover if that is not 
provided by the link layer).

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 15 Aug 2006 10:30:57 -0700

Syam,

There are a lot of changes requried for NETLMM in the last hop router. I 
think we can safely assume that it will be an entirely new device, in fact, 
the designation in the DT protocol draft of the NETLMM functionality as a 
Mobile Access Gateway (MAG) is intended to highlight this.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 15 Aug 2006 20:09:14 +0200

James Kempf wrote:
> information is conveyed to the end host. In fact, the relationship 
> between the two is something that needs to be discussed going 
> forward.

For example pppv6 specifies that there's no need to DAD a global address
derived using the id negotiated by IPv6CP.

This makes think that the DAD argumentation (and some of the DNA) is
probably necessary only if the L2 is a shared type.

Alex