[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: IPv6 support in debian installer

Hi Martin,

Thanks for giving my changes a test, and especially for your detailed

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

>   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

  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

> 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.

- Matt

Reply to: