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