Hi Matthew, apologize in advance to you and the others if this does not land in the threaded index properly (I'm trying out the custom headers plugin for Evolution for the first itme) -- I just subscribed to the list. I should add, very interesting work done! (See my PS for more funny details.) Off the top of my head, there are a few things one would like to work with v6-only-supporting d-i: 1) support for picking up RAs at all, eg, routers, 2 a) support for picking up RDNSS from RAs (rdnssd exists, leveraging that ( http://www.remlab.net/ndisc6/ ) would be ... neat, since you can do various discoveries in userland (router / prefix discovery + picking out RAs), with these tools!), 2 b) support for listening to the "Bit 6 ( ’o’ or 0x40 )", "Other stateful configuration flag bit" of RAs, which suggests to stacks to go out and request a DHCPv6 request, (also used stateless for distribution of DNS/NTP info) 3) support for SLAAC (address only), 4) eventually and finally complete support for auto-configuration of all IPv6-only network settings, which I admit is far from trivial. All of this should of course inter-operate with IPv4 in some way. So, here's how I see this: 1. Attempt IPv4-config -> success/fail (possibly:) IPv4-config-fail? 2. Attempt IPv6-config -> success/fail What are thoughts on dual-stacking the installation process? Perhaps it's best to KISS and just go with whatever address family seems to work the moment the installation is attempted. I've attached a .txt and a .png for my tests of your i386 iso-image. Regards, Martin PS. I *just* now googled for IPv6 support in d-i and saw your post. Interesting timing. I happen to have a brand new Thinkpad w510 so I can probably test-build an amd64 image later. I was a bit saddened when I an hour ago realized d-i doesn't have any IPv6 support at all..., especially as I just setup a kvm-setup as: My original idea for this is purely for testing purposes, eg, testing out various IPv6-only things (including nat64/dns64) easily. DS.
v1_i386.iso (sha512: 762bdffabc1ee072f993631b48996928873c10bf4f98ef9899a0943982dfa58e89a9b43eca21c7e621ea43a5c0c6123126b167aafceda4bc4c7d2bc6d9681370).
kvm-setup:
*) a v6-only interface, bridged to the kvm-interface
*) a radvd announcing: a prefix, RDNSS and a gateway, at random intervals between 3s and 10s,
*) working ipv6-forwarding of the v6-only interface
*) apt-cacher proxy on my main host,
*) a x86_64 architecture test-host
Tests done:
Test A.
1. Entered manual address,
2. Saw gateway prefilled -- I guess you calculate it from the subnet, since it was subnet::1
3. Tried to remove it to test RA according to my (flawed) parse of your announcement-email: this failed, I had to enter something in order to continue,
4. Configured a literal http proxy, to my apt-cacher, eg [addresses]:3142 -- worked fine.
5. Continued with installation all the way and it seems to work fine.
6. Peek into the ongoing tcpdump of the entire process, to see that the client is indeed talking with a SLAAC address to my apt-cacher (!).
7. Wireshark reveals that the manually configured IP was only used by the installer to test NTP. Once the next RA comes the host uses that address instead, but both addresses appears to be configured because I sourced a wget from the manually configured address.
7. I observe some "^Q" characters in the uh, (ncurses?)-installer some times, usually near the cancel button, which distorts the graphics a little bit. Haven't seen it in other installers recently, not sure why it is there or whether or not it is your creation.
8. Installation has stopped in the "Installing the base system" stage, at "Validating dpkg...", been stuck for 20min now. Something's broken. Last line in syslog: "Jan 22 05:26:13 debootstrap: Setting up tasksel (2.88) ..."
Test B. Change: I'd lost a v6 route on my laptop, so I just rerun the test as is.
[ Repeat of Test A up to and including point 5: ]
6. Installation finishes without problem.
7. When I can login I see that there is a configured address from /etc/network/interfaces, as well as a RA-configured address. A method of specifying a inet6-section in /etc/network/interfaces without any address (SLAAC should come from kernel) is needed.
Test C. Change: I create a new kvm machine with arch i686 instead of x86_64.
1. Entered manual address, but this time forgot to add the /64, so I see a new "enter netmask" window. it suggests ffff:ffff:ffff:: which seems fine, so I go with that.
[ Repeat of Test A from 2 up to 5 ]
6. Installation seems to have hung up again, this time in step "Select and install software" ("Jan 22 07:03:07 pkgsel: starting tasksel") Not sure why; connectivity works (wget works) and host answers ICMPv6 on both the SLAAC and manually configured address.
7. I cancel here and try the next test.
Test D. Change: I put in a DNS entry for the apt-cacher address.
[ Take 1. from Test C ]
[ Repeat of Test A from 2 up to 5 ]
[ Repeat of Test B from 6 up to 7 ]
Eg, it worked (but I have double addresses...)
Suggestions:
Some tests seems to hang up (though in the first one I know certainly that my connectivity was out for a while).
Disregarding that for a while, I add this:
*) The manual typing in of an address should only be done when any automatic configuration (RA first, DHCPv6 later -- AFAIK there is working DHCPv6 code OTOH) fails, of course.
*) In the name of "feature parity" with v4, I guess it is fine for a successful automatic configuration probing to just continue right onto DNS/hostname parts. Either way, as long as address + gateway created with RA and SLAAC is not stored into /etc/network/interfaces, just as they're not if DHCP is used in v4, I guess we're fine.
*) Resolvers you typically want to configure somewhere OTOH, I guess.
So, try to get automated configuration probing in so that, if successful, users won't have to do much of anything. As I wrote in the email, there are a few bits and pieces to do here... But if the ndisc6 package can be leveraged, your work should become very much easier. If the network probing can work in an equivalent fashion as IPv4 as far as menus and what information is stored on the host and what's kept in the network, I think users will be satisfied (or at least not upset).
Later on, perhaps configuration of dual-stack services should be done at installation-time as well. I'm especially thinking of the configuration and preference of v6 resolvers if they exists. And re v4 vs v6 preference of resolvers, it's my understanding that the error handling and completeness of Win7's resolver lib is a bit better than Debians, and using Win7 as a reference, it does seem to prefer v6 resolvers, if they exist , over
Attachment:
d-i-6-test-graphic-error.png
Description: PNG image
