IPv6 Confusion

Leo Bicknell bicknell at ufp.org
Wed Feb 18 14:34:06 CST 2009


In a message written on Wed, Feb 18, 2009 at 12:55:19PM -0700, Aria Stewart wrote:
> What operational reasons are there for working with RA turned off?

Not picking on the original poster, as I have no idea if they would
have any personal experience with this or not.....

There was a kinder, gentler time when your Cisco IGS would run RIPv1
and spew forth a default route.  Your SunOS boxes all ran routed
by default, and received the default route.

Which, quite frankly, looks a lot like how RA's work.

After many people had entire campus networks brought down by
misconfigured boxes, prankster students, rogue network intruders
and boxes plugged into the wrong ports the operators of the world
universally turned this junk off.

It appears the IETF did not study these history lessons when designing
IPv6 RA's.  Now, even with our limited IPv6 deployment we find
plenty of stories where the NANOG and IETF test networks are unusable
for hours at a time due to misconfigured boxes, prankster students,
rogue network intruders and boxes plugged into the wrong port.

Allowing an UNAUTHENTICATED BROADCAST packet to determine where you send
your traffic is insane.  Rather than moving forward, this is a
giantantic step backwards for security and reliability.

It wouldn't be so bad if we could just turn it off.  Indeed, in
part you can.  On a static LAN there is no need for RA's.  Static
IP the box, static default route, done and done.

But, when DHCPv6 was developed the "great minds of the world" decided
less functionality was better.  There /IS NO OPTION/ to send a
default route in DHCPv6, making DHCPv6 fully dependant on RA's being
turned on!  So the IETF and other great minds have totally removed the
capability for operators to work around this problem.

Thus we are doomed, for now, to IPv6 networks that regularly become
unworkable for hours at a time.  Brilliant design!

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090218/8589f8ca/attachment.bin>


More information about the NANOG mailing list