IPv6 Deployment for the LAN

Thu Oct 22 23:16:41 UTC 2009

On Thu, Oct 22, 2009 at 11:12:14AM +1100, Karl Auer wrote:
> > 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.

To use a link local address, you also have to supply the application
with the interface name for it to be used upon.  The application has
to pass this as an extra argument when opening a socket; it isn't part
of the regular gethostbyname/socket/connect.

Provided you have applications that have a separate dialog field for
the interface name so LL's can be used, you're probably going to be
entering in the IPv6 LL address in all its glory.  First, you are not
going to have LL addresses in /etc/resolv.conf because you can't list
interface names there (I think it is the same for other OS's
analogues of their nameservers list), and second people are not going
to be very well motivated to put LL addresses in DNS because those
addresses are not globally applicable; they would have to use DNS
views.

So it is not really very realistic to expect LL to actually be used
except to bootstrap.

Maybe it's possible for some proprietary printer or fileshare network
stuff to continue working on LL's (or, ironically, routing protocols
or DHCPv6 itself), but anywhere else ("mail.example.com",
"contacts.example.com"), anywhere real, and the network goes dark.

Unless of course it can fall back on native IPv4, or has entered a
bogus covering /64.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20091022/d2502253/attachment.sig>