Hi Martin, Thanks for giving my changes a test, and especially for your detailed feedback.
On Sat, Jan 22, 2011 at 03:47:39AM -0500, Martin Millnert wrote: > 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, This is handled in the kernel, and all I've got to do (and what I'm working on now) is to integrate it into the d-i process, so netcfg knows that whether it worked succeeded and can proceed accordingly. > 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!), I was aware of the existence of rDNS-in-RA, but I didn't know what tool (if any) on Linux handled it. Looks like rdnssd is the way to go. Do you happen to know what radvd magic is required to send out RAs with the rDNS servers in, so I can test it (and avoid having to run DHCPv6 at home)? > 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) Going out to DHCPv6 is on the todo list (a fair way down, because it involves getting udebs of wide-dhcp6c sorted). I hadn't intended on examining the RA for bit6, but I can't imagine it'll be massively complicated. > 4) eventually and finally complete support for auto-configuration of > all IPv6-only network settings, which I admit is far from trivial. I'm up for handling anything that d-i handles for IPv4, pretty much, but I'm not planning on going all out with every possible bit of network configuration (SIP servers? Naaaah). > 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 My overall mental map of netcfg is: for each interface attempt to autoconfigure v4/v6 if autoconfiguration succeeded consider the network config all done if autoconfig failed for all interfaces ask for interface to configure manually configure that interface manually ensure we have gateway, DNS, hostname, domain name, ask for it if necessary write out all settings > 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. My philosophy with netcfg is to configure the network only as far as is required to complete the rest of the installation process. So, if we find working IPv4, I don't want to deal with IPv6. Similarly, if we find autoconfigured IPv6, I'm not going to ask about manually configuring IPv4. If we find one interface that works, I'm not going to ask about all the other interfaces and whether the user would like to configure those as well just now. Obviously, anything we find out during the install should be reflected in the running system, so we provide a semblance of a working system out of the box, but IMAO there's not point in bugging the user with lots of network configuration questions if they're not required. In this, I *think* I'm in line with the existing feel of netcfg, as it only attempts to configure one interface. > 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: Since it's rare for people to have v6-only networks, I guess nobody's really worried about it too much. I don't have a need for it myself, I'm just doing this partially as an intellectual exercise, but I also think it's getting to the point where people *are* going to have v6-only networks soon, and I'd really prefer it if d-i wasn't the only reason someone had to setup a v4 infrastructure. Now I'm curious to know if any other Linux distros have support for a pure-v6 installation process... > 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. Yeah, I've noticed those in my testing as well, I just figured it was a glitch in KVM, but testing it now they're on my scratch laptop too... and testing a recent downloaded mini.iso, it's not there. Freaky. I guess I'll have to look into that one. > 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. Weeeeell... if you don't put anything into /e/n/interfaces for the interface, it doesn't come up, so the kernel doesn't autoconfigure it. I'd like it if ifupdown had a 'slaac' interface type, so I could just put "iface eth0 inet6 slaac" and be done with it, but in the meantime I'll settle for what I'm planning to do now: # This is a SLAAC-configured interface iface eth0 inet6 manual post-up ip link set eth0 up down ip link set eth0 down > *) 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. Yep, I definitely don't want anyone to have to type in anything if their network is setup to announce configuration. Again, thanks for all your feedback, especially the pointers to ndisc6. It will definitely come in handy. Keep an eye on the mailing list for further announcements. Thanks, - Matt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110122101639.gu3...@hezmatt.org
