It's Ars Tech's turn to bang the IPv4 exhaustion drum

Wed Aug 20 18:34:36 UTC 2008

>>> On 8/20/2008 at 1:54 AM, Iljitsch van Beijnum <iljitsch at 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:
> 
>>   http://www.attn.jp/presentation/apnic26-maz-ipv6-p2p.pdf 
> 
> 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 at globalstar.com 