Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Pekka Savola]

(Re-sending as netdev was non-operational yesterday.)

On Fri, 16 Jan 2004, Ville Nuorvala wrote:
> > It's still at the starting phase -- now would be an excellent time to
> > bring this up.
> 
> OK, I guess I'll send a question to the ipv6 list.

Please do -- I've already raised too many issues in that spec :-)

> Let's assume the proxy handles (both link-local and global) NUD
> probes correctly. What will it do with the rest of the unicast packets?
> 
> Packets to a global address may be routed to the proxied node if the
> router has a route to it, but what should it do to link-local packets? The
> desired behavior isn't described in RFC2461, but the MIPv6 draft has a
> proposal.

Right.
 
> No, *assuming* we have a proxy capable of capturing NUD probes, my patch
> will send an Address Unreachable message in response to all link-local
> unicast traffic *except* ND, since it is already handled separately.
> Since ND works normally, my patch doesn't limit link-local proxying. It
> just warns the sender that any link-local traffic it is trying to send
> can't be delivered to the destination.

OK.
 
> > It can give back ICMP error messages, if necessary.  I don't know
> > which path a Thaler proxy would use though.
> 
> It can't really use ip6_forward() anyway, since the funtion decreases the
> hop limit of the packet and drops all traffic from a link-local source
> address etc, etc.
> 
> Since the Thaler proxy clearly needs some other forwarding function than
> ip6_forward(), my proposed patch doesn't affect its behavior in any way.

Ok, if your modification is in ip6_forward() (I didn't check), I guess 
it would OK, with a sufficient comment to bring up that a future 
implementation might treat link-local proxying differently.

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

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Ville Nuorvala]

On Sat, 17 Jan 2004, Pekka Savola wrote:

> > Since the Thaler proxy clearly needs some other forwarding function than
> > ip6_forward(), my proposed patch doesn't affect its behavior in any way.
>
> Ok, if your modification is in ip6_forward() (I didn't check), I guess
> it would OK, with a sufficient comment to bring up that a future
> implementation might treat link-local proxying differently.

Dave, since even Pekka is now convinced this patch doesn't break anything,
would you consider applying it? :)

Slightly (cleaned up version of) patch below.

Thanks,
Ville

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1521  -> 1.1522
#	net/ipv6/ip6_output.c	1.49    -> 1.50
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/01/27	vnuorval@dsl-hkigw1o3c.dial.inet.fi	1.1522
# The MIPv6 specification requires we send an ICMPv6 Destination Unreachable,
# Address Unreachable, message in response to traffic to a proxied link-local address
# --------------------------------------------
#
diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
--- a/net/ipv6/ip6_output.c	Tue Jan 27 22:05:56 2004
+++ b/net/ipv6/ip6_output.c	Tue Jan 27 22:05:56 2004
@@ -385,6 +385,15 @@
 	if (!xfrm6_route_forward(skb))
 		goto drop;

+	/* The proxying router can't forward traffic sent to a link-local
+	   address, so signal the sender and discard the packet. This
+	   behavior is required by the MIPv6 specification. */
+
+	if (ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL &&
+	    skb->dev && pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) {
+		dst_link_failure(skb);
+		goto drop;
+	}
 	/* IPv6 specs say nothing about it, but it is clear that we cannot
 	   send redirects to source routed frames.
 	 */
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Pine.LNX.4.58.0401272259160.28384@rhea.tcs.hut.fi> (at Tue, 27 Jan 2004 23:11:20 +0200 (EET)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:

> Dave, since even Pekka is now convinced this patch doesn't break anything,
:

> +	/* The proxying router can't forward traffic sent to a link-local
> +	   address, so signal the sender and discard the packet. This
> +	   behavior is required by the MIPv6 specification. */

Would you please clarify the word "can't" and its reasons?
won't? don't? or whatever?

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Pekka Savola]

On Wed, 28 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> In article <Pine.LNX.4.58.0401272259160.28384@rhea.tcs.hut.fi> (at Tue, 27 Jan 2004 23:11:20 +0200 (EET)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:
> > +	/* The proxying router can't forward traffic sent to a link-local
> > +	   address, so signal the sender and discard the packet. This
> > +	   behavior is required by the MIPv6 specification. */
> 
> Would you please clarify the word "can't" and its reasons?
> won't? don't? or whatever?

I think "can't" in this context means, "it can't be _forwarded_
because it's link-local".  It could be proxied using some other
function than ip6_forward, though.

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

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Ville Nuorvala]

On Wed, 28 Jan 2004, Pekka Savola wrote:

> On Wed, 28 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote:
> > In article <Pine.LNX.4.58.0401272259160.28384@rhea.tcs.hut.fi> (at Tue, 27 Jan 2004 23:11:20 +0200 (EET)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:
> > > +	/* The proxying router can't forward traffic sent to a link-local
> > > +	   address, so signal the sender and discard the packet. This
> > > +	   behavior is required by the MIPv6 specification. */
> >
> > Would you please clarify the word "can't" and its reasons?
> > won't? don't? or whatever?
>
> I think "can't" in this context means, "it can't be _forwarded_
> because it's link-local".  It could be proxied using some other
> function than ip6_forward, though.

Yes.

--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[David S. Miller]

On Tue, 27 Jan 2004 23:11:20 +0200 (EET)
Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:

> Dave, since even Pekka is now convinced this patch doesn't break anything,
> would you consider applying it? :)

Yoshfuji asked for some time, so let us give it to him so he
may analyze your change without rushing.

Thanks.

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20040128115910.0a83e906.davem@redhat.com> (at Wed, 28 Jan 2004 11:59:10 -0800), "David S. Miller" <davem@redhat.com> says:

> On Tue, 27 Jan 2004 23:11:20 +0200 (EET)
> Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:
> 
> > Dave, since even Pekka is now convinced this patch doesn't break anything,
> > would you consider applying it? :)
> 
> Yoshfuji asked for some time, so let us give it to him so he
> may analyze your change without rushing.

David, I'm (or we're) ok with this patch. Please apply. Thanks.
(But I still do not eat the proxy ND patch.)

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: (usagi-core 17336) Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20040203.171952.105535895.yoshfuji@linux-ipv6.org> (at Tue, 03 Feb 2004 17:19:52 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:

> In article <20040128115910.0a83e906.davem@redhat.com> (at Wed, 28 Jan 2004 11:59:10 -0800), "David S. Miller" <davem@redhat.com> says:
> 
> > On Tue, 27 Jan 2004 23:11:20 +0200 (EET)
> > Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:
> > 
> > > Dave, since even Pekka is now convinced this patch doesn't break anything,
> > > would you consider applying it? :)
> > 
> > Yoshfuji asked for some time, so let us give it to him so he
> > may analyze your change without rushing.
> 
> David, I'm (or we're) ok with this patch. Please apply. Thanks.
> (But I still do not eat the proxy ND patch.)

Oops, I need to say something.
I however think this should be postponed after linux-2.6.2 is up
since this patch is not so "critical" fix.

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: (usagi-core 17336) Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[David S. Miller]

On Tue, 03 Feb 2004 17:24:19 +0900 (JST)
YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[(B <yoshfuji@linux-ipv6.org> wrote:

> I however think this should be postponed after linux-2.6.2 is up
> since this patch is not so "critical" fix.

I agree, Ville please resubmit once 2.6.2 is out.

[PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Ville Nuorvala]

Hi Dave & Co,

the patch below causes a router proxying a link-local address to discard
traffic sent to it, also sending an ICMPv6 Destination Unreachable, Code 3
message to the source. This behavior is required by the Mobile IPv6
specification (the only user of proxy ND I'm aware of).

This seems like reasonable behavior in any case, since the router won't be
able to forward the link-local traffic to the proxied node anyway.

Thanks,
Ville

===== net/ipv6/ip6_output.c 1.48 vs 1.50 =====
--- 1.48/net/ipv6/ip6_output.c	Thu Jan  1 22:25:30 2004
+++ 1.50/net/ipv6/ip6_output.c	Wed Jan 14 12:08:51 2004
@@ -385,6 +385,15 @@
 	if (!xfrm6_route_forward(skb))
 		goto drop;

+	/* The proxy can't forward traffic sent to a link-local address,
+	   so signal the sender and discard the packet */
+
+	if (ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL &&
+	    skb->dev && pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) {
+		icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_ADDR_UNREACH,
+			    0, skb->dev);
+		goto drop;
+	}
 	/* IPv6 specs say nothing about it, but it is clear that we cannot
 	   send redirects to source routed frames.
 	 */
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Pekka Savola]

On Wed, 14 Jan 2004, Ville Nuorvala wrote:
> the patch below causes a router proxying a link-local address to discard
> traffic sent to it, also sending an ICMPv6 Destination Unreachable, Code 3
> message to the source. This behavior is required by the Mobile IPv6
> specification (the only user of proxy ND I'm aware of).
> 
> This seems like reasonable behavior in any case, since the router won't be
> able to forward the link-local traffic to the proxied node anyway.

Please check out draft-thaler-ipv6-ndproxy-xx.txt -- it used ND 
proxying (similar to proxy ARP).

I fear this change might break that..

> --- 1.48/net/ipv6/ip6_output.c	Thu Jan  1 22:25:30 2004
> +++ 1.50/net/ipv6/ip6_output.c	Wed Jan 14 12:08:51 2004
> @@ -385,6 +385,15 @@
>  	if (!xfrm6_route_forward(skb))
>  		goto drop;
> 
> +	/* The proxy can't forward traffic sent to a link-local address,
> +	   so signal the sender and discard the packet */
> +
> +	if (ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL &&
> +	    skb->dev && pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) {
> +		icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_ADDR_UNREACH,
> +			    0, skb->dev);
> +		goto drop;
> +	}
>  	/* IPv6 specs say nothing about it, but it is clear that we cannot
>  	   send redirects to source routed frames.
>  	 */
> --
> Ville Nuorvala
> Research Assistant, Institute of Digital Communications,
> Helsinki University of Technology
> email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257
> 

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

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Ville Nuorvala]

On Wed, 14 Jan 2004, Pekka Savola wrote:

> Please check out draft-thaler-ipv6-ndproxy-xx.txt -- it used ND
> proxying (similar to proxy ARP).

Oh yes, true. I actually checked out the draft some months ago...
(And just re-read it :)

> I fear this change might break that..

I don't think it does. Here's why:

The current proxy ND implementation in the kernel only captures multicast
NS messages. A unicast NS (i.e. a NUD probe) won't be captured by the
proxy, in stead it tries to _route_ it to the proxied node.

No matter what scope the proxied address is, this is incorrect behavior since:

1) the packet will probably be routed back to the original link, unless
   the proxy has a more specific route to the proxied node

2) traffic to a link-local address can't be routed to another link

3) an attempt to route a packet back to the original link would
   just cause the proxy to send another NS for the address it is already
   proxying, eventually resulting in a ICMPv6 Destination Unreachable,
   Code 3 message after the NS has timed out.

4) the unicast ND messages are forwarded to at most one other interface,
   not all of them

5) multicast (ND) messages aren't forwarded at all because of 2 and
   since multicast routing isn't implemented yet AFAIK :(

6) the proxying router decreases the hop count of the packet, thus
   breaking the ND protocols (and other link-local protocols that rely on
   the hop count to remain unchanged.

The traditional proxy described in RFC 2461 is a router, what Thaler
describes is closer to a bridge. The protocol described in Thaler's draft
can't rely on routing for what it is doing, in stead it must AFAICS bypass
the routing altogether, either inside the kernel, or by pushing the
traffic through user space.

These are the real problems you have to address if you want to implement
Thaler's draft on Linux.

In contrast, since 2 always applies (i.e. you can't route link-locals)
this patch only removes the unnecessary steps described in 3 before the
error message is sent.

This shouldn't break anything wrt to draft-thaler-ipv6-ndproxy-01.txt (as
explained), and is a requirement in the MIPv6 specifiaction (as previously
mentioned :)

My other patch with the netfilter module captures the NUD probes once it
proxies an addresses, but the intermediate node faces all the listed
problems before it can even start acting as a proxy for it.

Similarly, issues 1, 2, 5 and 6 will also cause problems for other
protocols than just ND, assuming you don't want all traffic to bypass routing.

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Pekka Savola]

Hi,

On Wed, 14 Jan 2004, Ville Nuorvala wrote:
> > Please check out draft-thaler-ipv6-ndproxy-xx.txt -- it used ND
> > proxying (similar to proxy ARP).
> 
> Oh yes, true. I actually checked out the draft some months ago...
> (And just re-read it :)
> 
> > I fear this change might break that..
> 
> I don't think it does. Here's why:

You may have misunderstood ND proxying.  It's just basically an
enhanced Proxy ARP which also works with IPv6.  And proxy arp is
implemented in the kernel. See below:
 
> The current proxy ND implementation in the kernel only captures multicast
> NS messages. A unicast NS (i.e. a NUD probe) won't be captured by the
> proxy, in stead it tries to _route_ it to the proxied node.

Practically all ND packets should be proxied, I think.

[...]
> The traditional proxy described in RFC 2461 is a router, what Thaler
> describes is closer to a bridge. The protocol described in Thaler's draft
> can't rely on routing for what it is doing, in stead it must AFAICS bypass
> the routing altogether, either inside the kernel, or by pushing the
> traffic through user space.

No, Thaler's ND proxy is *not* a bridge; functionally, it's quite
close, but from the implementation perspective, it's not.  All the
communication terminates (at the IP layer) at the ND proxy (and that's
why the TTL won't decrease, because practically the same request is
replicated on the other links with TTL=255).  Therefore, it can act as
a "router"  between two physical links, and the users of the links can
still use e.g. link-local addresses.

ND proxy doesn't "route" between physical segments, because by
definition, all the physical segments share a subnet, and there are no
specifics. On the other hand, it duplicates all ICMPv6 ND packets
across the links (unless there is a mapping in a cache), and expands 
the IP layer subnet (even, the link-local address domain!) to span 
multiple links.

> In contrast, since 2 always applies (i.e. you can't route link-locals)
> this patch only removes the unnecessary steps described in 3 before the
> error message is sent.

Proxying link-locals break fully ND proxying.  I grant you that it may 
not work out of the box at the moment (because it hasn't been 
implemented! :-) but we shouldn't be making steps in the wrong 
direction here.. :-)
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Ville Nuorvala]

On Thu, 15 Jan 2004, Pekka Savola wrote:

> > The current proxy ND implementation in the kernel only captures multicast
> > NS messages. A unicast NS (i.e. a NUD probe) won't be captured by the
> > proxy, in stead it tries to _route_ it to the proxied node.
>
> Practically all ND packets should be proxied, I think.

Currently the specification (RFC 2461) only talks about NS packets, but I
agree. It seems logical for a proxy to handle all ND messages.

Whats the status of RFC 2461bis? Can we still ask for further
clarifications about the proxy behavior?

> [...]
> > The traditional proxy described in RFC 2461 is a router, what Thaler
> > describes is closer to a bridge. The protocol described in Thaler's draft
> > can't rely on routing for what it is doing, in stead it must AFAICS bypass
> > the routing altogether, either inside the kernel, or by pushing the
> > traffic through user space.
>
> No, Thaler's ND proxy is *not* a bridge; functionally, it's quite
> close, but from the implementation perspective, it's not.  All the
> communication terminates (at the IP layer) at the ND proxy (and that's
> why the TTL won't decrease, because practically the same request is
> replicated on the other links with TTL=255).  Therefore, it can act as
> a "router"  between two physical links, and the users of the links can
> still use e.g. link-local addresses.

I was talking about it from the functional point of view (and I didn't
actually call it a bridge ;)

My reasoning here is that Thaler's proxy passes IPv6 packets (except ND
etc) unchanged from one physical link to another, therefore it isn't a
router, but closer to a bridge.

The point is just that. We can't use the *routing* functionality to pass
the packet from one physical segment to another.

As I mentioned routing link-locals isn't possible, neither is routing of
multicast packets (at this moment), a router just forwards a packet to one
interface, not all of them, and last but not least, a router decreases the
hop limit of a forwarded packet.

This means we need some other mechanism than *routing* to achieve the
functionality in Thaler's draft.

> ND proxy doesn't "route" between physical segments, because by
> definition, all the physical segments share a subnet, and there are no
> specifics. On the other hand, it duplicates all ICMPv6 ND packets
> across the links (unless there is a mapping in a cache), and expands
> the IP layer subnet (even, the link-local address domain!) to span
> multiple links.

Exactly! Thaler's proxy doesn't route traffic, the MIPv6 proxy does. They
are not the same thing. My change allows a router (MIPv6 HA) to
correctly signal that it can't *route* a link-local packet.

There are IMO two different uses of proxy ND, which are quite different
from each other:

We have the Thaler proxy, with its "bridge" like behavior. It acts as a
proxy for *any* address on the subnet (if needed), and passes IP packets
between the interfaces unchanged.

Then we have the router (for example HA) acting as a proxy for a
*particular* node (for example MN) *routing* packets to it.

> Proxying link-locals break fully ND proxying.  I grant you that it may
> not work out of the box at the moment (because it hasn't been
> implemented! :-) but we shouldn't be making steps in the wrong
> direction here.. :-)

AFAICS a Thaler proxy would forward the packet using some other path than
ip6_forward(), therefore it wouldn't trigger the ICMP error message.

I'm not sure how proxy ARP is done in Linux, but I don't know if the
current proxy ND code is of any use for Thaler proxy.

The proxied addresses are explicitly stored in the nd_tbl and the proxy
relies on routing to get the packets delivered to the proxied node. This
is exactly what a HA should do, but it doesn't fit well into the Thaler
model.

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic

[Pekka Savola]

On Thu, 15 Jan 2004, Ville Nuorvala wrote:
> On Thu, 15 Jan 2004, Pekka Savola wrote:
> 
> > > The current proxy ND implementation in the kernel only captures multicast
> > > NS messages. A unicast NS (i.e. a NUD probe) won't be captured by the
> > > proxy, in stead it tries to _route_ it to the proxied node.
> >
> > Practically all ND packets should be proxied, I think.
> 
> Currently the specification (RFC 2461) only talks about NS packets, but I
> agree. It seems logical for a proxy to handle all ND messages.
> 
> Whats the status of RFC 2461bis? Can we still ask for further
> clarifications about the proxy behavior?

It's still at the starting phase -- now would be an excellent time to 
bring this up.

> My reasoning here is that Thaler's proxy passes IPv6 packets (except ND
> etc) unchanged from one physical link to another, therefore it isn't a
> router, but closer to a bridge.

Router only modifies the TTL.  Bridges do not respond to any Neighbor
Discovery (RFC2461) packets.. so it's not as clear as that.
 
> The point is just that. We can't use the *routing* functionality to pass
> the packet from one physical segment to another.

Yep.
 
> As I mentioned routing link-locals isn't possible, neither is routing of
> multicast packets (at this moment), a router just forwards a packet to one
> interface, not all of them, and last but not least, a router decreases the
> hop limit of a forwarded packet.
> 
> This means we need some other mechanism than *routing* to achieve the
> functionality in Thaler's draft.

Totally agree here.
 
> > ND proxy doesn't "route" between physical segments, because by
> > definition, all the physical segments share a subnet, and there are no
> > specifics. On the other hand, it duplicates all ICMPv6 ND packets
> > across the links (unless there is a mapping in a cache), and expands
> > the IP layer subnet (even, the link-local address domain!) to span
> > multiple links.
> 
> Exactly! Thaler's proxy doesn't route traffic, the MIPv6 proxy does. They
> are not the same thing. My change allows a router (MIPv6 HA) to
> correctly signal that it can't *route* a link-local packet.

The change may allow that signalling, but breaks the correct behaviour 
in general.

Note that MIPv6 spec just states that link-locals MUST NOT be
_tunneled_ to the mobile node, and site-locals SHOULD NOT.  It's still
fine to proxy for them (but discard them).  With L bit set, the HA is
just performing "DAD protection" for the address, with the intent to
discard the traffic.  Without L bit set, the HA is not supposed to do
even that.  As a matter of fact, it doesn't know the link-local
address of the MN in the first place.

So, it seems to be that the MIPv6 proxy should get the IP address to
proxy as an argument (put in nd_tbl or whatever), and it would just
proxy those addresses, and no change (like the one you proposed,
disallowing link-local proxying) would be needed.   So, with MIPv6 L=0 
link locals would not be entered in nd_tbl, so they would not be 
proxied; with MIPv6 L=1, link-locals would be entered in nd_tbl, but 
the packets would get discarded before they end up being tunneled to 
the MN.

Right?

> There are IMO two different uses of proxy ND, which are quite different
> from each other:
> 
> We have the Thaler proxy, with its "bridge" like behavior. It acts as a
> proxy for *any* address on the subnet (if needed), and passes IP packets
> between the interfaces unchanged.
> 
> Then we have the router (for example HA) acting as a proxy for a
> *particular* node (for example MN) *routing* packets to it.
> 
> > Proxying link-locals break fully ND proxying.  I grant you that it may
> > not work out of the box at the moment (because it hasn't been
> > implemented! :-) but we shouldn't be making steps in the wrong
> > direction here.. :-)
> 
> AFAICS a Thaler proxy would forward the packet using some other path than
> ip6_forward(), therefore it wouldn't trigger the ICMP error message.

It can give back ICMP error messages, if necessary.  I don't know 
which path a Thaler proxy would use though.

> I'm not sure how proxy ARP is done in Linux, but I don't know if the
> current proxy ND code is of any use for Thaler proxy.

It's a start, I think :-)
 
> The proxied addresses are explicitly stored in the nd_tbl and the proxy
> relies on routing to get the packets delivered to the proxied node. This
> is exactly what a HA should do, but it doesn't fit well into the Thaler
> model.

Yep, because there is no more specific route -- in the Thaler case, 
"querying whether the node exists on other physical links" gives the
more specific information ("route" of a kind). It's not really that 
different in my eyes..

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