IPv6

dhcp6c is missing from the image. let's fix that :-)

I have been testing DHCP-PD with embedded-1.32.2.img and have a dual-stack connection up and running.

But I have a feature request: can we have a gui config option for sla-len?

The prefix being assigned is a /56, not a /48, so with the default dhcp6c.conf, an IPv6 connection is not established. I get:

update_prefix: create a prefix 2001:bb0:d00:d00::/56 pltime=604800, vltime=2592000
add_ifprefix: invalid prefix length 56 + 16 + 64

But when I replace the dhcp6c.conf file with:

interface ng0 {
                send ia-pd 0;
};
id-assoc pd 0 {
                prefix-interface vr0 {
                        sla-id 1;
                        sla-len 8;
                };
};

The session comes up:

update_prefix: create a prefix 2001:bb0:d00:d00::/56 pltime=604800, vltime=2592000
ifaddrconf: add an address 2001:bb0:d00:d01:20d:b9ff:fe18:bee0/64 on vr0

A config option for sla-id would also be useful if people want to use an id other than 1, but a config option for sla-len is essential for any ISP that assigns a prefix other than /48. Of course, rather than asking the user for sla-len, it would make sense to ask for a prefix size and subtract that from 64 to get the sla-len value.

I'll take a look, here is the newest image for dhcp-pd, it just has dhcp6c put back in :-)

http://m0n0.ch/temp/embedded-1.33-pre3.img

Sla-id and sla-len options are in the beta

http://m0n0.ch/wall/beta.php

Thanks. The prefix length works. The beta image can now bring up a dual-stack session here without any modifications.

And the sla-id works, but not for a value of zero. The GUI accepts and saves 0, but dhcp6c.conf is written with sla-id set to 1.

If a default of one is being forced, this should probably be made clear in the GUI as I assumed it would be zero when nothing was entered.

Also, there's a tiny typo of sorts after "Select site-level aggregator ID and ISP prefix length." - the current value for prefix length appears here.

I'll fix these this evening I hope, thanks for the feedback ! 

It was a rush to get it and one other feature in before mk released the beta, so minimum testing was done by me

Hi -

I have 1.33b1 loaded in a virtual machine and am having problems with the DHCPv6 client. How do I get it to start up? I have DHCP enabled as my IPv6 WAN mode, but m0n0 never sends a Solicit. What am I missing here?

Thanks!
-Matt

As a follow up to my previous post, I noticed that m0n0's link local addresses as reported on the Status page seem malformed:

WAN:
   fe80::a00:27ff:fe57:a9d6%em1/64
LAN:
        fe80::a00:27ff:fe7b:d6bb%em0/64

What is the %em1 and %em0 - that looks like an issue to me.

I'm also wondering if perhaps m0n0's DHCPv6 client on the WAN is not starting up because I do not have a DHCPv6 DUID set. I assumed the DUID would be automatically composed by m0n0 as one of the three types defined in RFC 3315 Section 9: DUID-LLT, DUID-EN, or DUID-LL. What is the purpose of m0n0's DHCPv6 DUID field?

-Matt

we have people using this, so AFAIK it does work, but will try to take a peek next week and see if there maybe something broken if you still have an issue.

as we use dhcp6c, when it starts it looks for /var/db/dhcp6c_duid and if it doesn't find one, it generates one.  This means that on a cold boot you will get a new duid.

the duid option is to allow you to enter one which gets put into the dhcp6c config, so it doesn't use the one in that file,  but uses the specified one all the time.

if you run dhcp6c with -dD you will see debug messages like

$ /tmp/dhcp6c -c /tmp/dhcp6c.conf.sample -i -d -D -f em1
May/06/2010 09:31:07: gethwid: found an interface em0 for DUID
May/06/2010 09:31:07: get_duid: generated a new DUID: 00:01:00:01:13:75:48:db:08:00:27:ef:77:3b
May/06/2010 09:31:07: get_duid: saved generated DUID to /var/db/dhcp6c_duid

give that it changes on boot, and also that the above starts 00:01  I would say this is DUID-LLT

Hi brushedmoss -

I resolved my original issue with DHCPv6 and DHCPv6-PD on the WAN. It turns out that m0n0wall's SLA ID field for DHCPv6-PD is *decimal*. I assumed it was hex and was using "ffff" with a length of /48, which resulted in dhcp6c.conf parse errors during startup. The description included with m0n0wall's SLA ID field states:

"Select site-level aggregator ID and ISP prefix length. If ID is 1 and the client is delegated an IPv6 prefix 2001:db8:ffff and prefix 48, this will result in a single IPv6 prefix, 2001:db8:ffff:1::/64 ."

It may be helpful for other m0n0wall users if this description was expanded to mention that the value is decimal. Here's the manpage text for dhcp6c.conf from Ubuntu which does mention this caveat:

             sla-id ID ;
                     This statement specifies the identifier value of the
                     site-level aggregator (SLA) on the interface.  ID must be
                     a decimal integer which fits in the length of SLA IDs
                     (see below).  For example, if ID is 1 and the client is
                     delegated an IPv6 prefix 2001:db8:ffff::/48, dhcp6c will
                     combine the two values into a single IPv6 prefix,
                     2001:db8:ffff:1::/64, and will configure the prefix on
                     the specified interface.

After figuring this out I am able to get DHCPv6 and PD working. The only issue I now have is that m0n0wall does not appear to install a default route for IPv6. If I try to send an ICMPv6 ping from a connected LAN client (which assigned itself a valid global address via SLAAC from m0n0wall) to a host on the WAN, m0n0wall returns an ICMPv6 no route to destination error. Are you experiencing the same behavior?

-Matt

Thanks Matt, I will update the description in m0n0wall and get it to check for decimal only input.

the WAN interface is DHCP, this is used for address assignment, but your default gateway is set by m0n0wall receiving an RA.

you can check that m0n0wall is configured for this by going to /exec.php and executing

Code:

sysctl -A net.inet6.ip6.accept_rtadv

This should be set to 1.

Hi brushedmoss,

Thank you!

I have my test network set up to send RAs, so the m0n0wall box should be building a default route. I will double check this and also check my m0n0wall config using the command you specified. I'll report back shortly.

-Matt

Hi brushedmoss,

I confirmed that my test network is indeed sending RAs on the WAN. I can see this in the m0n0wall log files as well:

Code:

Feb 7 20:50:53 kernel: in6_ifadd: 3001:dddd:0:0457:0a00:27ff:fe7b:d6bb is already configured
Feb 7 20:50:53 dhcp6c[331]: client6_script: child: exec failed: Permission denied
Feb 7 20:50:53 dhcp6c[331]: client6_script: child: exec failed: Permission denied
Feb 7 20:50:53 dhcp6c[332]: client6_script: child: exec failed: Permission denied
Feb 7 20:50:53 dhcp6c[332]: client6_script: child: exec failed: Permission denied
Feb 7 20:50:57 rtadvd[296]: <ra_input> received RA from fe80::20b:bff:fe00:1 on non-advertising interface(em1)
Feb 7 20:51:01 kernel: in6_ifadd: 3001:dddd:0:0457:0a00:27ff:fe7b:d6bb is already configured
Feb 7 20:51:38 last message repeated 5 times
Feb 7 20:51:07 rtadvd[296]: <ra_input> received RA from fe80::20b:bff:fe00:1 on non-advertising interface(em1)

Checking my routes with netstat also confirms that no default route is being set for IPv6:

Code:

$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.200.1      UGS         0        7    em1
127.0.0.1          127.0.0.1          UH          1       56    lo0
192.168.1          link#1             UC          0        0    em0
192.168.1.10       00:1b:21:0b:05:bd  UHLW        1       24    em0   1189
192.168.1.199      00:1b:21:0b:05:bd  UHLW        1        3    em0    861
192.168.200        link#2             UC          0        0    em1
192.168.200.1      00:0b:0b:00:00:01  UHLW        2        2    em1    856
192.168.200.2      127.0.0.1          UGHS        0        0    lo0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::/96                             ::1                           UGRS        lo0
::1                               ::1                           UHL         lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
2002::/24                         ::1                           UGRS        lo0
2002:7f00::/24                    ::1                           UGRS        lo0
2002:e000::/20                    ::1                           UGRS        lo0
2002:ff00::/24                    ::1                           UGRS        lo0
3001::/64                         link#2                        UC          em1
3001::2                           08:00:27:57:a9:d6             UHL         lo0
3001:dddd:0:457::/64              link#1                        UC          em0
3001:dddd:0:457:201:2ff:fe03:406  00:01:02:03:04:06             UHLW        em0
3001:dddd:0:457:21b:21ff:fe0b:5bd 00:1b:21:0b:05:bd             UHLW        em0
3001:dddd:0:457:a00:27ff:fe7b:d6bb 08:00:27:7b:d6:bb             UHL         lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%em0/64                     link#1                        UC          em0
fe80::21b:21ff:fe0b:5bd%em0       00:1b:21:0b:05:bd             UHLW        em0
fe80::a00:27ff:fe7b:d6bb%em0      08:00:27:7b:d6:bb             UHL         lo0
fe80::%em1/64                     link#2                        UC          em1
fe80::20b:bff:fe00:1%em1          00:0b:0b:00:00:01             UHLW        em1
fe80::a00:27ff:fe57:a9d6%em1      08:00:27:57:a9:d6             UHL         lo0
fe80::%lo0/64                     fe80::1%lo0                   U           lo0
fe80::1%lo0                       link#5                        UHL         lo0
ff01:1::/32                       link#1                        UC          em0
ff01:2::/32                       link#2                        UC          em1
ff01:5::/32                       ::1                           UC          lo0
ff02::%em0/32                     link#1                        UC          em0
ff02::%em1/32                     link#2                        UC          em1
ff02::%lo0/32                     ::1                           UC          lo0

I also confirmed the following:

Code:

$ sysctl -A net.inet6.ip6.accept_rtadv
net.inet6.ip6.accept_rtadv: 1

For my test setup I am assigning 3001::2 to the m0n0wall WAN interface (DHCPv6 server is 3001::1). Prefix length is 64. The DHCPv6 server is providing the prefix 3001:dddd::/64 to the m0n0wall. The m0n0wall is correctly building a global LAN IPv6 address using the 3001:dddd::/64 prefix and including that same prefix in RAs on the LAN. My LAN client is able to build a valid global IPv6 address and ping the m0n0wall's global IPv6 address on the LAN. The only issue is routing *through* the m0n0wall. Do you have similar problems or is this working for you?

Thanks!
-Matt 

Hi Matt, I have the same problem, will have to dig some more to see where it is.  There is no obvious reason why the default gw isn't set.  Even using rtsol it won't set.

What are you using for your upstream device, i.e. what is sending the RA to m0n0wall ?

Also, what is your LAN side ipv6 configuration, is it dhcp-pd or static , I assume it's dhcp-pd ?

Hi brushedmoss,

Thank you for confirming this. I am using a proprietary Linux based RA deamon on the WAN. It is similar to radvd which should also work fine for this as well.

My LAN side configuration is dhcp-pd.

-Matt

Hi Matt, I have the same problem, will have to dig some more to see where it is.  There is no obvious reason why the default gw isn't set.  Even using rtsol it won't set.

What are you using for your upstream device, i.e. what is sending the RA to m0n0wall ?

Also, what is your LAN side ipv6 configuration, is it dhcp-pd or static , I assume it's dhcp-pd ?