Subject: [Int-area] IPv6 addressing model, per-MN subnet prefix, and broadcast domain

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Aug 2006 15:20:52 +0200

Hi Dave, and other folks knowledgeable about IPv6 addressing model,

[[email-masked] CCed, please reply only to [email-masked]]

While working on the issues of which addressing model to use in 
NetLMM, I think I got confused with issues involved the IPv6 
addressing model (or its assumptions.)

I would therefore like to ask you if a potential NetLMM addressing 
model (per-MN subnet prefix [RFC3314]) would, in some situations, 
conflict with the IP addressing model.

Background
----------

Dave's draft on issues involved with multilink subnets 
[draft-thaler-intarea-multilink-subnet-issues] list some assumptions 
of the IP addressing model, but there might be other that are not 
specific to multilink subnets. I'd therefore like to ask you about 
possible conflicts between IPv6 and RFC3314 addressing model.

We are considering the situation of mobile nodes (MNs) attached to a 
NetLMM domain. The NetLMM domain span multiple access links, each 
served by a given access router (AR). A MN attaches to one link, and 
hence to one AR.

	( NetLMM domain )
        /   |   |   |   \
       AR   AR  AR  AR   AR
      /  \   \     /  \    \
     MN  MN  MN   MN   MN  MN

If all of the MNs in the domain uses a common subnet prefix we 
obviously end-up with a multilink subnet, which is problematic as 
described in Dave's draft. Now a simple way to avoid multilink subnet 
issues is to use a per-MN subnet prefix, as in the IETF 
recommendation to 3GPP [RFC3314]. That way, each of the MN moves has 
a different prefix and hence none of the prefix spans more than one  
link, thus avoiding multilink subnet issues.

Issue
-----

Such model has however raised a question, which is orthogonal to 
multi-link subnets issues. RFC3314 was proposed for use in a scenario 
where the link between the MN and its AR is point-to-point. Now if we 
consider a broadcast/multicast capable link-layer technology such as 
Ethernet, then we would have a situation in which, on a given link, 
the broadcast domain and hence the link-local scope are larger than 
the any of the per-MN subnet prefixes scope (as illustrated below 
when 3 MNs A, B and C are connected to one such link served by one AR 
R). 

A subnet prefix scope:    -R-------A------------------  

B subnet prefix scope:    -R---------------B----------  

C subnet prefix scope:    -R------------------------C-  

link-local scope:         -R-------A-------B--------C-  

L2 broadcast scope:       -R-------A-------B--------C-  

Do you think that this situation (i.e. link-local scope larger than 
subnet prefix scope) would conflict with the IPv6 addressing model, 
or any of its assumptions?

Many thanks in advance. Best regards,

--julien

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

---

From: Christian Vogt <[email-masked]>
Date: Mon, 07 Aug 2006 18:38:12 +0200

Hi Julien,

I don't think there is a problem.

If you use the prefix-per-MN case on a broadcast link, what you get is a
link comprising multiple subnets.  RFC 3513 explicitly allows links with
multiple prefixes:

   Currently IPv6 continues the IPv4 model that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

(This is, BTW, the passage that Dave Thaler cites in
[draft-thaler-intarea-multilink-subnet-issues].)

In the scenario you describe (the one including MNs A, B, and C), you
simply have a link with 3 prefixes.  The unusual, but still legitimate
circumstance in this scenario is that the MNs do not see their
neighbors' prefixes.

Note that a situation where hosts on the same link see different
prefixes may also arise when the link has multiple routers, each router
advertises a different set of prefixes, and no two hosts receive RAs
from the same router due to packet loss.  The hosts will then not be
aware of their neighbors' prefixes.  Certainly, this is unlikely to
happen, but it may happen.

Let me know if I have missed something.

- Christian

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

Julien Laganier wrote:
> Background ----------
> ( NetLMM domain ) /   |   |   |   \ AR   AR  AR  AR   AR /  \   \
> /  \    \ MN  MN  MN   MN   MN  MN
> 
> Issue -----
>  where the link between the MN and its AR is point-to-point. Now if
> we consider a broadcast/multicast capable link-layer technology such
> as Ethernet, then we would have a situation in which, on a given
> link, the broadcast domain and hence the link-local scope are larger
> than the any of the per-MN subnet prefixes scope (as illustrated
> below when 3 MNs A, B and C are connected to one such link served by
> one AR R).
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 7 Aug 2006 21:01:06 +0300

El 07/08/2006, a las 16:20, Julien Laganier escribió:

> Hi Dave, and other folks knowledgeable about IPv٦ addressing model,
>
> NetLMM, I think I got confused with issues involved the IPv٦
> model (per-MN subnet prefix [RFC٣٣١٤]) would, in some situations,
> possible conflicts between IPv٦ and RFC٣٣١٤ addressing model.
>
> recommendation to ٣GPP [RFC٣٣١٤]. That way, each of the MN moves has
> multi-link subnets issues. RFC٣٣١٤ was proposed for use in a scenario
> when ٣ MNs A, B and C are connected to one such link served by one AR
> R).
>
> L٢ broadcast scope:       -R-------A-------B--------C-
>
> subnet prefix scope) would conflict with the IPv٦ addressing model,

How do the nodes configure their global addresses?
I mean are they using stateless autconf?
If they do, how do you prevent the nodes from configuring one address 
per prefix the get in the RADV? wouldn't some of the nodes end up with 
multiple addresses from different prefixes? breaking the goal of having 
one node per prefix?

However, i guess this is not a problem for your netlmm case, since i 
guess there is no problem that there are multiple mobile nodes per 
prefix, you are just trying to avoid multilink subnets... right?

regards, marcelo

> https://www١.ietf.org/mailman/listinfo/int-area
>

---

From: Christian Vogt <[email-masked]>
Date: Mon, 07 Aug 2006 20:01:19 +0200

To clarify the point I want to make:

- Certainly, there is currently no mechanism that allows you to limit a
node on a broadcast link to a subset of all on-link prefixes (even
though loss of RAs may temporarily prevent the node from seeing all
on-link prefixes).

- The prefix-per-MN approach would be the first mechanism that
guarantees to permanently limit a node on a broadcast link to a subset
of all on-link prefixes.  From this perspective, the prefix-per-MN
approach does make a difference.

- But my point is that things won't break if you use the prefix-per-MN
approach on a broadcast link, because the IPv4/IPv6 architecture does
AFAICT not require nodes to be aware of all on-link prefixes.
Neighboring nodes will simply not be able to communicate directly on the
link layer because they don't consider each other "on link".  This is
what we'd like to have in NETLMM anyway.

- Christian

"Everything should be made as simple as possible, but not simpler."
(Albert Einstein)

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Aug 2006 11:28:33 -0700

While it is true that IPv6 allows multiple subnets per link and has no
requirement about all nodes being aware of all prefixes, it is intended
for routers on a link supporting multiple prefixes. So, the number of
prefixes that you would actually see on a link in practice would be much
more limited than the number of prefixes you are likely to have with the
prefix-per-MN case. 

This does work fine for point-to-point links such as cellular links, but
for the general broadcast media, it is rather strange. It seems to me
that taking broadcast/multicast capability away from a medium that
natively supports the functionality is placing a serious limitation on
such links. I don't know if it specifically breaks something w.r.t IPv6,
but it definitely takes away some powerful functionality. 

Also, if, keeping inline with the charter goals, we still maintain that
the MN does not require any changes, this means that an MN, on WLAN or
ethernet or such media, will assume it is on a shared link and attempt
to do DAD - it will always succeed, but it is just a waste of resources
and time in such a prefix-per-MN model. Also, if stateful address
configuration is used, this means that the MN must do DHCP-PD, which it
normally may not do - so, that will be a change that NETLMM imposes on
an MN. 

If we are going with the prefix-per-MN model, perhaps a good thing to do
will be to scope NETLMM to virtual point-to-point links, since that is
what a broadcast link will be reduced to, in this case. 

Vidya

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Monday, August 07, 2006 11:01 AM
> To: Christian Vogt
> Cc: INT Area; Dave Thaler; NetLMM WG
> Subject: Follow-up: Re: [netlmm] IPv6 addressing model, 
> per-MN subnet prefix, and broadcast domain
> 
> - Certainly, there is currently no mechanism that allows you 
> to limit a node on a broadcast link to a subset of all 
> on-link prefixes (even though loss of RAs may temporarily 
> prevent the node from seeing all on-link prefixes).
> 
> - The prefix-per-MN approach would be the first mechanism 
> that guarantees to permanently limit a node on a broadcast 
> link to a subset of all on-link prefixes.  From this 
> perspective, the prefix-per-MN approach does make a difference.
> 
> - But my point is that things won't break if you use the 
> prefix-per-MN approach on a broadcast link, because the 
> IPv4/IPv6 architecture does AFAICT not require nodes to be 
> aware of all on-link prefixes.
> Neighboring nodes will simply not be able to communicate 
> directly on the link layer because they don't consider each 
> other "on link".  This is what we'd like to have in NETLMM anyway.
> 
> - Christian
> 
> --
> Christian Vogt, Institute of Telematics, Universitaet 
> Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/
> 
> > If you use the prefix-per-MN case on a broadcast link, what 
> you get is 
> > a link comprising multiple subnets.  RFC 3513 explicitly 
> allows links 
> > with multiple prefixes:
> > 
> > prefixes may also arise when the link has multiple routers, each 
> > router advertises a different set of prefixes, and no two hosts 
> > receive RAs from the same router due to packet loss.  The 
> hosts will 
> > then not be aware of their neighbors' prefixes.  Certainly, this is 
> > unlikely to happen, but it may happen.
> > 
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
>

---

From: Christian Vogt <[email-masked]>
Date: Mon, 07 Aug 2006 20:50:58 +0200

Hi Vidya,

right, the term "virtual point-to-point link" describes very well what a
broadcast link becomes as soon as one deploys the prefix-per-MN model.

(Although neighboring MNs can still circumvent the
"pseudo-point-to-point" property by communicating via link-local IP
addresses...)

- Christian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Aug 2006 21:08:23 +0200

Christian Vogt wrote:
> If you use the prefix-per-MN case on a broadcast link, what you get
> is a link comprising multiple subnets.  RFC 3513 explicitly allows
> links with multiple prefixes:
> 
>  simply have a link with 3 prefixes.  The unusual, but still
> legitimate circumstance in this scenario is that the MNs do not see
> their neighbors' prefixes.
> 
> receive RAs from the same router due to packet loss.  The hosts will

I think I agree with the description.

I'd add that if the wireless nature of MN-to-AR interface is
point-to-point (not Ethernet) then we do talk about one prefix valid on
that point-to-point link, and about one MN per one prefix; in my
understanding.

However, it is not clear to me how to "move" that prefix from one AR to
another, as the MN moves from one AR to another.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Aug 2006 21:13:01 +0200

> but it definitely takes away some powerful functionality. 

If the wireless media is natively point-to-point then there is no 
necessity to make it multicast capable.

To me this is the thing to be addressed, the netlmm wireless link nature.

> to do DAD

Not sure that the charter assumes MN being on a shared link.  I think it 
makes no assumptions of being on a shared link or on a point-to-point 
link.  It think it should, or maybe in the reqs/ps drafts.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Aug 2006 21:15:15 +0200

Christian Vogt wrote:
> Hi Vidya,
> 
> right, the term "virtual point-to-point link" describes very well
> what a broadcast link becomes as soon as one deploys the
> prefix-per-MN model.
> 

I think there is no need to try to simulate point-to-point links with
shared links, nor vice-versa.  It think one or the other should be
addressed first.  IMHO, two cents worth.

Alex

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Aug 2006 12:15:55 -0700 (PDT)

> that point-to-point link, and about one MN per one prefix; in my

PPP can support bridging and Ethernet bridges can assign different VLANs per port.  
So the scope of the broadcast domain really is orthogonal to the link type.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Aug 2006 21:03:22 +0200

marcelo bagnulo braun wrote:
[snip picture and text]
> How do the nodes configure their global addresses? I mean are they
> using stateless autconf?

Not sure about what's becoming mandatory and what not.  There's a draft
on MN-AR interface talking about _both_ stateless and stateful, haven't
checked recently though.

>  per prefix the get in the RADV?

By putting M bit to 1 in RA thus instructing MN not to derive an address
from the prefix in RA ('M' stands for managed, instructing to use DHCP
instead).

> wouldn't some of the nodes end up with multiple addresses from 
> different prefixes?

Yes, provided stateless autoconf is used.

> breaking the goal of having one node per prefix?

Not sure about the goal of having one node per prefix, where is it from?
  I know about a netlmm goal needing MN not to change its address (maybe
called CoA, not sure), not sure whether this is in the reqs draft either.

Alex

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Aug 2006 13:25:28 -0700

> > point-to-point (not Ethernet) then we do talk about one 
> prefix valid 
> > on that point-to-point link, and about one MN per one prefix; in my 
> > understanding.
> 

This is certainly true. However, the point of VLANs is still completely
different from the point of providing a prefix-per-MN for purposes of
mobility management. For instance, the VLAN concept itself will be in
conflict with providing NETLMM services on the same network. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Aug 2006 14:34:40 -0700

> From: Alexandru Petrescu [mailto:[email-masked]] 
> 
> Not sure about what's becoming mandatory and what not.  
> There's a draft on MN-AR interface talking about _both_ 
> stateless and stateful, haven't checked recently though.
> 
> By putting M bit to 1 in RA thus instructing MN not to derive 
> an address from the prefix in RA ('M' stands for managed, 
> instructing to use DHCP instead).
> 

No. The goal here is strangely different, actually. The goal is not to
advertise all the prefixes in all the RAs - the RA itself will be
tailored per mobile - so, each mobile will only see the prefix that is
being "assigned" to it. 

The other strange thing here is that the mobile may not know that it is
being "assigned" anything - so, it may continue to use stateless
autoconfig, assuming it is a shared prefix. 

The other point here that may be considered weird is that although the
prefix is being "assigned" so to say, there is no lifetime for it
(unlike DHCP-PD, for e.g.) - so, I'm not sure if these prefixes are
pretty much permanently assigned or if, based on the NETLMM location
registration information, these are somehow removed. 

Vidya

>   I know about a netlmm goal needing MN not to change its 
> address (maybe called CoA, not sure), not sure whether this 
> is in the reqs draft either.
> 
> Alex
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 08 Aug 2006 00:21:48 +0200

Bernard Aboba wrote:
>> point-to-point (not Ethernet) then we do talk about one prefix
>> valid on that point-to-point link, and about one MN per one prefix;
>> in my understanding.
> 
> PPP can support bridging and Ethernet bridges can assign different
> VLANs per port. So the scope of the broadcast domain really is
> orthogonal to the link type.

Wirelessly? Do we have any bridged PPP over wireless access, or any VLAN
over wireless access?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 08 Aug 2006 00:32:29 +0200

Narayanan, Vidya wrote:
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]]
>> 
>> marcelo bagnulo braun wrote: [snip picture and text]
>>> How do the nodes configure their global addresses? I mean are
>>> they using stateless autconf?
>> Not sure about what's becoming mandatory and what not. There's a
>> draft on MN-AR interface talking about _both_ stateless and
>> stateful, haven't checked recently though.
>> 
>> By putting M bit to 1 in RA thus instructing MN not to derive an
>> address from the prefix in RA ('M' stands for managed, instructing
>> to use DHCP instead).
>> 
> No. The goal here is strangely different, actually. The goal is not
> to advertise all the prefixes in all the RAs - the RA itself will be 
> tailored per mobile - so, each mobile will only see the prefix that
> is being "assigned" to it.

I think that is fine if we consider point-to-point links.  I know how to
do that (a tunnel interface is a point-to-point link, and send an RA on
that tunnel).

The problem I see with this is how to move this prefix from one AR to
another as the mobile moves (this may be known though...)

> The other strange thing here is that the mobile may not know that it
> is being "assigned" anything - so, it may continue to use stateless 

Well, if each time it opens a point-to-point connection it offers the
same NAI then it should be offered same prefix...

> The other point here that may be considered weird is that although
> the prefix is being "assigned" so to say, there is no lifetime for it

Right... not sure what else than DHCPv6-PD can be used to distribute a
prefix.  Maybe Mobile IPv6 draft extensions, maybe.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Aug 2006 08:24:44 +0200

Hi Christian,

FWIW I don't think that there is problem either. There have however 
been concerns that this break the IPv6 addressing model, hence my 
original message asking for opinions.

Thanks for your reply.

--julien 

On Monday 07 August 2006 18:38, Christian Vogt wrote:
>    associated with one link.  Multiple subnet prefixes may be
> assigned to the same link.
>
> In the scenario you describe (the one including MNs A, B, and C),
> you simply have a link with 3 prefixes.  The unusual, but still
> receive RAs from the same router due to packet loss.  The hosts
> will then not be aware of their neighbors' prefixes.  Certainly,
> this is unlikely to happen, but it may happen.
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Aug 2006 23:51:06 -0700

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Monday, August 07, 2006 11:08 PM
> To: Narayanan, Vidya
> Cc: Alexandru Petrescu; INT Area; James Kempf
> Subject: Re: [Int-area] IPv6 addressing model, per-MN subnet 
> prefix,and broadcast domain
> 
> 
> El 08/08/2006, a las 0:34, Narayanan, Vidya escribió:
> 
> >
> stateless and 
> >> address from the prefix in RA ('M' stands for managed, 
> instructing to 
> >> use DHCP instead).
> >>
> but how do you achieve that? isn't all a single broadcast 
> link (with multiple subnets? if this is the case all the 
> nodes see all the RADV, hence all the nodes configure 
> addresses from all prefixes, right?
> 

I believe those will be unicast RAs sent to the link local address - there will be a huge mess without that, as you observe (I believe there is a mess in the addressing model even with that, but it will be worse with broadcast RAs). 

> i am lost now.... are you using something different than 
> stateless autocnf and than dhcp? a new address conf protocol 
> for specific for netlmm?
> 

I'm waiting to see some proposed text myself to see how this whole thing is going to work on shared media :) Based on the emails I've seen, I think the proposal is the following (people who are actually proposing this may correct anything I say incorrectly here): 

When a mobile shows up, the AR obtains a prefix for the mobile from the LMA using the NETLMM protocol. That prefix is sent in a unicast RA to the mobile by the AR. The MN doesn't really know it is a unique prefix - it performs SLAAC and comes up with an address and performs DAD. 

At the moment, I'm very skeptical about slapping a point-to-point model on shared media - I'll wait for some text to see if I can convince myself :) 

Regards,
Vidya

> >>   I know about a netlmm goal needing MN not to change its address 
> >> (maybe called CoA, not sure), not sure whether this is in the reqs 
> >> draft either.
> >>
> >> Alex
> >>
> >>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 8 Aug 2006 10:15:50 +0300

El 08/08/2006, a las 9:51, Narayanan, Vidya escribió:

>
> I believe those will be unicast RAs sent to the link local address - 
> there will be a huge mess without that, as you observe (I believe 
> there is a mess in the addressing model even with that, but it will be 
> worse with broadcast RAs).
>

so, the router will not send unsolicited RADV but will only answer to 
router solicitations is that it?

wouldn't this pose some problems with movement detection for instance? 
i mean there will no periodic RADV to detect the we are on a different 
link... but i guess you are assuming some for netlmm... but this is off 
topic for the int ml i guess

regards, marcelo

> I'm waiting to see some proposed text myself to see how this whole 
> thing is going to work on shared media :) Based on the emails I've 
> seen, I think the proposal is the following (people who are actually 
> proposing this may correct anything I say incorrectly here):
>
> When a mobile shows up, the AR obtains a prefix for the mobile from 
> the LMA using the NETLMM protocol. That prefix is sent in a unicast RA 
> to the mobile by the AR. The MN doesn't really know it is a unique 
> prefix - it performs SLAAC and comes up with an address and performs 
> DAD.
>
> At the moment, I'm very skeptical about slapping a point-to-point 
> model on shared media - I'll wait for some text to see if I can 
> convince myself :)
>
> Regards,
> Vidya
>
>> regards, marcelo
>>
>>
>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 8 Aug 2006 09:07:57 +0300

> tailored per mobile - so, each mobile will only see the prefix that is

but how do you achieve that? isn't all a single broadcast link (with 
multiple subnets? if this is the case all the nodes see all the RADV, 
hence all the nodes configure addresses from all prefixes, right?

> autoconfig, assuming it is a shared prefix.

i am lost now.... are you using something different than stateless 
autocnf and than dhcp? a new address conf protocol for specific for 
netlmm?

regards, marcelo

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Aug 2006 13:15:22 +0200

Hi Vidya,

[ cutting down the NetLMM-specific discussion which I think is 
out-of-scope for INT area, and CCing INT area only ]

Thanks for your comments
On Monday 07 August 2006 20:28, Narayanan, Vidya wrote:
> While it is true that IPv6 allows multiple subnets per link and has
> no requirement about all nodes being aware of all prefixes, it is
> intended for routers on a link supporting multiple prefixes. 
> So, the number of prefixes that you would actually see on a link in
> practice would be much more limited than the number of prefixes you
> are likely to have with the prefix-per-MN case.

I miss the point you're making above. Are you saying that one link 
would not scale to the number of prefixes implied by the 
prefix-per-MN approach?

> This does work fine for point-to-point links such as cellular
> links, but for the general broadcast media, it is rather strange.
> It seems to me that taking broadcast/multicast capability away from
> a medium that natively supports the functionality is placing a
> serious limitation on such links. I don't know if it specifically
> breaks something w.r.t IPv6, but it definitely takes away some
> powerful functionality.

Agree that it takes away some functionality, most notably the 
possibility for two MNs attached to the same link to communicate 
directly (i.e. not via the router) using global unicast addresses, 
because they would not have the same subnet prefix.

It would however still be possible to use IP multicast as usual on 
such a link, as the constraint involves only global unicast 
addresses.

And you don't see anything specific breaking IPv6 addressing model, 
right?

Best,

--julien

---

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

Vidya,

> At the moment, I'm very skeptical about slapping a point-to-point model on 
> shared media - I'll wait for some text to see if I can convince myself :)

What services do you propose to use in a cellular type system that require 
shared media functionality, such as broadcast and link local multicast? Can 
you give some examples of such services on existing cellular type systems, 
such as UTRAN or cdma2K?

          jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Aug 2006 10:10:09 -0700

Why?

            jak

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>; <[email-masked]>
Cc: "NetLMM WG" <[email-masked]>
Sent: Monday, August 07, 2006 1:25 PM
Subject: RE: [Int-area] Re: [netlmm] IPv6 addressing model,per-MN 
subnetprefix, and broadcast domain

Vidya

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 Aug 2006 13:13:45 -0700

If I understand the picture at bottom, this is fine.
That is, there can be multiple subnet prefixes per link,
and different hosts may be in different subsets of the
set of subnet prefixes.  All of this is fine in the IP 
addressing model.

Section 2.1 of the [draft-thaler-intarea-multilink-subnet-issues] draft
acknowledges this:

   In December 1995, the original IP Version 6 Addressing Architecture
   [RFC1884] was published, stating: "IPv6 continues the IPv4 model
   that a subnet is associated with one link.  Multiple subnets may be
   assigned to the same link."

   Thus it explicitly acknowledges that the current IPv4 model has been
   that a subnet is associated with one link, and that IPv6 does not
   change this model.  Furthermore, a subnet is sometimes considered to
   be only a subset of a link, when multiple subnets are assigned to
   the same link.

-Dave

> From: Julien Laganier [mailto:[email-masked]]
> Sent: Monday, August 07, 2006 6:21 AM
> To: Dave Thaler; INT Area
> Cc: James Kempf; NetLMM WG
> Subject: IPv6 addressing model, per-MN subnet prefix, and broadcast
domain

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 Aug 2006 13:24:15 -0700

Point of terminology...

RAs do not assign a prefix to a node, they assign a prefix to the link
over which the RA is sent.  That is, the router and the node both have
an on-link route in their routing table, and any addresses in the prefix
are assigned to the interface the RA is sent/received on.

DHCP-PD assigns a prefix to a node.  That is, the router has a route in
its routing table that is not on-link but points to that node directly,
and any addresses in the prefix are assigned to an interface other than
the one the RA is sent/received on.

-Dave

> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Monday, August 07, 2006 2:35 PM
> To: Alexandru Petrescu; marcelo bagnulo braun
> Cc: James Kempf; INT Area
> Subject: RE: [Int-area] IPv6 addressing model, per-MN subnet
prefix,and
> broadcast domain
is

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 Aug 2006 13:31:00 -0700

I think Bernard's point is that PPP bridging is defined (RFC 3518).
That is, PPP links can be bridged together.   They cannot be bridged
with Ethernet links.

Whether it's wired or wireless depends on whatever the physical media
under PPP is.  So for example, if someone were to do RFC3518 with PPPoE
and if PPPoE is able to work over 802.11 (offhand I don't know if it
does), then you'd have bridged PPP over wireless.

-Dave

> Sent: Monday, August 07, 2006 3:22 PM
> To: Bernard Aboba
> Cc: NetLMM WG; [email-masked]
> Subject: Re: [Int-area] Re: [netlmm] IPv6 addressing model, per-MN

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 Aug 2006 13:34:21 -0700

> Sent: Tuesday, August 08, 2006 12:16 AM
> To: Narayanan, Vidya
> Cc: -; James Kempf; INT Area
prefix,and
> topic for the int ml i guess

Not sending periodic RAs over a shared medium seems to me to be pretty
fragile.  Router Solicitations are not periodic (at least from
unmodified hosts), whereas RAs are.  This means it'd only work if the
initial RS/RA exchange worked, and the route/prefix lifetimes were
essentially infinite.  I wouldn't recommend this sort of approach.

Instead it would be much safer to either have a normal shared media
(normal = periodic RAs, and all nodes see the same RA), or else have a
disjoint set of logical p2p links where each p2p link can get a
different RA.

-Dave

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 8 Aug 2006 13:39:26 -0700

I fully agree. The point I was trying to make was that in the specific
NETLMM case, these are assigned prefixes (assigned using the NETLMM
protocol from the LMA). Such an assigned prefix is then advertised in
the RA by the AR - the mobile will see the RA as a regular RA and think
that the prefix is meant for the link and configure an IP address on the
interface on which the RA was received. 

Vidya

> From: Dave Thaler [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 1:24 PM
> To: Narayanan, Vidya; Alexandru Petrescu; marcelo bagnulo braun
> RAs do not assign a prefix to a node, they assign a prefix to 
> the link over which the RA is sent.  That is, the router and 
> the node both have an on-link route in their routing table, 
> and any addresses in the prefix are assigned to the interface 
> the RA is sent/received on.
> 
> DHCP-PD assigns a prefix to a node.  That is, the router has 
> a route in its routing table that is not on-link but points 
> to that node directly, and any addresses in the prefix are 
> assigned to an interface other than the one the RA is 
> sent/received on.
> 
> -Dave
> 
> > > There's a draft on MN-AR interface talking about _both_ stateless 
> > > and stateful, haven't checked recently though.
> > >
> > > Not sure about the goal of having one node per prefix, 
> where is it 
> > > from?

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 Aug 2006 13:39:49 -0700

> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2006 1:26 PM
> To: Dave Thaler; Julien Laganier; INT Area
> Cc: NetLMM WG
> Subject: Re: IPv6 addressing model, per-MN subnet prefix, and
broadcast
> domain
> 
> Dave,
> 
> RFC 1812 Section 2.2.5.1 defines the case where multiple subnets are
> associated with a single interface of a router thusly:
> 
>    "The inventors of the subnet mechanism presumed that each piece of
an
>    organization's network would have only a single subnet number.  In
>    practice, it has often proven necessary or useful to have several
>    subnets share a single physical cable.  

Yes the last sentence above is what we mean by multiple subnets on a
single link.

>    For this reason, routers
>    should be capable of configuring multiple subnets on the same
>    physical interfaces, and treat them (from a routing or forwarding
>    perspective) as though they were distinct physical interfaces."

The "treat them as though they were distinct interfaces" is just one way
to implement multiple subnets on a single link, but it is not the only
way or necessarily even the recommended way.  The sentence is just
saying it should be a configurable option to be able to do it that way.

-Dave

> Is this what you mean by multiple subnets on a single link?
> 
>             jak
> 
> From: "Dave Thaler" <[email-masked]>
> To: "Julien Laganier" <[email-masked]>; "INT Area"
> <[email-masked]>
> Cc: "James Kempf" <[email-masked]>; "NetLMM WG"
> <[email-masked]>
> Sent: Tuesday, August 08, 2006 1:13 PM
> Subject: RE: IPv6 addressing model, per-MN subnet prefix, and
broadcast
> > conflict with the IP addressing model.
we

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 8 Aug 2006 13:24:20 -0700

> so, the router will not send unsolicited RADV but will only 
> answer to router solicitations is that it?
> 

There will have to be no multicast RAs. Some networks detect the mobile at L2 and send a unicast RA when the link local address is available (via L2 means). In others, yes, there will be no unsolicited RAs. 

> i mean there will no periodic RADV to detect the we are on a 
> different link... but i guess you are assuming some for 
> netlmm... but this is off topic for the int ml i guess
> 

Yes - due to this restriction, all nodes attaching to links within the NETLMM domain will have to follow NETLMM defined behavior - I don't see how there can be a mix of nodes on the network, some that obtain NETLMM services and some that don't. Those are actually the reasons applicability of this model to all sorts of environments becomes weird. 

It fits the cellular world, where the attached hosts are all paid subscribers that may uniformly get NETLMM services. In the enterprise world, where true shared prefixes are used, for instance, one may want to provide NETLMM services just to the enterprise hosts and not for guest devices or such. This model will not really allow for such mixed deployments. 

Regards,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 8 Aug 2006 13:44:30 -0700

James,
I don't believe that cellular type systems use any shared media
functionality - they've already gone down to the path of p2p links for
various reasons. As I already said in a few of my earlier emails, the
prefix-per-MN model is inline with the cellular system operation. 

Vidya

> Sent: Tuesday, August 08, 2006 10:55 AM
> To: Narayanan, Vidya; marcelo bagnulo braun
> Cc: Alexandru Petrescu; INT Area; -
> What services do you propose to use in a cellular type system 
> that require shared media functionality, such as broadcast 
> and link local multicast? Can you give some examples of such 
> services on existing cellular type systems, such as UTRAN or cdma2K?
> 
>           jak 
> 
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Aug 2006 13:46:27 -0700

----- Original Message ----- 
From: "Dave Thaler" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Julien Laganier" 
<[email-masked]>; "INT Area" <[email-masked]>
Cc: "NetLMM WG" <[email-masked]>
Sent: Tuesday, August 08, 2006 1:39 PM
Subject: RE: IPv6 addressing model, per-MN subnet prefix, and broadcast 
domain

broadcast
an

jak>> The other options being, what? I think it might be useful to enumerate 
them so that we can get an idea of what historical precedent is here.

jak>> One other option is I think PPP, which Bernard has already mentioned, 
with PPPoE being the choice for Ethernet links. Are there any others 
(anybody else know)?

            jak

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 Aug 2006 13:58:10 -0700

jak>> The other options being, what? I think it might be useful to
enumerate 
      them so that we can get an idea of what historical precedent is
here.

The other main option is that there's just one interface (for the shared
media in question) on the router, and that interface has multiple onlink
prefixes.  This is the model described in section 6.2 of RFC2461, where
the AdvPrefixList variable is the list of prefixes onlink to the same
interface.

-Dave

> Sent: Tuesday, August 08, 2006 1:46 PM
broadcast
broadcast

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Aug 2006 14:02:56 -0700

> There will have to be no multicast RAs. Some networks detect
> the mobile at L2 and send a unicast RA when the link local
> address is available (via L2 means). In others, yes, there
> will be no unsolicited RAs.

That is not strictly true, e.g., a router can still send
unsolicited multicast RAs if it wants to advertise itself
as 'default' without advertising prefixes for autoconfig.
(Other examples could also apply in certain use-cases.)

Fred
[email-masked]

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 8 Aug 2006 14:11:18 -0700

> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 2:03 PM
> > There will have to be no multicast RAs. Some networks detect the 
> > mobile at L2 and send a unicast RA when the link local address is 
> > available (via L2 means). In others, yes, there will be no 
> unsolicited 
> > RAs.
> 
> unsolicited multicast RAs if it wants to advertise itself as 
> 'default' without advertising prefixes for autoconfig.

I was referring to multicast RAs for purposes of SLAAC. If you did
stateful address configuration and used RAs only to advertise default
router, that is different. 

Vidya

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Aug 2006 14:24:33 -0700

> router, that is different.

Its not only about stateful address configuration; unsolicited
RAs with incomplete information can be followed by an RS/RA
exchange where the RA contains prefixes for SLAAC.

Fred

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Aug 2006 00:54:30 +0300

Vidya, James,

This gets me back to where Julien started this thread --- whether
it makes sense to have a link local scope larger than the per node
global prefix scope.

We have talked about whether that breaks the addressing
model or not. (There may also be other technical issues to
discuss. What happens to link local communications
when you move, for instance?)

But we should also talk about what the need is. One of the
potential targets for the NETLMM work is specific cellular
networks. If these networks employ p2p links, per node
prefixes, and generally do not use shared media services,
the question is if the WG wants to spend time designing
something that goes beyond this. Keep it simple unless
you have a reason not to.

--Jari

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 8 Aug 2006 14:58:23 -0700

Yes. If the scope is set to cellular networks, that would be fine. It is
the larger generalization to the rest of the models that IETF generally
caters for that I see some issues with. 

Vidya 

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 2:55 PM
> To: Narayanan, Vidya; James Kempf
> Cc: INT Area
> prefix, and broadcast domain
> 
> Vidya, James,
> 
> This gets me back to where Julien started this thread --- 
> whether it makes sense to have a link local scope larger than 
> the per node global prefix scope.
> 
> We have talked about whether that breaks the addressing model 
> or not. (There may also be other technical issues to discuss. 
> What happens to link local communications when you move, for 
> instance?)
> 
> prefixes, and generally do not use shared media services, the 
> question is if the WG wants to spend time designing something 
> that goes beyond this. Keep it simple unless you have a reason not to.
> 
> --Jari
> 
> Narayanan, Vidya wrote:
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Aug 2006 01:16:34 +0300

>all nodes attaching to links within the NETLMM domain will have to follow NETLMM defined behavior - I don't see how there can be a mix of nodes on the network, some that obtain NETLMM services and some that don't.
>  
>
We need to be very careful about "NETLMM defined behaviour".
In particular, what part of this behaviour is in the network and
what is in the host. The value of a NETLMM solution depends in
part on the host not needing to have specialized support for
NETLMM. My ideal model of the solution is where the hosts are
happily doing what they would be doing anyway (DAD, DNA,
DHCP, etc) and the network makes sure that their globally
routable addresses do not need to change unless you leave
the entire network. This also makes it possible to deploy
NETLMM on top of an existing, non-LMM link technology
without having to update the mobile nodes in sync with the
deployment. If we start to require changes in router discovery
or other parts of the MN behaviour this causes complications.

(Having said that, I am not aware of the current documents in
NETLMM proposing any deviations from the ideal model.)

--Jari

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 8 Aug 2006 15:23:59 -0700

I think you misunderstood what I was saying there. I didn't say that the
behavior of the end node must change - only that either all nodes
attaching to the network get NETLMM service or none of them do. There
can't be a mix - otherwise, on shared media, there will need to be
multicast RAs, which will lead to the problem Marcelo was bringing up. 

Vidya 

> Sent: Tuesday, August 08, 2006 3:17 PM
> To: Narayanan, Vidya
> Cc: INT Area
> >all nodes attaching to links within the NETLMM domain will 
> have to follow NETLMM defined behavior - I don't see how 
> there can be a mix of nodes on the network, some that obtain 
> NETLMM services and some that don't.
> >  
> >
> In particular, what part of this behaviour is in the network 
> and what is in the host. The value of a NETLMM solution 
> depends in part on the host not needing to have specialized 
> support for NETLMM. My ideal model of the solution is where 
> the hosts are happily doing what they would be doing anyway 
> (DAD, DNA, DHCP, etc) and the network makes sure that their 
> globally routable addresses do not need to change unless you 
> leave the entire network. This also makes it possible to 
> deploy NETLMM on top of an existing, non-LMM link technology 
> deployment. If we start to require changes in router 
> discovery or other parts of the MN behaviour this causes 
> complications.
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Aug 2006 13:26:28 -0700

Dave,

   "The inventors of the subnet mechanism presumed that each piece of an
   organization's network would have only a single subnet number.  In
   practice, it has often proven necessary or useful to have several
   subnets share a single physical cable.  For this reason, routers
   should be capable of configuring multiple subnets on the same
   physical interfaces, and treat them (from a routing or forwarding
   perspective) as though they were distinct physical interfaces."

            jak

----- Original Message ----- 
From: "Dave Thaler" <[email-masked]>
To: "Julien Laganier" <[email-masked]>; "INT Area" 
<[email-masked]>
Cc: "James Kempf" <[email-masked]>; "NetLMM WG" <[email-masked]>
Sent: Tuesday, August 08, 2006 1:13 PM
Subject: RE: IPv6 addressing model, per-MN subnet prefix, and broadcast 
domain

-Dave

domain

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 8 Aug 2006 13:40:57 -0700

> link... but i guess you are assuming some for netlmm... but this is 
> off topic for the int ml i guess
> 

Regards,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 8 Aug 2006 17:16:45 -0700

> Sent: Tuesday, August 08, 2006 2:25 PM
> Its not only about stateful address configuration; 
> unsolicited RAs with incomplete information can be followed 
> by an RS/RA exchange where the RA contains prefixes for SLAAC.
> 

I'm not exactly sure what you mean by RAs with "incomplete information".
In any case, the above design seems weird to me. For one, there is no
reason a host should send an RS right after it received an unsolicited
RA. Further, what you are suggesting is that the unsolicited RA is
different from the RA that follows the RS. All these sound
architecturally strange to me. 

Vidya

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Aug 2006 08:20:27 +0200

Hi Vidya, 

See comments below,

On Tuesday 08 August 2006 22:24, Narayanan, Vidya wrote:
> unsolicited RAs.
> Yes - due to this restriction, all nodes attaching to links within
> the NETLMM domain will have to follow NETLMM defined behavior - I
> don't see how there can be a mix of nodes on the network, some that
> obtain NETLMM services and some that don't. Those are actually the
> reasons applicability of this model to all sorts of environments
> becomes weird.
>
> It fits the cellular world, where the attached hosts are all paid
> subscribers that may uniformly get NETLMM services. In the
> enterprise world, where true shared prefixes are used, for
> instance, one may want to provide NETLMM services just to the
> enterprise hosts and not for guest devices or such. This model will
> not really allow for such mixed deployments.

There is no requirement that the MN follow a "NetLMM defined 
behavior", as you put it. The MN is supposed to follow standard ND 
and IP layer movement detection (DNA)

When the MN moves within a NetLMM domain, the IP layer movement 
detection (DNA) will always conclude that the node hasn't moved *from 
IP point of view*. The only thing that needs to be updated is the 
default router. This can be done quickly if the MN implements the DNA 
protocol. 

Now if DNA isn't implemented the default router update would be slower 
because NUD has to be invoked, but that's not specific to NetLMM. It 
is the case for every moving node which does not implement IP layer 
movement detection (DNA)  

IMHO link-layer considerations (e.g. cellular) are orthogonal to that 
issue.

Best,

--julien

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 9 Aug 2006 09:29:42 +0300

> exchange where the RA contains prefixes for SLAAC.

But i guess that Dave's point is what happens if the initial RS is 
lost, would the node retry with the RS after receiving the incomplete 
RADV in order to get a valid prefix and manage to configure a gloabl 
address? (i don't know what 2461 states about this...)

I mean, the question is if this approach of incomplete RADV is used, 
could a node recover and stateless autoconfigure a global address if 
the initial RS was lost?

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 09 Aug 2006 10:55:47 +0200

Narayanan, Vidya wrote:
> 
> 
>> -----Original Message----- From: Templin, Fred L 
>> [mailto:[email-masked]] Sent: Tuesday, August 08, 2006 
>> 2:25 PM To: Narayanan, Vidya; marcelo bagnulo braun Cc: James 
>> Kempf; INT Area Subject: RE: [Int-area] IPv6 addressing model, 
>> per-MN subnet prefix,and broadcast domain
>> 
>>> I was referring to multicast RAs for purposes of SLAAC. If you 
>>> did stateful address configuration and used RAs only to
>> advertise default
>> Its not only about stateful address configuration; unsolicited RAs
>>  with incomplete information can be followed by an RS/RA exchange 
>> where the RA contains prefixes for SLAAC.
>> 
> 
> I'm not exactly sure what you mean by RAs with "incomplete 
> information". In any case, the above design seems weird to me. For 
> one, there is no reason a host should send an RS right after it 
> received an unsolicited RA.

Well, if the router puts a short lifetime in the periodic partial RA
(partial, incomplete would mean only the default router address) then
the host will necessarily do an RS after that lifetime and get an RA
that would contain only prefix (no default router address) with a much
longer lifetime.  I think it's implementable.

> Further, what you are suggesting is that the unsolicited RA is 
> different from the RA that follows the RS.

Yes, why not.  The contents are different but they concern different
characteristics, why not.

> All these sound architecturally strange to me.

Looks to me different too, but not necessarily strange.  Why
"architecturally" strange :-)  Would it break anything.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 09 Aug 2006 11:07:13 +0200

marcelo bagnulo braun wrote:
> But i guess that Dave's point is what happens if the initial RS is lost, 
> would the node retry with the RS after receiving the incomplete RADV in 
> order to get a valid prefix and manage to configure a gloabl address? (i 
> don't know what 2461 states about this...)
> 
> could a node recover and stateless autoconfigure a global address if the 
> initial RS was lost?

Well, 2461 says there should be MAX_RTR_SOLICITATIONS RSs at 
RTR_SOLICITATION_INTERVAL seconds interval.  Could they _all_ be lost.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 09 Aug 2006 11:15:07 +0200

> exchange where the RA contains prefixes for SLAAC.

I kind of see how this would work.  A quirk may be with RS being sent to 
multicast only, by 2461:

      Destination Address
                      Typically the all-routers multicast address.

Point-to-point links are usually non multicast capable.

If one needs an unicast solicitation, then that would better be a NS not RS.

But yes, ok,

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 09 Aug 2006 03:58:01 -0700

> Point-to-point links are usually non multicast capable.

That seems backwards.

Point to point links are by definition IP multicast capable.
When sending a packet on a point to point link, whether the final 
destination is unicast or multicast, the same thing happens - the packet 
is sent to the other end of the link.

RFC 2461
    point-to-point - a link that connects exactly two interfaces.  A
                     point-to-point link is assumed to have multicast
                     capability and have a link-local address.

    Erik

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Aug 2006 14:47:45 +0200

Thanks for your input, Dave. That's the input I was searching for.

Best,

--julien

On Tuesday 08 August 2006 22:13, Dave Thaler wrote:
> Section 2.1 of the [draft-thaler-intarea-multilink-subnet-issues]
> draft acknowledges this:
>
>    In December 1995, the original IP Version 6 Addressing
> Architecture [RFC1884] was published, stating: "IPv6 continues the
> IPv4 model that a subnet is associated with one link.  Multiple
> subnets may be assigned to the same link."
>
>    Thus it explicitly acknowledges that the current IPv4 model has
> been that a subnet is associated with one link, and that IPv6 does
> not change this model.  Furthermore, a subnet is sometimes
> considered to be only a subset of a link, when multiple subnets are
> > I would therefore like to ask you if a potential NetLMM
> > addressing model (per-MN subnet prefix [RFC3314]) would, in some
> > situations, conflict with the IP addressing model.
> >
> > Background
> > ----------
> >
> > [draft-thaler-intarea-multilink-subnet-issues] list some
> > assumptions of the IP addressing model, but there might be other
> > that are not specific to multilink subnets. I'd therefore like to
> > ask you about possible conflicts between IPv6 and RFC3314
> > addressing model.
> >
> > We are considering the situation of mobile nodes (MNs) attached
> > to a NetLMM domain. The NetLMM domain span multiple access links,
> > each served by a given access router (AR). A MN attaches to one
> > link, and hence to one AR.
> >
> > 	( NetLMM domain )
> >         /   |   |   |   \
> >        AR   AR  AR  AR   AR
> >       /  \   \     /  \    \
> >      MN  MN  MN   MN   MN  MN
> >
> > described in Dave's draft. Now a simple way to avoid multilink
> > subnet issues is to use a per-MN subnet prefix, as in the IETF
> > recommendation to 3GPP [RFC3314]. That way, each of the MN moves
> > has a different prefix and hence none of the prefix spans more
> > than one link, thus avoiding multilink subnet issues.
> >
> > Issue
> > -----
> >
> > multi-link subnets issues. RFC3314 was proposed for use in a
> > scenario where the link between the MN and its AR is
> > point-to-point. Now if we consider a broadcast/multicast capable
> > link-layer technology such as Ethernet, then we would have a
> > situation in which, on a given link, the broadcast domain and
> > hence the link-local scope are larger than the any of the per-MN
> > subnet prefixes scope (as illustrated below when 3 MNs A, B and C
> > are connected to one such link served by one AR R).
> >
> > Do you think that this situation (i.e. link-local scope larger
> > than subnet prefix scope) would conflict with the IPv6 addressing
> > model, or any of its assumptions?
> >

---

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

Hi Jari,

> you have a reason not to.

So far the discussion on the list hasn't revealed a reason that would 
prevent (or increase the cost of) designing/running NetLMM on shared 
media. My personal opinion is that if we can do it then let's do it, 
it would be good to be link-layer agnostic, as called in the REQ 
draft. FWIW I remember that at least Pekka Savola asked that we keep 
WLAN in our scope. He proposed some text changes to the PS draft:

> 3.1 Large Campus
>   
>      One  scenario where localized mobility management would be
>      attractive is a large campus wireless LAN deployment.  Having a
>      single broadcast domain for all WLAN access points doesn't
>      scale very well.  Also, sometimes parts of the campus cannot be
>      covered by one VLAN for other reasons (e.g., some links are
>      other than 802.3).
>   
> [...]

Best,

--julien

---

From: Dave Thaler <[email-masked]>
Date: Wed, 9 Aug 2006 09:51:44 -0700

> longer lifetime.  I think it's implementable.

Only if you modify the hosts to introduce new behavior, as what you
describe above is not the RFC 2461 specified behavior.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 9 Aug 2006 09:53:17 -0700

> > But i guess that Dave's point is what happens if the initial RS is
lost,
> > could a node recover and stateless autoconfigure a global address if
the
> RTR_SOLICITATION_INTERVAL seconds interval.  Could they _all_ be lost.

Absolutely.  An example in a normal Ethernet environment is that the
hosts are connected to the router through a simple mini-hub box, and the
cable between the minihub and the router is unplugged at the time, and
then plugged back in.

-Dave

---

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

These constant values are changed by DNA. See 
draft-ietf-dna-protocol-01.txt.

       jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>; "James Kempf" 
<[email-masked]>; "INT Area" <[email-masked]>
Sent: Wednesday, August 09, 2006 2:07 AM
Subject: Re: [Int-area] IPv6 addressing model, per-MN subnet prefix, and 
broadcast domain

marcelo bagnulo braun wrote:
> I mean, the question is if this approach of incomplete RADV is used, could 
> a node recover and stateless autoconfigure a global address if the initial 
> RS was lost?

Alex

---

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

And the reason (which Dave neglected to mention) is that Section 6.3.7 of 
RFC 2461 and 2461bis specifies precisely five conditions that allow a host 
to send an RS and forbids the host from sending an RS at any other time. 
Expiration of the RA lifetime is not one of those conditions.

            jak

----- Original Message ----- 
From: "Dave Thaler" <[email-masked]>
To: "Alexandru Petrescu" <[email-masked]>; "Narayanan, 
Vidya" <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>; "James Kempf" 
<[email-masked]>; "INT Area" <[email-masked]>
Sent: Wednesday, August 09, 2006 9:51 AM
Subject: RE: [Int-area] IPv6 addressing model, per-MN subnet prefix,and 
broadcast domain

-Dave

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Aug 2006 13:50:27 +0300

Narayanan, Vidya wrote:

>behavior of the end node must change 
>
Ok.

>- only that either all nodes
Yes - the access routers have to decide whether they run a link
in NETLMM mode or not. On a shared link, multicast RAs would
cause a problem.

(But I am not sure if there's anything that prevents the access
routers from deciding that they do not give this host the actual
local  mobility service; as the hosts are unmodified, they really
do not know how the network decides to give them prefix X or Y.
The restriction is related to how ND works on the link, not what
the NETLMM nodes actually do on behalf of the host.)

--Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 11 Aug 2006 18:00:39 +0200

Erik Nordmark wrote:
>>>> advertise default router, that is different.
>>> 
>> I kind of see how this would work.  A quirk may be with RS being 
>> sent to multicast only, by 2461:
>> 
>> Destination Address Typically the all-routers multicast address.
>> 
> Point to point links are by definition IP multicast capable. When 
> sending a packet on a point to point link, whether the final 
> destination is unicast or multicast, the same thing happens - the 
> packet is sent to the other end of the link.
> 
> RFC 2461 point-to-point - a link that connects exactly two 
> interfaces.  A point-to-point link is assumed to have multicast 

Sounds right, I may have had it backwards.

A router multicasting a packet to two neighbours on a Ethernet sends
only one packet.  A router with two multicast-capable point-to-point
links sends two packets.

But I think it's right to say that a point-to-point link is inherently
multicast capable, I had it wrong.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 Aug 2006 16:46:17 -0700

Having been away from e-mail for the past several days, the
text below is offered to cover the NETLMM Addressing concerns.

This would naturally go as replacement text for Section 5 of
'draft-ietf-netlmm-mn-ar-if-01.txt', but may be appropriate
for other documents as well. Comments?

Fred

"5.  Multilink Subnet Considerations

An individual prefix is an IP prefix associated with a specific
MN, and a shared prefix is an IP prefix that may be associated
with multiple MNs.

ARs must not include an individual prefix in RAs that may be
received by a MN other than the one associated with the prefix.

ARs must not send RAs that include a shared prefix in a Prefix
Information Option with 'A'=1 unless there is operational assurance
of duplicate address detection/avoidance across the NETLMM domain.

ARs must not send RAs that include an individual or shared prefix
in a Prefix Information Option with 'L'=1 unless all RAs that
include the prefix and all MNs that receive them are associated
with a single link."

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2006 08:47:53 -0700

(cross-posting, since there seems to be interest in NETLMM
on the IPv6 list)

Fred

---

From: "James Kempf" <[email-masked]>
Date: Thu, 24 Aug 2006 11:04:01 -0700

Fred,

I don't think this quite captures the situation.

First off, a prefix advertised in an RA is not assigned to an end node, it 
is assigned to a link. A prefix can only rightly be considered to be 
assigned to a node when it is delegated via DHCP, this allows the node to 
then assign the prefix to links downstream, or delegate further if the 
prefix isn't a /64.

Secondly, exactly what is meant by 'L=0' is underspecified by RFC 2461. I 
think everyone agrees with 'L=1' means, that the prefix is only being 
advertised to nodes that are on this physical link. Any effort to tighten up 
the definitoin of  'L=0' is going to need wider discussion with the ipv6 WG 
and possibly might impact RFC2461bis. This draft is currently in AD 
Evauation:Revised Draft Needed.

Thirdly, this doesn't discuss at all link forwarding considerations, 
particularly with regard to link local multicast (i.e. forwarding of traffic 
to link local multicast addresses). As we've discussed offlist, exactly how 
link local multicast forwarding works for NETLMM is an open question at this 
point. I started another thread on that for comment. So far, the thread 
hasn't been very active.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "INT Area" <[email-masked]>; <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>
Sent: Wednesday, August 23, 2006 4:46 PM
Subject: [netlmm] Multilink Subnet Considerations for NETLMM Addressing

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2006 11:22:58 -0700

James,

> prefix isn't a /64.

The text does not say anywhere "assigned to (sic) an end node";
it says "associated with (sic) an end node/nodes", and prefixes
are associated with a link per (RFC4291, Section 2.1). 

> Evauation:Revised Draft Needed.

As long as a MN does not assign a prefix with 'L=0' to an interface,
then the RFC2461 interpretation of 'L=0' is irrelevant in terms of
the text I offered and RFC2461 is certainly specified well enough
such that implementations would not assign a prefix with 'L=0' to
an interface.

> point. I started another thread on that for comment. So far, the
thread 

Again, this is irrelevant wrt to the text I offered, and subject
for a separate thread of discussion. Such discussion should take
place on a wider distribution such as the INT area and IPv6 lists
since it is germane to the IPv6 addressing architecture and not
particular to NETLMM.

Fred

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "INT Area" <[email-masked]>; <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>
Sent: Wednesday, August 23, 2006 4:46 PM
Subject: [netlmm] Multilink Subnet Considerations for NETLMM Addressing

Fred

---

From: "James Kempf" <[email-masked]>
Date: Thu, 24 Aug 2006 11:39:49 -0700

jak>> The last paragraph of Section 2.1 in 4291 says:

   Currently, IPv6 continues the IPv4 model in that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.

jak>> So whether the term "associated" or "assigned" is used is not 
particularly relevant. Both are used to mean that the link is what, in a 
sense, "owns' the prefix, not the node.

jak>> Inferring from the previous text in that section, the discussion makes 
clear that prefixes are assigned to interfaces, not nodes. In fact, the 
first sentence in the section says that:

   IPv6 addresses of all types are assigned to interfaces, not nodes.

jak>> I interpret the text in the paragraph you sent to mean that the node 
"owns" the prefix. I would suggest modifying the text as follows:

    An individual prefix is an IP prefix assigned to an interface on a 
specific
    MN on a single link and is not shared by any other node on the link with
    the exception of the last hop router, and a shared prefix is an IP 
prefix that
    may be assigned to interfaces on multiple MNs on a single link.

jak>> I'm not sure I understand. Perhaps you can provide some background on 
what exactly you are intending to convey with this text?

jak>> I think it is relevant to multilink subnets. Suppose a NETLMM domain 
is a multilink subnet. Then the question of what happens with link local 
multicast is important. Does it get forwarded between physical links or not? 
This determines whether the NETLMM domain looks like a single virtual 
physical link or not. An application that uses link local multicast might 
work differently if link local multicast is forward or not, as we have 
discussed.

            jak

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2006 12:16:07 -0700

James, 

> "owns" the prefix. I would suggest modifying the text as follows:

"Associated" does not mean "owned" by any sense of the definition for
"associated" I was able to find in www.m-w.com.

specific
prefix that
>    may be assigned to interfaces on multiple MNs on a single link.

That is unnecessarily restrictive, as I believe you know.

> what exactly you are intending to convey with this text?

I don't know how to address a question like this without more detail,
since my statement above and the offered text read clearly to me.

> discussed.

The point of the offered text is that by following the guidelines
a NETLMM domain cannot be a multilink subnet. I can call it something
like "Multilink Subnet Avoidance" if you'd like.

Here is the offered text again:

Fred

---

From: "James Kempf" <[email-masked]>
Date: Thu, 24 Aug 2006 13:04:34 -0700

Fred,

jak>> Well it does according to my reading of the enclosed text from RFC 
4291. Perhaps we need someone else's opinion on this, since we clearly 
disagree. Perhaps we should ask Bob Hinden, as he is the author of the 
disputed text in RFC 4291?

specific
prefix that

jak>> The current text is unacceptable to me, as insufficiently precise.

jak>> What are other people's opinions?

jak>> What are your expectations about  what advertising 'L=1' means for the 
link?

jak>> "Cannot avoid a multilink subnet"? Then why call it "Multilink Subnet 
Avoidance"?'

            jak

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2006 13:14:19 -0700

> jak>> What are your expectations about  what advertising 'L=1' means
for the 

The criteria that allow a prefix to be advertised with 'L=1' are
covered under the final paragraph of the offered text, and what
advertising 'L=1' means for the link is covered under RFC2461.

> jak>> "Cannot avoid a multilink subnet"? Then why call it "Multilink
Subnet 

I don't quite understand your question, but the offered text avoids
multilink subnets.

Fred

            jak

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Aug 2006 13:41:03 -0700

James,

> I'm not going to discuss this text with you any further on the list at
this 
> time. I believe the text is sufficiently unclear and imprecise to
result in 
> confusion about how one should implement the MN-AR interface in
NETLMM. 
> Clearly, you disagree and you're not prepared to accommodate any of my

> suggestions, so there's little point in our continuing the discussion.

Suit yourself, but the text works in necessary and sufficient terms.
Take 5 minutes to work through it, and I believe you will see that
this is so.

Fred

---

From: "James Kempf" <[email-masked]>
Date: Thu, 24 Aug 2006 13:23:48 -0700

Fred,

I'm not going to discuss this text with you any further on the list at this 
time. I believe the text is sufficiently unclear and imprecise to result in 
confusion about how one should implement the MN-AR interface in NETLMM. 
Clearly, you disagree and you're not prepared to accommodate any of my 
suggestions, so there's little point in our continuing the discussion.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "INT Area" 
<[email-masked]>; <[email-masked]>; "IETF IPv6 Mailing List" 
<[email-masked]>
Sent: Thursday, August 24, 2006 1:14 PM
Subject: RE: [Int-area] RE: [netlmm] Multilink Subnet Considerations for 
NETLMMAddressing

Fred

            jak

Fred

---

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

Hi James,

Just for clarification.

On Thursday 24 August 2006 20:04, James Kempf wrote:
> Secondly, exactly what is meant by 'L=0' is underspecified by RFC
> 2461. I think everyone agrees with 'L=1' means, that the prefix is
> only being advertised to nodes that are on this physical link. Any
> effort to tighten up the definitoin of  'L=0' is going to need
> wider discussion with the ipv6 WG and possibly might impact
> RFC2461bis. This draft is currently in AD Evauation:Revised Draft
> Needed.
>
> [...]

I wouldn't say that 'L=0' semantic is underspecified. I on the 
opposite found 2461 to be quite well specified. It says:

   Note, however, that a Prefix Information option
   with the on-link flag set to zero conveys no information concerning
   on-link determination and MUST NOT be interpreted to mean that
   addresses covered by the prefix are off-link.

That is, it doesn't mean that *all* nodes are off-link. Some might, 
while some might not. But it clearly specifies what the node should 
do in that case.

   The default behavior (see
   Section 5.2) when sending a packet to an address for which no
   information is known about the on-link status of the address is to
   forward the packet to a default router;

i.e. send packets to the default router.

What do you think is underspecified?

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 31 Aug 2006 10:40:37 -0700

In addition to what Julien said, (RFC2461, Section 6.3.4)
also says:

   "Prefixes with the on-link flag set to zero would normally
   have the autonomous flag set and be used by [ADDRCONF]."

and ([ADDRCONF], Section 5.5.3) looks only at the 'A' bit
for address configuration. Hosts use prefixes with the 'A'
bit set to configure an address and add it to the list of
addresses assigned to the interface regardless of the sense
of the 'L' bit.

Fred

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Thursday, August 31, 2006 1:43 AM
To: James Kempf
Cc: [email-masked]; INT Area; IETF IPv6 Mailing List
Subject: Re: [netlmm] Multilink Subnet Considerations for NETLMM
Addressing

Hi James,

Just for clarification.

--julien

---

From: "James Kempf" <[email-masked]>
Date: Thu, 31 Aug 2006 10:55:20 -0700

Maybe I'm confused, but I don't see what L=0 really means. If ADDRCONF 
assigns the prefix to the interface, then the prefix is on link for at least 
one node, the node that configured the interface with the prefix. I suppose 
one could argue that, even if that node considered the prefix on link, that 
node should not assume another node does. But IFICT, 2461 doesn't have 
specific, RFC 2119 requirements language around that.

If M=1, and stateful configuration is used, then I could see some sense in 
L=0, since I assume in that case the prefix is not assigned to the 
interface.

Can anybody say what real implemetations do with this?

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "Julien Laganier" <[email-masked]>; "James Kempf" 
<[email-masked]>
Cc: <[email-masked]>; "INT Area" <[email-masked]>; "IETF IPv6 Mailing 
List" <[email-masked]>
Sent: Thursday, August 31, 2006 10:40 AM
Subject: RE: [netlmm] Multilink Subnet Considerations for NETLMM Addressing

Fred

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]]
Sent: Thursday, August 31, 2006 1:43 AM
To: James Kempf
Cc: [email-masked]; INT Area; IETF IPv6 Mailing List
Subject: Re: [netlmm] Multilink Subnet Considerations for NETLMM
Addressing

Hi James,

Just for clarification.

--julien