[nycbug-talk] IPv6 in Japan

[Miles Nordin]

>>>>> "th" == Tillman Hodgson <tillman at seekingfire.com> writes:
>>>>> "il" == Isaac Levy <ike at lesmuug.org> writes:

    th> What ircd were you planning on using (that has IPv6 support

hybrid has stable v6 support, but they broke CIDR bans between 7.0 and
7.2, so I can't recommend it.

anope services does not crash on my v6 ircnet, but it also doesn't
have any special v6 support AFAICT.

    >> my two favorites: ipsec intergration into the base stack

    il> HECK YEAH.

you still have to use racoon.  It's really no better than v4 ipsec.
It's not ``more tightly integrated'' or any nonsense like that.  It's
just required to claim compliance.

In fact so far I think FreeBSD and NetBSD release versions have
FAST_IPSEC for v4 only, not v6, because recently there was news of
FAST_IPSEC v6 new in -current.  so v4 has better IPsec in existing
systems.  Does Cisco support v6 in their IKE?

anyway this ``integration into the base stack'' is just marketing
garbage.

    il> IPSEC isn't just for encrypted tunnels, tunnelling was merely
    il> the first good application of IPSEC.

yeah I read on one of the NetBSD lists the iSCSI guys are using some
kind of channel-binding scheme to replace their CHAP authentication.
It depends on having separate SA's for the TCP circuit your IPsec
session runs over.  It's important for the kernel to clear the SA if
it drops the TCP circuit, which the poster (sorry I forget who) was
saying Solaris's (still closed source IKE &) IPsec stack does, but
NetBSD doesn't.  need to understand more about channel binding soon.

Also OSPFv3 uses IPsec to replace the homerolled message digest scheme
in OSPFv2.  It's not specified how you are supposed to maintain the
SA's for a multicast protocol.  What cisco does, is set up all these
special cases for OSPFv3 IPsec, to dispense with IKE entirely, and let
you configure static SA's in an equivalent way to bring back an
interface that feels like OSPFv2's.

    il> IPSEC advantage over ssl/tls is complete transport layer,
    il> packet-level crypto- as opposed to application-layer crypto...

what's the ``advantage'' to that?  ``easier to do traffic analysis
attacks''?

It may have an advantage of being easier to implement correctly in
hardware because the performance-critical IPsec part is broken out
from IKE so it churns less than Team TLS's manure field, has zero
ASN.1 garbage in it, and has Counter Mode.  (after we have our
InfiniPath/SCTP - to - Ethernet/TCP bridges, we can put IPsec as well
as TCP inside the bridge instead of inside the Unix box.)

    il> DHCP, farewell.  I'm still confused about how to get DNS
    il> Servers though...  (but historically, this was a band-aid hack
    il> idea to DHCP that stuck- because it worked...)

yes, I have that problem.  I do automatic DNS updates for v4 DHCP
users, but v6 addresses don't get registered in DNS at all.

You could maybe give each client a TSIG key and let them nsupdate
their own records using some more generalized ifwatchd to provide the
hooks on address discovery.  I don't have anything like that working.
-------------- 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/20070324/1e4ac485/attachment.bin>