[BBLISA] Last night's IPv6 talk

[Daniel Hagerty]

[ Something in between my mail server and reader really doesn't like
Ned's mail.  Not v6 related.  If somebody has a copy of one of his
recent mails with full headers as it left bblisa, I'd appreciate a
copy. ]

> Not previously mentioned, the other security that NAT offers is internal
> network roadmap masking.  That is, somebody outside has no way of knowing
> your internal network topology or subnet ranges and possible router hops.  

    I don't have any references to this, but somebody(ies) has been
doing some work on topology discovery through NATs.  There are enough
leaks to get a fair amount of information; things like IP TTLs,
Received headers in mail, web proxies, and split DNS misconfigurations
were mentioned in whatever I saw.  Doubtless more.  This is pretty
typical with technologies meant primarily to solve a non-security
problem that have a coincidental security use; consider ethernet
switching and sniffing.

> see how slowly things move when you're trying to be ideal.  If striving for
> perfection, then critical components (DNS, DHCP) get left out by the time
> you need to use them.  So, just as you can expect people to use DHCPv6
> despite extremist objections, so you can expect some organizations to do

    Couple of things in this area:  I can't imagine any service
provider deploying to end users that wasn't some kind of dual-stack
setup for the forseeable future.

    Personally, I don't really need DHCPv6, it's merely a "would be
nice".  My hosts at home obviously have working DNS, they just get it
via DHCPv4.  I could certaintly get a DHCPv6 server, and the unix
boxes are supposed to run at least ISC dhclient6, if not a few others.
I wouldn't be surprised if OS-X could be abused into running ISC's
dhclientv6.  My XP machine could most obviously handled by upgrading
it.  But this would all be effort for relatively low gain.

    Getting back to the sort of things you might see ISPs do, comcast
is trying several technologies in their trials:

* Native Dual Stack

* 6rd - This is 6to4 with ISP address space and a relay run by the
  provider, skipping 6to4's corner case problem(**).  Obviously, this
  is a dual stack setup.

* DS-Lite - v6 only in the core network, dual stack on the customer
  site.  CPE tunnels v4 over the v6 core to reach a big v4 NAT box
  somewhere inside the v6 core network.  Probably using ISC aftr.

In none of these does DHCPv4 go away.

    Some other dangling bits from the talk:

    Somebody asked me about spam over v6.  I initially thought "zero"
after filtering for false positives, but having run the search a
different way, I've got something like 130 pieces of spam that
involved IPv6 and weren't the case where somebody forwarding to me
sank it over v4 and delivered it to me over v6.  This is drawn from
180 days worth of spam totalling ~16500 pieces.

    While I mentioned the nasty way IPv6 hosts will listen to any and
all route advertisements, I didn't mention that you should be
bothering your switch vendors about "RA-Guard".  Remember that day
some yahoo on your network lit up a DHCP server and took down his
subnet?  Same problem in IPv6.  One similar solution to the problem is
to have your switches filter route advertisements on all but the port
the real routers are on.  Bug your vendors about this.


    I also want to thank you all for coming!  I'm generally lurking
somewhere in the vicinity of this email address if you have more
questions.


    (**) I didn't get to cover the "6to4 corner case" very well during
the talk.  6to4 has a failure mode that makes network engineers hate
it.  The relay you use for your outbound traffic isn't guaranteed to
be the same as the relay your inbound traffic uses, and if the inbound
relay somebody is using to reach you is broken, it sucks to be you,
because you can't change that.  When I read that description, I can't
help but add "just like the internet".

    Here's a more concrete example.  Below is a traceroute from my
house to 192.88.99.1, which is the 6to4 anycast address:

traceroute to 192.88.99.1 (192.88.99.1), 64 hops max, 40 byte packets
 1  er1.nyc1.speakeasy.net (66.92.73.1)  24.172 ms  21.230 ms  19.781 ms
 2  220.ge-0-1-0.cr2.nyc1.speakeasy.net (69.17.83.201)  20.247 ms  22.054 ms  19.356 ms
 3  nyiix.he.net (198.32.160.61)  29.644 ms  24.015 ms  24.601 ms
 4  10gigabitethernet1-1.core1.nyc4.he.net (72.52.92.45)  21.213 ms  21.690 ms  21.895 ms
 5  192.88.99.1 (192.88.99.1)  20.118 ms  18.868 ms  20.547 ms

and here's the "same" traceroute from MIT:

traceroute to 192.88.99.1 (192.88.99.1), 30 hops max, 40 byte packets
 1  server-net.kalgan.csail.mit.edu (128.30.2.2)  0.283 ms  0.316 ms  0.396 ms
 2  kalgan.trantor.csail.mit.edu (128.30.0.245)  0.278 ms  0.369 ms  0.389 ms
 3  B24-RTR-2-CSAIL.MIT.EDU (18.4.7.1)  0.318 ms  0.344 ms  0.428 ms
 4  EXTERNAL-RTR-3-BACKBONE.MIT.EDU (18.168.0.50)  0.512 ms  0.588 ms  0.675 ms
 5  NY32-RTR-1-BACKBONE-2.MIT.EDU (18.168.1.34)  5.975 ms  6.056 ms  6.130 ms
 6  tge-0-2-0-3.4006.newy.layer3.nlr.net (216.24.184.101)  6.959 ms  7.052 ms  7.033 ms
 7  wash-newy-98.layer3.nlr.net (216.24.186.23)  11.702 ms  12.531 ms  12.520 ms
 8  leviathan-nlr-10g0-0-0-0.3rox.net (192.88.115.164)  18.293 ms  18.275 ms  18.291 ms
 9  bar-leviathan-ge-6-0-0-1.3rox.net (192.88.115.84)  18.217 ms  18.265 ms  18.315 ms
10  6to4-bar-f4-0.3rox.net (192.88.115.135)  17.400 ms * *

    These are different relays.  If I'm talking to a 6to4 host at MIT,
and the 3rox relay is broken, the connection won't work.  Web browsing
tends to be particularly painful, as you'll experience a 60 second
pause before it tries v4.

    In practice, I've seen this failure mode 3 times in two years.
Hard for me to get upset about that when held up to all the other
random "internet fail".  I suspect the network engineers are suffering
from sampling bias.