Re: IPv6 Deployment for the LAN

[Karl Auer <kauer () biplane com au>]

On Wed, 2009-10-21 at 14:34 -0700, David W. Hankins wrote:
> folks on this mailing list who have proposed you can predict SLAAC
> addresses based on prefix and MAC are confused; they are not taking
> into account the many clients that use temporary addresses by default
> when the A flag is set (these are intentionally not cryptographically
> predictable), or that clients may need to re-iterate their SLAAC
> algorithm if interfered with by a peer[...]

That was me. My suggestion was to use MAC information from switches to
build candidate addresses and ping6 them; rogue SLAAC-using hosts would
respond, allowing them to be located and fixed.

The OP I was replying to was concerned about clients that would do SLAAC
even when the RA told them not to. It seems to me that hosts advanced
enough to be able to do CGA or use temporary addresses (not necessarily
the same thing) are unlikely to be hosts that would fail to interpret an
RA correctly.

This approach would probably not be 100% successful - maybe the pings
don't get through, maybe the rogue doesn't answer pings, whatever. But
it would at least be a start. A host that doesn't answer *may* still be
a problem, but a host that does answer is *definitely* a problem. IMHO,
automatically locating even some of your dud hosts is better than having
to locate all of them the hard way.

> Ostensibly the solution to this problem is "per host RA", which has
> [...]
> This is of course a completely scalable and well thought out plan

Er - tap, tap - is this thing working? (Just testing my sarcasm
detector :-)

> To work around this problem, some DHCPv6 software implementers have
> elected to temporarily apply a fixed /64 bit prefix to all applied
> addresses until a prefix length can be made available in-band through
> some means.  This does neatly work around the problem; the hosts may
> now speak to one another.

I don't understand this. Could you elaborate? It seems to me that the
"simplest network imaginable" should still operate on link local
addresses.

> Dibbler is a solid software package.

Yes - and your note above tickles some vague memory that Dibbler has
implemented something along those lines...

> I am extremely skeptical that we'll ever reach where we're going if
> we get there one millimeter at a time all the while redrafting our
> plans over and over.

True - but that *is* pretty much how we got to where we are with
IPv4 :-)

> Someone has forgotten that the reason IPv4 deployed so pervasively is
> because it was so very trivially simple.

And some of its biggest disadvantages are there for the same reason. As
Einstein said, things should be made a simple as possible - but no
simpler.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer () biplane com au)                   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

Attachment: signature.asc
Description: This is a digitally signed message part