Subject: [netlmm] 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

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

---

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

---

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

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: 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: Julien Laganier <[email-masked]>
Date: Tue, 8 Aug 2006 09:05:05 +0200

Vidya,

[cutting down the recipient list as the issue discussed below is 
specific to netlmm]

On Monday 07 August 2006 20:28, Narayanan, Vidya wrote:
>
> [...]
>
> 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. 

Even if it was a waste of resources, I wouldn't be concerned as DAD 
occurs only upon first attachment to a NetLMM domain. Hence the 
"waste" wouldn't be that important.

I however don't agree that DAD would always succeed and that it is a 
waste of resources. 

DAD might fail in two cases:
1) the MAG has already configured a colliding link-local address
2) a MN attached to a different link has configured a colliding 
link-local address. This is not an immediate problem, but if the two 
MNs later happen to attach to the same link, that is a problem. Hence 
it would be good if we could insure (via proxy/relay DAD) link-local 
uniqueness in the domain.

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

I don't see why the MN would need DHCP-PD. It is entirely possible 
that the DHCP server assigns to MNs *addresses* under different 
subnet prefixes (one prefix per MN.) The prefix does not really need 
to be 'entirely' delegated to the MN, although that's a possibility.

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

Yes that would be a possibility, if that can be achieved at layer 2 
using per-MN VLANs, as James pointed out to me.

Thanks.

--julien

---

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