On 8/20/2008 at 1:54 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote: On 20 aug 2008, at 3:31, Randy Bush wrote:
matsuzaki-san's preso, i think the copy he will present next week at
apops:
He (she?) says packets will ping-pong across the link if they are addressed to an address on the p2p subnet that isn't used. However,
this is only true if there is no address resolution on the subnet, which would be the normal mode of operation with IPv4 on p2p links because those links don't have addresses and there is no ARP. With v6
on the other hand, ND can work on all link types and PPP does negotiate an address of sorts.
So whether this actually happens on a true point-to-point link is open with IPv6, and if it's a point-to-point ethernet or similar link you
only get some neighbor discovery traffic that goes nowhere, not an increase in actual traffic.
On a "true" P-to-P link, there is no netmask, no? A netmask is a concept that applies to broadcast media, like Ethernet. Even if you only have two hosts on an Ethernet link, it's not really P-to-P in the strict sense. For example, my IPv6-over-IPv4 tunnel from home (thank you HE, tunnelbroker.net) terminating on a Soekris net5501 running FreeBSD 7.0 (im s0 l33t!!11), gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280 tunnel inet 24.6.175.101 --> 72.52.104.74 inet6 fe80::200:24ff:feca:91b4%gif0 prefixlen 64 scopeid 0x7 inet6 2001:470:1f04:2fc::2 --> 2001:470:1f04:2fc::1 prefixlen 128 Note the prefixlen on the P-to-P portion inet6 configuration, 128. And the IPv4 tunnel part doesn't bother with a netmask. It doesn't make sense for a P-to-P. But the link-local on the gif(4)... well, hmmm. But as for how ND works over a P-to-P, the FreeBSD stack seems to be a little odd. I see, IP6 2001:470:1f04:2fc::2 > 2001:470:1f04:2fc::1: ICMP6, neighbor solicitation, who has 2001:470:1f04:2fc::1, length 24 IP6 2001:470:1f04:2fc::1 > 2001:470:1f04:2fc::2: ICMP6, neighbor advertisement, tgt is 2001:470:1f04:2fc::1, length 24 IP6 2001:470:1f04:2fc::1 > 2001:470:1f04:2fc::2: ICMP6, neighbor solicitation, who has 2001:470:1f04:2fc::2, length 24 IP6 2001:470:1f04:2fc::1 > 2001:470:1f04:2fc::2: ICMP6, neighbor solicitation, who has 2001:470:1f04:2fc::2, length 24 IP6 2001:470:1f04:2fc::1 > 2001:470:1f04:2fc::2: ICMP6, neighbor solicitation, who has 2001:470:1f04:2fc::2, length 24 My FreeBSD 7.0 occasionally will attempt gratuitous ND, and the other end responds, but when the remote tries to find us... silence. I don't think it's my ipf ruleset either. I tried to figure out if this is a bug or feature, but digging in src/sys/netinet6... well, it's been several years since I was last in there and it made my brain hurt. But despite all of that, it all works pretty sweetly. This is from a FreeBSD 6.2 host that does autoconf to the tunnel endpoint in my tunnelbroker.net /48 (and uses temporary, privacy extension addresses, m4d l33tnes), $ /sbin/ping6 www.freebsd.org PING6(56=40+8+8 bytes) 2001:470:8045:0:7034:f7e7:3d02:c41a --> 2001:4f8:fff6::21 16 bytes from 2001:4f8:fff6::21, icmp_seq=0 hlim=56 time=16.844 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=1 hlim=56 time=17.674 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=2 hlim=56 time=15.692 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=3 hlim=56 time=45.123 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=4 hlim=56 time=116.619 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=5 hlim=56 time=22.286 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=6 hlim=56 time=18.861 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=7 hlim=56 time=15.797 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=8 hlim=56 time=15.391 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=9 hlim=56 time=19.165 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=10 hlim=56 time=47.429 ms ^C --- www.freebsd.org ping6 statistics --- 11 packets transmitted, 11 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 15.391/31.898/116.619/28.985 ms B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com