[nycbug-talk] upcoming IPv6 meeting

[Miles Nordin]

>>>>> "cs" == Charles Sprickman <spork at bway.net> writes:

    cs> inet6 fe80::217:f2ff:fe50:de4c%en1 prefixlen 64 scopeid 0x5

    cs> if eventually you're an ISP and a customer calls up how do you
    cs> tell them to ping their gateway for troubleshooting?

honestly, if you need to read the address over the phone for some
reason, you just do it.  it's not too big a deal.  But the general
advice from the NetBSD help pages anyway is that we should be using
dynamic routing pretty ubiquitously on IPv6.  I've been running Quagga
since I set up IPv6 on my LAN---I followed their advice and didn't
turn up IPv6 until I was ready to do it with Quagga.  but at mrmcd I
did not use any dynamic routing (only had ~4 hours to install FreeBSD
and finish), so it's possible either way.

here is the tunnel from my colocated router to the C1720 at home:

-----8<-----
$ ifconfig gif1
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1476
        tunnel inet [XXX] --> [YYY]
        inet6 fe80::203:baff:fe0f:aa45%gif1 prefixlen 64 scopeid 0x6 
        inet 69.31.131.52 --> 69.31.131.53 netmask 0xfffffffe 
$ ping6 ff02::2%gif1
PING6(56=40+8+8 bytes) fe80::203:baff:fe0f:aa45%gif1 --> ff02::2%gif1
16 bytes from fe80::203:baff:fe0f:aa45%gif1, icmp_seq=0 hlim=64 time=0.868 ms
16 bytes from fe80::451f:17fb%gif1, icmp_seq=0 hlim=64 time=8.749 ms(DUP!)
16 bytes from fe80::203:baff:fe0f:aa45%gif1, icmp_seq=1 hlim=64 time=0.534 ms
16 bytes from fe80::451f:17fb%gif1, icmp_seq=1 hlim=64 time=7.140 ms(DUP!)
^C
-----8<-----

so, you do not always need to type it to do something like check
connectivity.  ff02::1 is all hosts.  ff02::2 is all routers (for
*BSD, this means anything running rtadvd to advertise prefixes).
ff02::5 is all OSPFv3 speakers.

A number of operating systems like FreeBSD and Mac OS X very stupidly
disabled pings to the v4 broadcast address after Smurf attacks,
following Windows's lead, when in fact all that's necessary to plug
the security hole is to disable forwarding broadcasts across
interfaces---you may, and should, and Cisco and NetBSD do, still
answer the broadcast ping so long as the reply stays on the same
subnet.  At least these two FreeBSD and Mac OS X will still respond to
the ipv6 all-hosts multicast address ff02::1 even though they've
turned off the analagous v4 feature.  This is a good thing, not a
security problem to get hysterical about.  but the idiots who turned
off the v4 broadcast ping feature would probably disable this one,
too, if they knew about it, so it's an example of how there are likely
more security problems lurking in v6 that we don't know about yet.

In general I think it's not customary to ssh to a link-local address,
although it'll work.  Link-local addresses are good for using as
next-hops when you are running dynamic routing protocols like OSPFv3.
It makes router-to-router links more switch-like and less router-like,
because you can plug any two of your routers together, and they'll
discover each other and work fine---you don't have to configure every
pair of ends onto a matching /30 subnet like before.  The routers will
still show up in 'traceroute'---they'll grab a global address from
somewhere else (like a /128 global scope alias that you added to lo0).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20070917/f317aa10/attachment.bin>