[tahoe-dev] [tahoe-lafs] #867: use ipv6

Greg Troxel gdt at ir.bbn.com
Mon Feb 18 14:54:33 UTC 2013


Randall Mason <clashthebunny at gmail.com> writes:

> On Mon, Feb 18, 2013 at 10:23 AM, Jean Lorchat <jean at iijlab.net> wrote:
>>> (I'm guessing you are on Linux, but could be a different BSD.)  That's
>>
>> I am seconding Greg's guess.
>>
>> Then, to specify which interface for output with site-local
>> addresses, with the ping6 command on a linux box, you need to
>> specify it with a percent sign in-between (same as what happens in
>> the display output of the NetBSD ping6, see Greg's previous email).
>
> Yes, I'm on Linux in the above example.  I was making sure that ping6
> didn't fail on fc00::/7 addresses.  Since it doesn't fail, I think we
> can treat it as a normal address and not one that requires an
> interface identifier.  I have different experience with Windows 7 and
> such.  IPv6 has vastly different implementations different places it
> seems.  So much for KAME creating a great product and then it being
> reusable...

Agreed, my understanding is that fc00::/7 do not have the
scopeid/interface-id concept.

> IPv6 has vastly different implementations different places it seems.
> So much for KAME creating a great product and then it being
> reusable...

It hasn't been shown that it wasn't reusable.  What we've observed is
that Windows behaves in a way which is hard to understand, relative to
normal practice and standards.  To me that says more about Windows than
about KAME.

> Here's my wife's iBook pinging my linux computer:
>
>> iBook$ ping6 fe80::2ff:eeff:fedd:ccbb
>> PING6(56=40+8+8 bytes) fe80::2aa:bbff:fecc:ddee%en1 -->
>> fe80::2ff:eeff:fedd:ccbb
>> 16 bytes from fe80::2ff:eeff:fedd:ccbb%en1, icmp_seq=0 hlim=64 time=1.601 ms
>> 16 bytes from fe80::2ff:eeff:fedd:ccbb%en1, icmp_seq=1 hlim=64 time=2.343 ms

That's interesting.  Note that the 2nd line has %en1, and the last two.
So it's like the mac kernel decided to guess at the scopeid (perhaps
because only one interface was up).

>> linux$ tcpdump -n -i eth1 icmp6
>> 11:33:18.437626 IP6 fe80::2aa:bbff:fecc:ddee >
>> fe80::2ff:eeff:fedd:ccbb: ICMP6, echo request, seq 3, length 16
>> 11:33:18.437700 IP6 fe80::2ff:eeff:fedd:ccbb >
>> fe80::2aa:bbff:fecc:ddee: ICMP6, echo reply, seq 3, length 16
>> 11:33:19.440775 IP6 fe80::2aa:bbff:fecc:ddee >
>> fe80::2ff:eeff:fedd:ccbb: ICMP6, echo request, seq 4, length 16
>> 11:33:19.440837 IP6 fe80::2ff:eeff:fedd:ccbb >
>> fe80::2aa:bbff:fecc:ddee: ICMP6, echo reply, seq 4, length 16

> No interface identifier, not even in the fe80:x:: portion of the
> address.  But it sure doesn't work the other way around.  Just the
> invalid argument.  I need to either specify it with the %eth1 or the
> -I eth1 option to ping6.

interface identifers are never present on the wire.  They are only
present in the user/kernel socket interface to tell the kernel an
interface, because send() with a LL is incomplete, one needs a (addr,
interface) tuple.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20130218/883189f4/attachment.asc>


More information about the tahoe-dev mailing list