>> ==+=== 3ffe:2a00:100:3001::/64
>>   | vx0
>> pastaws0 ---------------------------------+ tunnel
>>   | xl0					  |
>> ==+=== 3ffe:2a00:100:3002::/64		  |3ffe:2a00:100:3002::/64
>> 					spam
>Yes, as this is similar to what you can do in IPv4 with proxy-arp, I made
>an uninformed guess that  it would work in IPv6 with ND too. I see now
>this is not the case. 
>
>I think the most elegant solution would be to specify `link-local' scope
>independent from the underlying physical network, and only specify it
>in terms of addressing. I.e. link-local scope is e.g. all hosts with
>network-prefix 3ffe:2a00:100:3002::/64. I think this would be rather
>elegant, but I cannot oversee all the implementation difficulties
>that might arrise from it. But it makes sense to me, especially
>the gained flexibility in defining link-local hosts for underlying
>networks that are not-quite-entirely-like-Ethernet, i.e. non-shared
>medium ones.

	No I don't think like the above.  If link-local scope is to be
	understood as "subnet local", the naming should have been "subnet-local
	scope".  This will complicate forwarding rule for pastaws0 very much.

>The alternative would be to implement something similar as proxy-arp
>for IPv6. I think that would be something we really would like to 
>avoid as it has the taste of an ugly hack to it. Or a little less
>ugly might be something like a meta-tunnel interface, i.e. a single
>IPv6-interface representing all `real' tunnels with the same prefix,
>and multiplexing traffic between the tunnels as if it was a shared
>medium. This meta-tunnel would be similar to an Ethernet switch in
>some ways. Not really elegant, but it would not require modification
>of link-local specs and such. Hmmm, maybe I should try to implement
>such a thing and see how well or how bad it works... Or... you tell
>me now it is a very silly idea (if you think so, please do ;-}.
>

	Yes, I agree that proxy NDP (similar to proxy ARP) should work
	properly.
	The issue is that we need to do a careful analysis about how
	link-local scope multicast should work, as link-local scope multicast
	is used everywhere in the specification.

>Not providing a solution is the final alternative, but wouldn't that
>in the current v6 addressing scheme imply you'd need to assign a 64 bit
>network prefix to each and every tunnel for everything to work
>nicely? For a large ISP handing out v6 over v4 tunnels that might
>eat-up address-space at a rather alarming rate I think.

	I agree, that if we assign 64bit network to every PPP customer we
	will be doomed.  We need to fix it (actually KAME/FreeBSD PPP does
	some trick for proxy NDP).  
	I usualy think of it as, for example, that we have a ethernet behind
	"spam".  We do not need to have global address on the tunnel, RIPng
	and other routing protocols run just fine.  Actually "gateway" portion
	of routing table MUST be link-local address.

itojun


==+=== 3ffe:2a00:100:3001::/64
  | vx0
pastaws0 ---------------------------------+ tunnel
  | xl0					  |
==+=== 3ffe:2a00:100:3002::/64		  |
					spam
					  |
					==+=== 3ffe:2a00:100:3003::/64