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

From: Julien Laganier <[email-masked]>
Date: Mon, 2 Oct 2006 14:27:25 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Brian Haley <[email-masked]>
Date: Mon, 02 Oct 2006 10:47:26 -0400

Hi Julien,

> link (which is different from the tunnel interface.), and the HA 

No, the tunnel endpoint on the MN is it's Care-of address, and the other 
end of the tunnel is the HA's address.  It's Home address is configured 
somewhere else, either on its primary nic or on the loopback interface, 
but that's implementation-dependent.

> multilink subnet but you do not forward link-scoped traffic.

I disagree that the MN-HA tunnel is a multilink subnet, it's simply a 
point-to-point tunnel.  The proxying function the HA is doing is 
different from all-out forwarding since it only certain traffic gets 
forwarded, and none of this traffic is forwarded out of the MN onto the 
care-of link, it's just extending the home link to the MN.

-Brian

---

From: Julien Laganier <[email-masked]>
Date: Mon, 2 Oct 2006 17:28:35 +0200

Hi Brian,

On Monday 02 October 2006 16:47, Brian Haley wrote:
>
> Julien Laganier wrote:
> > 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:
>
> No, the tunnel endpoint on the MN is it's Care-of
> address, and the other end of the tunnel is the HA's
> address.  It's Home address is configured somewhere
> else, either on its primary nic or on the loopback
> interface, but that's implementation-dependent.

Ok it seems I confused thing -- What I wanted to say 
is: the MN configures an address within a subnet 
prefix used on the home link. When the MN is away from 
home, that address is on a different link (e.g. 
loopback interface) than the home link. Hence the 
subnet is multilink (scattered on multiple links.)

> [...]
> 
> 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.
>
> I disagree that the MN-HA tunnel is a multilink
> subnet, it's simply a point-to-point tunnel.  

See above: I probably failed to express myself clearly 
-- I wasn't saying the MN-HA tunnel is a multilink 
subnet.

> The proxying function the HA is doing is different
> from all-out forwarding since it only certain traffic
> gets forwarded, and none of this traffic is
> forwarded out of the MN onto the care-of link, it's
> just extending the home link to the MN.

I think this "extension" is indeed what causes a 
multilink subnet: the assumption that a subnet does 
not span more than one link is broken, since the same 
subnet span the home link, *and* a virtual link on the 
MN (e.g. a loopback link, a mip interface link, ...) 
Hence the multilink subnet term.

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 02 Oct 2006 08:42:51 -0700

> Hence the multilink subnet term.

thats different from saying the issues caused by
multi-link subnets are there for MIPv6 also. please
be more specific.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Mon, 2 Oct 2006 09:08:42 -0700

What about ND proxying for home address DAD?  I agree that the tunnel is a 
point to point link, but wouldn't the traffic need to be forwarded down the 
tunnel? A quick search of RFC 3775 indicates that nothing is said about the 
TTL, but it could not be decremented on the relayed  DAD traffic because of 
ND security. This isn't like a normal point to point link between a router 
and a host, because there are other hosts on the same link.

             jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Julien Laganier" <[email-masked]>
Cc: <[email-masked]>; "Brian Haley" <[email-masked]>; "Dave Thaler" 
<[email-masked]>
Sent: Monday, October 02, 2006 8:42 AM
Subject: Re: Multi-link subnets and MIPv6 (was Re: [Mip6] Re: WG 
Review:Recharter of Mobility for IPv6 (mip6))

> Julien Laganier wrote:
>> See above: I probably failed to express myself clearly -- I wasn't saying 
>> the MN-HA tunnel is a multilink subnet.
>>
>> I think this "extension" is indeed what causes a multilink subnet: the 
>> assumption that a subnet does not span more than one link is broken, 
>> since the same subnet span the home link, *and* a virtual link on the MN 
>> (e.g. a loopback link, a mip interface link, ...) Hence the multilink 
>> subnet term.
>

---

From: Julien Laganier <[email-masked]>
Date: Mon, 2 Oct 2006 18:29:34 +0200

On Monday 02 October 2006 18:08, James Kempf wrote:
> What about ND proxying for home address DAD?  I
> agree that the tunnel is a point to point link, but
> wouldn't the traffic need to be forwarded down the
> tunnel? A quick search of RFC 3775 indicates that 
> nothing is said about the TTL, but it could not be
> decremented on the relayed  DAD traffic because of
> ND security.

I don't think the issue is specific to DAD, it's rather 
generic to SEND: CGA ownership has an intrinsic 
conflict with proxying.

When the MN is off-link the HA can't proxy ND by 
replying directly with a NA to a NS sent by an on-link 
host because it doesn't own the MN IP address (i.e. it 
doesn't know the public key generating the MN's CGA)

The alternative would be that the HA proxy ND by 
relaying NSs sent by on-link hosts to the MN, and NAs 
replied by the MN to those hosts while rewriting the 
target link-layer address. This wouldn't work either, 
as the HA cannot rewrite the link-layer address since 
it is signed by the MN.

> This isn't like a normal point to point 
> link between a router and a host, because there are
> other hosts on the same link.

I'd rather say: This isn't like a normal subnet used to 
number a pt-2-pt link between a router and a host, 
because there are other hosts on the same subnet.

--julien

> From: "Vijay Devarapalli"
> <[email-masked]> To: "Julien
> Laganier" <[email-masked]> Cc:
> <[email-masked]>; "Brian Haley" <[email-masked]>;
> "Dave Thaler" <[email-masked]>
> Subject: Re: Multi-link subnets and MIPv6 (was Re:
> [Mip6] Re: WG Review:Recharter of Mobility for IPv6
> (mip6))
>
> > Julien Laganier wrote:
> >> See above: I probably failed to express myself
> >> clearly -- I wasn't saying the MN-HA tunnel is a
> >> multilink subnet.
> >>
> >>> The proxying function the HA is doing is
> >>> different from all-out forwarding since it only
> >>> certain traffic gets forwarded, and none of this
> >>> traffic is forwarded out of the MN onto the
> >> multilink subnet: the assumption that a subnet
> >> does not span more than one link is broken, since
> >> the same subnet span the home link, *and* a
> >> virtual link on the MN (e.g. a loopback link, a
> >> mip interface link, ...) Hence the multilink
> >> subnet term.
> >
> > multi-link subnets are there for MIPv6 also.
> > please be more specific.
> >
> > Vijay
> >
> >> --julien
> >>

---

From: Brian Haley <[email-masked]>
Date: Mon, 02 Oct 2006 12:32:32 -0400

James Kempf wrote:
> What about ND proxying for home address DAD?  I agree that the tunnel is 
> a point to point link, but wouldn't the traffic need to be forwarded 
> down the tunnel? A quick search of RFC 3775 indicates that nothing is 
> said about the TTL, but it could not be decremented on the relayed  DAD 
> traffic because of ND security.

HA does DAD (and all ND on home link) for MN when it's not home, this 
traffic is never forwarded.  The hoplimit on "normal" IPv6 traffic is 
decremented on traffic entering the tunnel, at least in my implementation.

> link between a router and a host, because there are other hosts on the 
> same link.

I don't understand... on the tunnel?  There's only one host at the end 
of the tunnel.

-Brian

---

From: "James Kempf" <[email-masked]>
Date: Mon, 2 Oct 2006 09:59:28 -0700

>> a point to point link, but wouldn't the traffic need to be forwarded down 
>> the tunnel? A quick search of RFC 3775 indicates that nothing is said 
>> about the TTL, but it could not be decremented on the relayed  DAD 

Right, that would solve the problem.

>> This isn't like a normal point to point link between a router and a host, 
>> because there are other hosts on the same link.
>
> I don't understand... on the tunnel?  There's only one host at the end of 
> the tunnel.
>

I was thinking of the case where the HA forwards the ND traffic from an MN 
to other MNs through tunnels, but, as you point out, this isn't necessary.

There is still the issue of secure proxying, though, as Julien has pointed 
out. This topic has come up now and then over the years, and we had a BAR 
BOF the last time IETF was in San Diego to discuss it. Greg Daley did a 
draft (probably expired now) describing solutions that do not require 
protocol changes, I did a draft for MOBOPTS about something more 
sophisticated but requiring more protocol changes.

Do people care about this issue? The easiest way to solve it is to put 
something in RFC 3775bis that says: "if you are concerned about proxy ND 
security, don't configure a home link in a way that allows nodes to directly 
attach to it."  But maybe that's too restrictive.

            jak

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 2 Oct 2006 10:14:22 -0700

I think we might need to distinguish between ND-related issues with
multi-link subnets (and the consequent relay/proxy of ND messages) and
the situation in MIPv6. 

There are two slightly different threads that I think are being
discussed on the list: 

1. Defining multi-link subnets in general and deciding whether MIPv6
falls under such category and therefore comes with all the issues
related to multi-link subnet?

2. Addressing multi-link subnet issues in MIPv6 and investigating
whether there are problems in the *context of MIPv6*. 

Of course addressing 2) implies that we agree the MIPv6 as a concept
creates a multi-link subnet. It would be useful IMO to address 1)
without worrying about the consequences ;)

Another related question to 1) above: If we assume the p2p tunnel
created by MIPv6 is effectively a multi-link subnet, can we also make
that assumption about VPN technologies out there? I'm just interested in
scoping this discussion to the issues that matter to this WG rather than
taking potentially larger issues related to all technologies that
introduce a model that would fall under the multi-link umbrella. 

So, I guess my question is, what are the problematic multi-link aspects
that we want to discuss here? ND seems to be a large component, should
we start with that? 

Sorry for putting more questions than answers! 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 02 Oct 2006 10:21:52 -0700

James Kempf wrote:

> There is still the issue of secure proxying, 

its a separate issue. so I changed the subject.

though, as Julien has
> pointed out. This topic has come up now and then over the years, and we 
> had a BAR BOF the last time IETF was in San Diego to discuss it. Greg 
> Daley did a draft (probably expired now) describing solutions that do 
> not require protocol changes, I did a draft for MOBOPTS about something 
> more sophisticated but requiring more protocol changes.
> 
> Do people care about this issue? 

nope, not yet. nobody yet is using SeND and proxy
ND together on the MIP6 home link.

 > The easiest way to solve it is to put
> security, don't configure a home link in a way that allows nodes to 
> directly attach to it."  But maybe that's too restrictive.

I don't see SeND being used on the MIPv6 home link
anywhere.

however, its true that additional work is needed
to make SeND and proxy ND work together. its not
specific to MIPv6 only.

Vijay

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Mon, 2 Oct 2006 19:50:26 +0200

Hi,

IMHO, maybe, it would be time to re-active SEND WG. The different reasons I see:
o the main one, to re-work on the RFC 3971
- to reduce or to solve the issue regarding the fact that SEND only
secures the IP address of a SEND node and not the link "IP address -
link address" which, IIRC, was one of the initial goal of this WG.
- to integrate feedbacks from SEND implementors (even if, personally,
I only know one: the NTT's public implementation)
o to re-work on the RFC 3972
- to have a better/suited place for the work on draft-bagnulo-multiple-hash-cga
o to work on ND proxy used in conjunction with SEND

Comments?

Sorry if this reply is out of scope the initial thread.

Best regards.

JMC.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 02 Oct 2006 10:46:03 -0700

> related to multi-link subnet?

agree. this is what we should focus on.

> that assumption about VPN technologies out there? 

I would like to second this.

Vijay

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Mon, 2 Oct 2006 19:52:29 +0200

Hi again,

copy/past of my previous mail in the right thread this time :)

"Hi,

Comments?

Best regards.

JMC."

---

From: "James Kempf" <[email-masked]>
Date: Mon, 2 Oct 2006 10:59:08 -0700

I changed the subject again to reflect the change in thread topic.

I've had some reports of interoperability issues with Docomo's 
implementation of SEND so it's possible there is a need for an update of the 
spec. I know of other implementations, but they are not being publically 
distributed.

But the question has always been whether there is enough interest in 
implementation and energy to address lingering issues to restart the WG. 
Vijay's opinion on whether proxy SEND is an issue for MIPv6 is typical of 
the reaction one gets, in my experience. So far, I've not seen strong 
interest in getting the lingering issues addressed.

            jak

----- Original Message ----- 
From: "Jean-Michel Combes" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Brian Haley" <[email-masked]>; <[email-masked]>; "Dave Thaler" 
<[email-masked]>
Sent: Monday, October 02, 2006 10:50 AM
Subject: Re: Multi-link subnets and MIPv6 (was Re: [Mip6] Re: WG 
Review:Recharter of Mobility for IPv6 (mip6))

>> >> down
>> > of
>> directly

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 2 Oct 2006 11:34:59 -0700

I tend to agree with Hesham here. I am not sure why multi-link subnets
is any more an issue for MIP6 than it is for remote access VPNs such as
tunnel-mode IPsec. 

I think focusing on 1 below makes sense to determine what models,
including MIP6 and tunnel-mode ESP, fall under this category. I would
say this is a cross-area activity rather than something that goes into
the MIP6 charter. 

Vidya 

> -----Original Message-----
> From: Soliman, Hesham [mailto:[email-masked]] 
> Sent: Monday, October 02, 2006 10:14 AM
> To: [email-masked]
> Cc: Dave Thaler
> Subject: RE: Multi-link subnets and MIPv6 (was Re: [Mip6] 
> Re:WGReview:Recharter of Mobility for IPv6 (mip6))
> 
> I think we might need to distinguish between ND-related 
> issues with multi-link subnets (and the consequent 
> relay/proxy of ND messages) and the situation in MIPv6. 
> 
> There are two slightly different threads that I think are 
> being discussed on the list: 
> 
> 1. Defining multi-link subnets in general and deciding 
> whether MIPv6 falls under such category and therefore comes 
> with all the issues related to multi-link subnet?
> 
> 2. Addressing multi-link subnet issues in MIPv6 and 
> investigating whether there are problems in the *context of MIPv6*. 
> 
> Of course addressing 2) implies that we agree the MIPv6 as a 
> concept creates a multi-link subnet. It would be useful IMO 
> to address 1) without worrying about the consequences ;)
> 
> Another related question to 1) above: If we assume the p2p 
> tunnel created by MIPv6 is effectively a multi-link subnet, 
> can we also make that assumption about VPN technologies out 
> there? I'm just interested in scoping this discussion to the 
> issues that matter to this WG rather than taking potentially 
> larger issues related to all technologies that introduce a 
> model that would fall under the multi-link umbrella. 
> 
> So, I guess my question is, what are the problematic 
> multi-link aspects that we want to discuss here? ND seems to 
> be a large component, should we start with that? 
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Oct 2006 22:11:50 +0300 (EEST)

> is any more an issue for MIP6 than it is for remote access VPNs such as

MIPv6 includes the concept of a "home link" from which the home 
address is taken.  In case this is a physical link, this is distinctly 
different from how VPNs operate.  If it would be only a logical link, 
you're quite right that the scenario is very close to a regular VPN.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Oct 2006 23:05:53 +0300

Proxy ND / SEND interoperability is one part of this
problem space.

But just to clarify what I expect from the WG regarding
this work item: while a proxy SEND solution would
be useful, I would like to address that, if needed, in
another context outside the MIP6 WG. There's been
occasional questions on creating a SEND++ WG
to deal with various issues that have come up.
(However, I'm not sure we should do that before
we see some deployment of base SEND
mechanisms.)

Anyway, from a MIP6 WG perspective this means that
you should focus on other aspects of the problem.

--Jari