Subject: Re: [netlmm] #107: MAG May Not Be Default Router

From: netlmm <[email-masked]>
Date: Wed, 13 Sep 2006 08:26:58 -0000

#107: MAG May Not Be Default Router
----------------------------------------+-----------------------------------
  Reporter:  [email-masked]           |       Owner:  [email-masked]   
      Type:  defect                     |      Status:  closed             
  Priority:  major                      |   Milestone:  milestone1         
 Component:  draft-ietf-netlmm-threats  |     Version:  2.0                
Resolution:  fixed                      |    Keywords:  MAG, default router
----------------------------------------+-----------------------------------
Changes (by [email-masked]):

  * resolution:  => fixed
  * status:  new => closed

Comment:

 Solved with draft revision 04 (in section 1 and throughout the rest of the
 draft).

-- 
Ticket URL: <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/107>
netlmm <http://tools.ietf.org/wg/netlmm/>
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: netlmm <[email-masked]>
Date: Wed, 13 Sep 2006 10:48:46 -0000

Comment (by [email-masked]):

 Follow-up:  Version 03 of the Threats document was written based on the
 assumption
 that the MAG is a router.  This assumption was removed since it may no
 longer be valid given the recent WG agreement in favor of the per-MN
 prefix model.  Version 04 of the Threats document is now written in a
 more general style, permitting the MAG to be either a router or a
 bridge.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Sep 2006 11:46:44 -0700

> permitting the MAG to be either a router or a bridge.

I would be careful about calling it a "bridge". True bridges
do not mange routes in IP forwarding tables and cannot be used
to join link technologies with dissimilar link-layer address
formats and/or MTUs.

Maybe you are talking about "bridging" when IP is used as
the link-layer protocol for IP, e.g., IP-in-IP tunneling?
Even so, I don't know if it could properly be called a
"bridge"?

Fred
[email-masked]  

-----Original Message-----
From: netlmm [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 3:49 AM
To: [email-masked]
Subject: Re: [netlmm] #107: MAG May Not Be Default Router

#107: MAG May Not Be Default Router
----------------------------------------+-------------------------------
----
  Reporter:  [email-masked]           |       Owner:  [email-masked]

Resolution:  fixed                      |    Keywords:  MAG, default
router
----------------------------------------+-------------------------------
----
Comment (by [email-masked]):

---

From: Christian Vogt <[email-masked]>
Date: Thu, 14 Sep 2006 19:19:51 +0200

Fred,

the Threats document does not explicitly say that the MAG may be a
"bridge".  Actually, the word "bridge" does not appear at all in the
document.

I just chose the term to indicate that, since it is yet undecided
whether a MAG is also an access router, the Threats document is general
enough to permit either option (and discuss potential threats for both).

Thanks for raising this point.

- Christian

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Sep 2006 10:29:23 -0700

Christian,

I wasn't talking about the text of the threats document;
only the text of the follow-up comment for issue #107.

The documents/discussions up to recently have talked about
ARs/MAGs as if they were ordinary routers. Is this group
headed toward narrowing the applicability to only deal
with tunnels (e.g., PDP contexts) that pass through MAGs
w/o decrementing the IP hop-limit? (And if so, why not
just come out and say so?)

Fred

-----Original Message-----
From: Christian Vogt [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 10:20 AM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [netlmm] #107: MAG May Not Be Default Router

Fred,

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 14 Sep 2006 20:25:15 +0200

Fred,

I think the topic of whether MAGs provide access router or bridging
functionality for data plane packets is one point to be further
discussed, given that the discussion on the IP address model has
concluded in (initial) favor of the per-MN prefix model.

While in the shared-prefix model, a MAG must by definition provide
bridging functionality for data plane packets (anything else would end
up being a multi-link subnet model), the per-MN prefix model permits
both options:  MAGs with and without access router functionality.

There is a conflict between the possibly prevalent perception that MAGs
are access routers, and the fact that the 3GPP approach -- which, after
all, significantly helped to shape the per-MN prefix model in NETLMM --
uses the GGSN as an access router (see also RFC 3314), and the GGSN
provides a similar role as the LMA.

OTOH, one may argue that localized mobility management could just as
well be realized at the link layer if the access router functionality is
at the LMA anyway.

Note that the purpose of this email is not to favor either option, but
to observe that this topic needs to be discussed within the group.

Best,
- Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Sep 2006 11:43:01 -0700

> given that the discussion on the IP address model has

I see attractive properties of the prefix-per-MN model, but
I missed seeing the conclusion you are referring to and I
don't quite get why it has to be one vs. the other when
both could be viable alternatives.

> up being a multi-link subnet model),

I don't think that is true if the shared prefixes are
advertised in PIOs with 'L'=0. In that case, there can be
no assumption that address A configured from the shared
prefix is on-link with address B configured from the same
shared prefix - right?

Fred

---

From: Christian Vogt <[email-masked]>
Date: Thu, 14 Sep 2006 22:18:43 +0200

Hi Fred.

> both could be viable alternatives.

I did not say that it would have to be one way or other.  It is true
that either option is viable.

> prefix is on-link with address B configured from the same

You mean 'L'=0 and 'A'=0, right?  All MNs on the link would otherwise do
SLAAC for the prefix.

If SLAAC is disabled by setting 'A'=0 in all multicast RAs, then it
seems that the DAD issue raised in
draft-thaler-intarea-multilink-subnet-issues-00 could be avoided even
though you have a multi-link subnet.  Note, however, that MNs would
still do DAD when receiving a unicast RA with an auto-configurable
prefix.  DAD is likewise recommended for DHCPv6-assigned IP addresses
(see RFC 3315).  But there would never be an address conflict.

OTOH, there may still be Hop Limit and proxying issues, e.g., when
sending packets to link-local multicast addresses.  Do you have a
particular mechanism in mind to avoid those?

- Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Sep 2006 13:54:36 -0700

> that either option is viable.

Maybe I mis-interpreted what you said, but OK.

> You mean 'L'=0 and 'A'=0, right?  All MNs on the link would otherwise
do

That is certainly a viable option and may be beneficial for
certain scenarios.

> (see RFC 3315).  But there would never be an address conflict.

OK, but I'm not sure how you mean about a multi-link subnet;
the only prefix that gets assigned to the link is a /128, so
how is it a multi-link subnet?

> particular mechanism in mind to avoid those?

By definition, link-local multicast addresses are not to be
forwarded off the local link - I'm not meaning to suggest
anything different.

Fred

---

From: Christian Vogt <[email-masked]>
Date: Fri, 15 Sep 2006 00:35:24 +0200

Templin, Fred L wrote:
>> draft-thaler-intarea-multilink-subnet-issues-00 could be avoided
>> even though you have a multi-link subnet.  Note, however, that MNs
>> would still do DAD when receiving a unicast RA with an
>> auto-configurable prefix.  DAD is likewise recommended for
>> DHCPv6-assigned IP addresses (see RFC 3315).  But there would never
>> be an address conflict.
>
> OK, but I'm not sure how you mean about a multi-link subnet; the only
> prefix that gets assigned to the link is a /128, so how is it a
> multi-link subnet?

Fred,

if I understand you correctly and you want to advertise to each MN a
unique 128-bit prefix, then you are proposing a variant of the per-MN
prefix model.  This is not the shared-prefix model.  I might be
misunderstanding you.

- Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Sep 2006 16:15:33 -0700

Christian, 

> prefix model.  This is not the shared-prefix model.  I might be

That is not what I was meaning to say, but I don't want to
rule that out. Other possibilities include:

 1) AR sends RAs with no PIOs at all, but 'M' flag set. MN uses
    DHCPv6 to get addresses and assigns them to the access
    interface as /128s. (fe80::/10 is also assigned to the
    access interface, but no other prefixes are assigned.)

 2) AR sends RAs with PIO(s) with 'A'='L'=0, and 'M' flag set.
    MN considers the PIO(s) as indications of prefixes the DHCPv6
    server is willing to delegate addresses from, and constructs
    addresses from the prefixes (e.g., using CGA). MN includes
    addresses in IA_NA options in a DHCPv6 4-msg or 2-msg exchange,
    and DHCPv6 server considers the addresses as requests for
    specific addresses the MN would like to receive. DHCPv6 server
    delegates the addresses and MN assigns them to the access
    interface as /128s as in 1).

 3) AR sends RAs with PIO(s) with 'A'=1;'L'=0. MN uses SLAAC,
    but this is only viable if there is some (unspecified)
    means of duplicate address detection/avoidance across the
    NETLMM domain. MN assigns addresses to access interface
    as /128s as in 1). 
     
Fred

---

From: Christian Vogt <[email-masked]>
Date: Fri, 15 Sep 2006 14:51:13 +0200

Hi Fred,

all of the possibilities you are listing do actually follow the per-MN
prefix model because all of them use IP addresses with 128-bit prefixes.
 I.e., each MN ends up using an individual prefix.

Note that the starting point for this discussion was whether the MAG
could be an access router in the shared-prefix model.  My argument was
that, by definition of the shared-prefix model, it cannot.  If the MAG
is an access router, you end up following either the multi-link subnet
model or the per-MN prefix model.  Where the MAG can be either an access
router or a bridge in the per-MN prefix model.  This is what I was
saying in my original email.

Does this make sense?

- Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Sep 2006 07:50:58 -0700

Christian,

>  I.e., each MN ends up using an individual prefix.

I think this can be viewed in two ways; you are right that
it is an individual prefix from the perspective of on-link
determination, but it is still a shared prefix from the
perspective of address configuration - hence the need for
some form of duplicate address avoidance.

If the PIO had both 'A';'L' = 1, then it would be a shared
prefix from both perspectives. But this would only work if
the NETLMM domain comprised a single link, which may/may not
be a common use case. 

> saying in my original email.

Right, and the part I originally commented on was about use of
the term "bridge"; a true bridge cannot connect L2 link media
with dissimilar L2 address formats and/or LinkMTUs because there
is no way to harmonize them without L3 involvement. If the L2
media is IP (as in IP-in-IP tunneling) then there is a common
address format and a way to harmonize dissimilar LinkMTUs (IP
fragmentation and/or Path MTU discovery) so you could call it
"bridging" in some sense. But bridging of dissimilar "native"
L2s (e.g., certain wireless media and GigE) doesn't work.  

> Does this make sense?

Yes, and sorry if the discussion got side-tracked.

Fred

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 15 Sep 2006 22:16:41 +0200

Hi Fred.

>> all of the possibilities you are listing do actually follow the
>> per-MN prefix model because all of them use IP addresses with
>> 128-bit prefixes.
> I think this can be viewed in two ways; you are right that it is an
> individual prefix from the perspective of on-link determination, but
> it is still a shared prefix from the perspective of address
> configuration - hence the need for some form of duplicate address
> avoidance.

Hmm, let's see.  DAD uses link-local multicast addresses and therefore
involves all neighbors on a link, regardless of whether the neighbors
have IP addresses from the same prefix as the target (to-be-configured)
IP address.  It would technically be feasible to run subnet-scope DAD
(which implies link-scope DAD when the target IP address is link-local).

The reason why link-scoped DAD is totally feasible in regular IPv6 is
because the scope of a subnet equals the scope of the link.  But in
NETLMM, the scope of a subnet may be just a single MN (or two nodes on a
point-to-point link).

So in conclusion, I'd say that the IP address assignment approaches that
you described in your previous email /do/ follow the per-MN prefix
model.  It is just that DAD must be executed across the entire link
because that's the way the protocol is built.

The situation is different when the per-MN prefix model is realized with
(possibly virtual) point-to-point links because this narrows the scope
of a link down to the scope of the subnet.

BTW, this discussion is bringing us to the point that Jari raised
earlier:  Whether or not the link scope should be bigger than the subnet
scope in NETLMM.  I don't know if this was discussed further in the
meantime.

> If the PIO had both 'A';'L' = 1, then it would be a shared prefix
> from both perspectives.

If such a PIO is sent to multiple MNs---e.g., in a multicast RA---,
then, yes, the prefix is shared.  But then you would use a prefix length
shorter than 128 bits, which is fundamentally different from the
approaches you have proposed.

>                          But this would only work if the NETLMM domain
> comprised a single link, which may/may not be a common use case.

Spontaneously I would say that you may also send unicast RAs including
128-bit prefixes with 'A'='L'=1 in addition to multicast RAs without any
PIOs.

> Right, and the part I originally commented on was about use of the
> term "bridge"; a true bridge cannot connect L2 link media with
> dissimilar L2 address formats and/or LinkMTUs because there is no way
> to harmonize them without L3 involvement. If the L2 media is IP (as
> in IP-in-IP tunneling) then there is a common address format and a
> way to harmonize dissimilar LinkMTUs (IP fragmentation and/or Path
> MTU discovery) so you could call it "bridging" in some sense. But
> bridging of dissimilar "native" L2s (e.g., certain wireless media and
> GigE) doesn't work.

Ok.

> Yes, and sorry if the discussion got side-tracked.

No, no, that's fine.  This was certainly an interesting excursion.

- Christian

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Sep 2006 10:23:29 +0200

Hi Christian,

On Friday 15 September 2006 22:16, Christian Vogt wrote:
> earlier:  Whether or not the link scope should be bigger than the
> subnet scope in NETLMM.  I don't know if this was discussed further
> in the meantime.

I originally started on the INT-area ML the thread asking if a 
link-local scope larger than the subnet prefix scope is problematic:

<http://www1.ietf.org/mail-archive/web/int-area/current/msg00342.html>

As far as I can remember the answers I got so far, there was no 
precise point made about why this would be a problem.

--julien