Fwd: RE: Multi-link subnets and MIPv6 (was Re: [Mip6] Re: WG Review: Recharter of Mobility for IPv6 (mip6))

[Julien Laganier <[e-mail]>]

Forwarding Dave's note as it seems it didn't make it to 
the mailing list.

--julien

----------  Forwarded Message  ----------

Subject: RE: Multi-link subnets and MIPv6 (was Re: 
[Mip6] Re: WG Review: Recharter of Mobility for IPv6 
(mip6))
Date: Tuesday 03 October 2006 19:42
From: Dave Thaler
To: Julien Laganier, [e-mail]
Cc: Vijay Devarapalli, Jari Arkko

Just catching up on this thread. I agree with Julian's 
email below, and Pekka's later email.

MIPv6 defines a multilink subnet in the case where you 
have a home link with a subnet prefix. When you are 
away from home, and using a point-to-point tunnel to 
the home agent, the fact that the home agent 
decrements the TTL between the tunnel and other nodes 
on the home link, and the fact that the home agent 
does not forward link-scoped multicast between the 
two, is precisely the cause of the problems as Julian 
notes.

MIPv6 implementations do decrement TTL (as Brian Haley 
noted in his response), and do not forward link-scoped 
multicast (as Vijay noted in his email).

Regarding the discussion of VPNs, the same problem can 
occur with VPNs if the VPN server shares a prefix with 
a subnet (e.g., Ethernet) on the back end and some VPN 
servers are capable of doing this. Similarly, the same 
problem could occur if all the point-to-point links 
share a common subnet mask/prefix and the VPN server 
decrements TTL and/or doesn't forward link-scoped 
multicast between two VPN clients in the same subnet 
prefix. However, I'm not aware of an RFC that 
specifically recommends this behavior, which is the 
main reason why MIPv6 is more problematic than VPNs in 
general.

-Dave

> -----Original Message-----
> From: julien laganier
> [mailto:[e-mail]] On Behalf Of
> Julien Laganier
> Sent: Monday, October 02, 2006 4:53 AM
> To: [e-mail]
> Cc: Vijay Devarapalli; Jari Arkko; Dave Thaler
> Subject: Re: Multi-link subnets and MIPv6 (was Re:
> [Mip6] Re: WG

Review:
> Recharter of Mobility for IPv6 (mip6))
>
> Hi Vijay,
>
> Some thoughts below:
>
> On Friday 29 September 2006 23:54, Vijay Devarapalli 
wrote:
> > Hi Jari and Dave,
> >
> > Jari Arkko wrote:
> > >> can you send us more information on this?
> > >> specifically on what we are supposed to look
> > >> for. document problems that we might encounter
> > >> when MIPv6 is run over multilink subnets?
> > >
> > > The basic reference is the new IAB draft,
> > > draft-iab-multilink-subnet-issues-00.txt.
> >
> > I went through this document.
> >
> > first I was surprised when I saw the following
> > text
> >
> > >    However, other WGs continued to allow for
> > > this concept even though it had been rejected in
> > > the IPv6 WG.  Mobile IPv6 [RFC3775] allows
> > > tunnels to mobile nodes to use the same subnet
> > > as a home link, with the Home Agent doing layer
> > > 3 forwarding between them.
> >
> > I was surprised to see the MIPv6 home link and the
> > tunnels to each mobile node being compared to a
> > multi-link subnet. its not a multi-link subnet as
> > described in
> > draft-ietf-ipv6-multilink-subnets-00.txt. the home
> > agent does not bridge and forward link-scope
> > traffic onto the tunnels.
>
> My (perhaps flawed) understanding is that a
> multilink subnet occurs when a subnet prefix is used
> to number interfaces on different links, and an
> entity forward traffic between those two links. It
> is not only about forwarding link-scope traffic.
>
> If you look at MIPv6 as described per section 8.4.
> of RFC 3775 this AFAICS exactly what happens: The MN
> numbers its tunnel interface with an address in the
> same subnet prefix that the one used on the home
> link (which is different from the tunnel
> interface.), and the HA
>
> forwards traffic:
> > 8.4.  IPv6 Home Agents
> >
> > [...]
> >
> >   o  Every home agent MUST be able to intercept
> > packets (using proxy Neighbor Discovery [12])
> > addressed to a mobile node for which it is
> > currently serving as the home agent, on that
> > mobile node's home link, while the mobile node is
> > away from home (Section 10.4.1).
> >
> >   o  Every home agent MUST be able to encapsulate
> > [15] such intercepted packets in order to tunnel
> > them to the primary care-of address for the mobile
> > node indicated in its binding in the home agent's
> > Binding Cache (Section 10.4.2).
>
> Regarding your observation that link-scope traffic
> is not forwarded in MIPv6, I think that not
> forwarding link-scope traffic is exactly the problem
> with multilink subnets: lot of applications assume
> that if two nodes share a same subnet prefix, then
> it means they share a link, and they can therefore
> communicate with link-scope traffic, and TTL won't
> get decremented. This assumption is broken when you
> have a multilink subnet but you do not forward
> link-scoped traffic.
>
> > the draft later on says
> >
> > >    A multilink subnet model SHOULD NOT be used. 
> > > IETF WG's using, or considering using, multilink
> > > subnets today should investigate moving to one
> > > of the other models.  For example, Mobile IPv6
> > > should investigate having the Home Agent not
> > > decrement the Hop Limit, and forward multicast
> > > traffic.
> >
> > currently no link local traffic sent on the home
> > link is forwarded over the Mobile IP tunnel to the
> > mobile node.
>
> I think that is exactly one of the issue of
> multilink subnets as used in MIPv6 (see above.)
>
> > [...]
> >
> > the current use of Mobile IP tunnels as an
> > extension of the home links does not introduce the
> > issues described with multi-link subnets in
> > draft-iab-multilink-subnet-issues. or I might be
> > missing something big.
>
> IMHO MIPv6 introduce the issues described in the
> multilink subnet draft.
>
> --julien

-------------------------------------------------------

_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6