[OpenWrt-Devel] "option ip6assign 60"

[Gert Doering]

Hiya,

I've installed "trunk (r40576)" on a few boxes because I want to play
around with homenet (hnetd / package hnet-full).

Before I even get there, I'm wondering about something. The sample
"/etc/config/network" file has an option in there which confuses me:

config interface 'lan'
option ifname 'eth1'
# option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

what is "option ip6assign" good for, and why does it default to "60"?
("option bridge" commented out by me, as hnetd supposedly does not
like bridges)

The effect it has is that the interface in question receives a /60 as
IPv6 network connected to it:

***@OpenWrt:/etc/config# ifconfig -a

eth1 Link encap:Ethernet HWaddr 10:FE:ED:E6:5F:32
inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::12fe:edff:fee6:5f32/64 Scope:Link
inet6 addr: fd83:af19:9ef::1/60 Scope:Global
inet6 addr: 2001:608:0:c10::1/60 Scope:Global

... which is not exactly "what the IETF says should be on a LAN" - but
some other parts of the system see the prefix as /64, like when sending
out a RA on that LAN

17:51:19.741002 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 192) fe80::12fe:edff:fee6:5f32 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 192
hop limit 0, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 10:fe:ed:e6:5f:32
mtu option (5), length 8 (1): 1500
prefix info option (3), length 32 (4): 2001:608:0:c10::/64, Flags [onlink, auto], valid time 2817s, pref. time 1017s
prefix info option (3), length 32 (4): fd83:af19:9ef::/64, Flags [onlink, auto], valid time 7200s, pref. time 1800s

... which is perfectly correct, as SLAAC only works for /64.


So, well, my question boils down to "why is that default there?", and
"what effects does this option have, besides assigning /60 prefixes to
LAN interfaces?".

(As a side note: I really like the way IPv6 has gotten integrated into
newer releases. Plug in that thing, received DHCPv6-PD from upstream
routers, offer v6 to connected LANs, off you go...)

gert

[Owen Kirby]

A /64 prefix and SLAAC can only really be applied to a single link in
your network, so if you wanted to separate your network into multiple
links (ie: not bridging) then you would use a shorter prefix to get the
routing right between each of those links.

For example, the IPv6 prefix generated by your router might be
fd83:af19:9ef::/60, but your your ethernet devices would see
fd83:af19:9ef:1::/64 for SLAAC, and your WiFi devices might see
fd83:af19:9ef:2::/64 for SLAAC. Because they are both subnets of the
broader /60 prefix, your router can advertise itself as the router for
all of the links in your home network.

Cheers,
Owen

P.S. This is all hypothetical, I haven't actually played with this
option to see what it does... but this is the typical use case for IPv6
prefixes shorter than 64-bits and ULAs.

Post by Gert Doering
Hiya,
I've installed "trunk (r40576)" on a few boxes because I want to play
around with homenet (hnetd / package hnet-full).
Before I even get there, I'm wondering about something. The sample
config interface 'lan'
option ifname 'eth1'
# option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
what is "option ip6assign" good for, and why does it default to "60"?
("option bridge" commented out by me, as hnetd supposedly does not
like bridges)
The effect it has is that the interface in question receives a /60 as
eth1 Link encap:Ethernet HWaddr 10:FE:ED:E6:5F:32
inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::12fe:edff:fee6:5f32/64 Scope:Link
inet6 addr: fd83:af19:9ef::1/60 Scope:Global
inet6 addr: 2001:608:0:c10::1/60 Scope:Global
... which is not exactly "what the IETF says should be on a LAN" - but
some other parts of the system see the prefix as /64, like when sending
out a RA on that LAN
17:51:19.741002 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 192) fe80::12fe:edff:fee6:5f32 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 192
hop limit 0, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
source link-address option (1), length 8 (1): 10:fe:ed:e6:5f:32
mtu option (5), length 8 (1): 1500
prefix info option (3), length 32 (4): 2001:608:0:c10::/64, Flags [onlink, auto], valid time 2817s, pref. time 1017s
prefix info option (3), length 32 (4): fd83:af19:9ef::/64, Flags [onlink, auto], valid time 7200s, pref. time 1800s
... which is perfectly correct, as SLAAC only works for /64.
So, well, my question boils down to "why is that default there?", and
"what effects does this option have, besides assigning /60 prefixes to
LAN interfaces?".
(As a side note: I really like the way IPv6 has gotten integrated into
newer releases. Plug in that thing, received DHCPv6-PD from upstream
routers, offer v6 to connected LANs, off you go...)
gert
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[Gert Doering]

Hi,

Post by Owen Kirby
A /64 prefix and SLAAC can only really be applied to a single link in
your network, so if you wanted to separate your network into multiple
links (ie: not bridging) then you would use a shorter prefix to get the
routing right between each of those links.
For example, the IPv6 prefix generated by your router might be
fd83:af19:9ef::/60, but your your ethernet devices would see
fd83:af19:9ef:1::/64 for SLAAC, and your WiFi devices might see
fd83:af19:9ef:2::/64 for SLAAC. Because they are both subnets of the
broader /60 prefix, your router can advertise itself as the router for
all of the links in your home network.

I do understand *that*, and I can see that if you do multi-level DHCPv6-PD,
the first router might want to give the second router a /60, so that
this one has 16 /64s for all of its LANs (and so on).

But you'd then normally not configure the /60 onto a LAN segment in between,
but have a /64 between router A and router B, and the /60 routed across
that...

gert

[Steven Barth]

Hi Gert,

you are right its a bit unusual and you may very well consider it bad
practice and if I have enough time it will hopefully solve it in a
better way at some point.

The reasoning behind this is that this way the DHCPv6 (PD) server can
easily learn about the whole available prefix range and any lifetime
etc. changes immediately via Kernel netlink updates and thus reconfigure
clients and downstream routers easily if needed without a separate IPC
or configuration channel.

Of course it still sets up a more specific routes once a prefixes is
actually assigned to a downstream router so that routing works correctly.

Cheers,

Steven

[Steven Barth]

Hi Gert,

In regular OpenWrt ip6assign means that - as already written - a /60 (if
available) is taken from the DP and the assigned to the given interface.
That value was chosen rather arbitrarily. The first /64 of that DP is
handed out via RA and stateful DHCPv6 (IA_NA). The rest of the /60 (or
whatever you set in ip6assign) can be acquired by downstream routers on
that interface via DHCPv6-PD.

Regarding homenet / hnetd, please see http://www.homewrt.org for some
documentation. Also feel free to ask me (I'm one of the authors of the
draft and implementation) or join us on #hnet-hackers on freenode about
anything you might need / want to know.

hnetd implements its own prefix delegation algorithm (as its managed
throughout the homenet) so usual ip6assign-stuff doesn't apply here. You
can also use it with bridges but it might make more sense to use
individual ports instead to e.g. avoid unnecessary traffic on WiFi or
make proper use of the border detection (e.g. use one switch-port for a
second uplink and another for downstream or so).


Cheers,

Steven

[Gert Doering]

Hi,

Post by Steven Barth
In regular OpenWrt ip6assign means that - as already written - a /60 (if
available) is taken from the DP and the assigned to the given interface.
That value was chosen rather arbitrarily. The first /64 of that DP is
handed out via RA and stateful DHCPv6 (IA_NA). The rest of the /60 (or
whatever you set in ip6assign) can be acquired by downstream routers on
that interface via DHCPv6-PD.

Ah! So it's a "reservation" for downstream-DHCPv6-PD.

It's still slightly confusing, tbh, to see the ifconfig and route values
point the /60 towards the actual interface. But maybe that's just me :-)
- it certainly isn't causing problems, just to say that again.

Post by Steven Barth
Regarding homenet / hnetd, please see http://www.homewrt.org for some
documentation. Also feel free to ask me (I'm one of the authors of the
draft and implementation) or join us on #hnet-hackers on freenode about
anything you might need / want to know.

Thanks for the offer. Right now, only one of the routers is life
(due to convenience of access to "stuff", like "arbitrary upstream
routers", I'm building this at office, and 3 out of 4 boxes are still
at home...), but I'm planning to have this operational in the next
few days - and I'm sure questions will come.

I've read everything that's linked from the start page on
http://www.homewrt.org/ - but it's not really much as far as "how can
I see what it does? how can I debug it? Is there only one single
option to turn this on and off ("option proto 'hnet'"), or is there more?
Does hnetd handle IPv4 and IPv6 today? How do I force selection of a certain
/64 on a specific interface?" question go... :-)

(I *have* read all the *-homenet-* drafts, so I feel I understand the
basic concepts and requirements, but now I need to "see" it)

Post by Steven Barth
hnetd implements its own prefix delegation algorithm (as its managed
throughout the homenet) so usual ip6assign-stuff doesn't apply here. You

Understood. I was just curious what it was, spending too much time on
"side-track" curiousity again :-)

Post by Steven Barth
can also use it with bridges but it might make more sense to use
individual ports instead to e.g. avoid unnecessary traffic on WiFi or
make proper use of the border detection (e.g. use one switch-port for a
second uplink and another for downstream or so).

I think the "does not like bridges" thing came from the old stuff on
http://github.org/fingon/hnet-core/ or something like that - can't find
it right now. It's good to know that it works, though I'm fully
intending to not use bridging anyway :-) - I really really like the
hnet approach.

Will let you know how it works out!

thanks,

gert

[Steven Barth]

Post by Gert Doering
Ah! So it's a "reservation" for downstream-DHCPv6-PD.
It's still slightly confusing, tbh, to see the ifconfig and route values
point the /60 towards the actual interface. But maybe that's just me :-)
- it certainly isn't causing problems, just to say that again.

Yes, please see other e-mail in the thread for "justification" ;)

Post by Gert Doering
Thanks for the offer. Right now, only one of the routers is life
(due to convenience of access to "stuff", like "arbitrary upstream
routers", I'm building this at office, and 3 out of 4 boxes are still
at home...), but I'm planning to have this operational in the next
few days - and I'm sure questions will come.
I've read everything that's linked from the start page on
http://www.homewrt.org/ - but it's not really much as far as "how can
I see what it does? how can I debug it? Is there only one single
option to turn this on and off ("option proto 'hnet'"), or is there more?
Does hnetd handle IPv4 and IPv6 today? How do I force selection of a certain
/64 on a specific interface?" question go... :-)

Yeah to turn it on on a given interface simply change the proto to
"hnet" (and remove any previous interface using the same interface in
/etc/config/network). If you want to not use bridging you need to create
one logical interface in /etc/config/network for each switch-port / vlan.

Once you have configured an interface e.g. like this:
config interface h1
option ifname eth1
option proto hnet

and brough it up with /etc/init.d/network reload && ifup h1 you can
watch its state using:
ifstatus h1. hnet also automatically creates a dhcp and dhcpv6 client
subinterface which you can also monitor using ifstatus h1_4 and ifstatus
h1_6. If there is 6rd or dslite provided by dhcp / dhcpv6 then there is
a in addition an interface h1_6rd or h1_dslite. All these virtual
interface are created automatically (you don't need to put then in
/etc/config/network).

Also hnetd at the moment is very talkative in syslog so you should get a
pretty good view of whats going on.

Forcing a certain prefix on an interface is implemented but not exposed
to interface config yet. I will try to put it on todo for sometime next
week and push a new version to OpenWrt once its working shouldn't be
very hard.


Regards,

Steven

[Gert Doering]

Hi,

Post by Steven Barth

Post by Gert Doering
I've read everything that's linked from the start page on
http://www.homewrt.org/ - but it's not really much as far as "how can
I see what it does? how can I debug it? Is there only one single
option to turn this on and off ("option proto 'hnet'"), or is there more?
Does hnetd handle IPv4 and IPv6 today? How do I force selection of a certain
/64 on a specific interface?" question go... :-)

Yeah to turn it on on a given interface simply change the proto to
"hnet" (and remove any previous interface using the same interface in
/etc/config/network). If you want to not use bridging you need to create
one logical interface in /etc/config/network for each switch-port / vlan.

OK. What about the "wan6" interface? Default OpenWRT config has

config interface 'wan'
option ifname 'eth0'
option proto 'dhcp'

config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'

so I assume the "wan6" interface would completely go away, leading to

config interface 'wan'
option ifname 'eth0'
option proto 'hnet'

#config interface 'wan6'
# option ifname '@wan'
# option proto 'dhcpv6'

right?

... but that doesn't work out for me :-( - I can see hnetd talk, but I
completely lost "global IPv6" - no RA learning on the WAN anymore, and
no DHCPv6 PD either.

The upstream server complains about IA-NA not being supported (Cisco),
but I don't see a PD request in there...

May 2 22:47:09: IPv6 DHCP: Received SOLICIT from FE80::CC4F:57BB:3A1:93FD on Vlan2
May 2 22:47:09: IPv6 DHCP: Option IA-NA(3) is not supported yet
May 2 22:47:09: IPv6 DHCP: Sending ADVERTISE to FE80::CC4F:57BB:3A1:93FD on Vlan2
May 2 22:47:09: IPv6 DHCP: Received SOLICIT from FE80::12FE:EDFF:FEE6:5F33 on Vlan62
May 2 22:47:09: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 2 22:47:09: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 2 22:47:09: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 2 22:47:09: IPv6 DHCP: Option IA-NA(3) is not supported yet
May 2 22:47:09: IPv6 DHCP: Sending ADVERTISE to FE80::12FE:EDFF:FEE6:5F33 on Vlan62

(Upstream router sends RA with "A" and "O" bit set, and that worked nicely
with "proto dhcpv6")

and "ifstatus wan" also looks very much "passive"...

***@OpenWrt:~# ifstatus wan
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"uptime": 419,
"l3_device": "eth0",
"proto": "hnet",
"device": "eth0",
"metric": 0,
"delegation": true,
"ipv4-address": [

],
"ipv6-address": [

],
"ipv6-prefix": [

],
"ipv6-prefix-assignment": [

],
"route": [

],
"dns-server": [
"195.30.0.2"
],
"dns-search": [

],
"inactive": {
"ipv4-address": [

],
"ipv6-address": [

],
"route": [

],
"dns-server": [

],
"dns-search": [

]
},
"data": {
"dhcpv4": "disabled",
"dhcpv6": "disabled",
"ra": "disabled",
"ra_management": 1,
"zone": "wan"
}
}

... so, something I am missing... :-/

thanks,

gert

[Gert Doering]

Hi,

Post by Gert Doering
May 2 22:47:09: IPv6 DHCP: Received SOLICIT from FE80::CC4F:57BB:3A1:93FD on Vlan2
May 2 22:47:09: IPv6 DHCP: Option IA-NA(3) is not supported yet
May 2 22:47:09: IPv6 DHCP: Sending ADVERTISE to FE80::CC4F:57BB:3A1:93FD on Vlan2

Ooops, *this* was a red herring. Some other device in that test LAN...

Post by Gert Doering
May 2 22:47:09: IPv6 DHCP: Received SOLICIT from FE80::12FE:EDFF:FEE6:5F33 on Vlan62
May 2 22:47:09: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 2 22:47:09: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 2 22:47:09: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 2 22:47:09: IPv6 DHCP: Option IA-NA(3) is not supported yet
May 2 22:47:09: IPv6 DHCP: Sending ADVERTISE to FE80::12FE:EDFF:FEE6:5F33 on Vlan62

But *that* is the WRT Box...

gert

[Gert Doering]

Hi,

Post by Gert Doering
... so, something I am missing... :-/

Oh well. First thing is "I should have looked at 'ifstatus wan_6'" which
indeed tells me "WAN is working":

***@OpenWrt:/etc/config# ifstatus wan_6
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"proto": "dhcpv6",
"device": "eth0",
"data": {

}
}


Second thing is what tcpdump tells me...

21:07:24.773303 IP6 (hlim 1, next-header UDP (17) payload length: 148) fe80::12fe:edff:fee6:5f33.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=eacb5 (elapsed-time 12979) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_82 opt_83) (client-ID hwaddr type 1 10feede65f33) (user-class) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/0 pltime:0 vltime:0)))

21:07:24.774839 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 59) fe80::214:1cff:fed2:30c0.547 > fe80::12fe:edff:fee6:5f33.546: [udp sum ok] dhcp6 advertise (xid=eacb5 (server-ID hwaddr type 1 00141cd230c0) (client-ID hwaddr type 1 10feede65f33) (status-code no addresses))

... so hnetd is asking for IA_NA and IA_PD, which the upstream Cisco doesn't
support (at least not in the IOS version that's running, need to research
whether a different Cisco platform could do IA_NA), so the Cisco returns "no
addresses", and then hnetd is unhappy and does not want to ask again for
"only IA_PD".


Questions :-)

- is hnetd intentionally ignoring the A-Bit in RA?

- what's the recommended config on the upstream side to make it work?
Remove the "O"-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)

thanks,

gert

[Steven Barth]

Hi Gert,

Post by Gert Doering
Hi,

Post by Gert Doering
... so, something I am missing... :-/

Oh well. First thing is "I should have looked at 'ifstatus wan_6'" which
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"proto": "dhcpv6",
"device": "eth0",
"data": {
}
}

doesn't really look like working.

Post by Gert Doering
Questions :-)
- is hnetd intentionally ignoring the A-Bit in RA?

hnetd doesn't reimplement the dhcpv6-client it uses OpenWrt's internal
dhcpv6-protocol-handler.
So it behaves the same as if you had an interface with proto=dhcpv6 and
option forceprefix 1. If it works with that you should be good to go
(unless there is a bug somewhere sigh)

And normally the dhcpv6 handler ignores O/M-bits and just asks for IA_NA
+ IA_PD first in a solicit and when that fails (server returns with
NoAddrsAvail) tries with IA_PD-only which should succeed in your case
(don't know why it didn't though).

Post by Gert Doering
- what's the recommended config on the upstream side to make it work?
Remove the "O"-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)

I'll try to confirm / fix a bug tomorrow or on monday. I could offer you
a workaround at the moment which is: Open /lib/netifd/proto/hnet.sh and
search for json_add_string proto dhcpv6

Below that insert a line:
json_add_string reqaddress none
which should disable it asking for an IA_NA alltogether.

Post by Gert Doering
thanks,
gert

[Steven Barth]

Just did a quick test with hnet against ISC dhcp behaving the same
(IA_PD-only) and it worked out fine.

Post by Steven Barth
Hi Gert,

Post by Gert Doering
Hi,

Post by Gert Doering
... so, something I am missing... :-/

Oh well. First thing is "I should have looked at 'ifstatus wan_6'" which
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"proto": "dhcpv6",
"device": "eth0",
"data": {
}
}

doesn't really look like working.

Post by Gert Doering
Questions :-)
- is hnetd intentionally ignoring the A-Bit in RA?

hnetd doesn't reimplement the dhcpv6-client it uses OpenWrt's internal
dhcpv6-protocol-handler.
So it behaves the same as if you had an interface with proto=dhcpv6
and option forceprefix 1. If it works with that you should be good to
go (unless there is a bug somewhere sigh)
And normally the dhcpv6 handler ignores O/M-bits and just asks for
IA_NA + IA_PD first in a solicit and when that fails (server returns
with NoAddrsAvail) tries with IA_PD-only which should succeed in your
case (don't know why it didn't though).

Post by Gert Doering
- what's the recommended config on the upstream side to make it work?
Remove the "O"-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)

I'll try to confirm / fix a bug tomorrow or on monday. I could offer
you a workaround at the moment which is: Open
/lib/netifd/proto/hnet.sh and search for json_add_string proto dhcpv6
json_add_string reqaddress none
which should disable it asking for an IA_NA alltogether.

Post by Gert Doering
thanks,
gert

[Gert Doering]

Hi,

thanks for your help so far. (Side question: if people feel this is getting
off-topic for openwrt-devel, I'll take it offline. For now I keep the CC:
because I think other people might end up running into this, and google
might find the solutions, then :-) )

Post by Steven Barth

Post by Gert Doering
Oh well. First thing is "I should have looked at 'ifstatus wan_6'" which
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"proto": "dhcpv6",
"device": "eth0",
"data": {
}
}

doesn't really look like working.

Well, it's not succeeding, but at least it's doing something :-) - while
"ifstatus wan" got me all confused, with all protocols set to "false".

Post by Steven Barth

Post by Gert Doering
Questions :-)
- is hnetd intentionally ignoring the A-Bit in RA?

hnetd doesn't reimplement the dhcpv6-client it uses OpenWrt's internal
dhcpv6-protocol-handler.
So it behaves the same as if you had an interface with proto=dhcpv6 and
option forceprefix 1. If it works with that you should be good to go
(unless there is a bug somewhere sigh)

What does "forceprefix 1" do?

If I do "proto dhcp" and no "forceprefix", the wan interface gets an
IPv6 address from the RAs received (plus default route).

Right now, I have neither an IPv6 default route nor an address, so it
very much looks like it's ignoring my RAs.

Post by Steven Barth
And normally the dhcpv6 handler ignores O/M-bits and just asks for IA_NA
+ IA_PD first in a solicit and when that fails (server returns with
NoAddrsAvail) tries with IA_PD-only which should succeed in your case
(don't know why it didn't though).

Yeah, given the not-exactly-clear specification of O/M-Bits, this sounds
like a "fail-save" approach in the general case.

[..]

Post by Steven Barth

Post by Gert Doering
- what's the recommended config on the upstream side to make it work?
Remove the "O"-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)

I'll try to confirm / fix a bug tomorrow or on monday.

Thanks for testing against ISC DHCP (other mail). I'm not sure what
is different here - maybe ISC is returning the prefix right away, while
IOS just tells the router "go away"?

Post by Steven Barth
I could offer you
a workaround at the moment which is: Open /lib/netifd/proto/hnet.sh and
search for json_add_string proto dhcpv6
json_add_string reqaddress none
which should disable it asking for an IA_NA alltogether.

Done...

May 3 14:47:47: IPv6 DHCP: Received SOLICIT from FE80::12FE:EDFF:FEE6:5F33 on Vlan62
May 3 14:47:47: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 3 14:47:47: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 3 14:47:47: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 3 14:47:47: IPv6 DHCP: Sending ADVERTISE to FE80::12FE:EDFF:FEE6:5F33 on Vlan62
May 3 14:47:47: IPv6 DHCP: Received REQUEST from FE80::12FE:EDFF:FEE6:5F33 on Vlan62
May 3 14:47:47: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 3 14:47:47: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 3 14:47:47: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 3 14:47:47: IPv6 DHCP: Creating binding for FE80::12FE:EDFF:FEE6:5F33 in pool NetmasterTEST
May 3 14:47:47: IPv6 DHCP: Allocating IA_PD 00000001 in binding for FE80::12FE:EDFF:FEE6:5F33
May 3 14:47:47: IPv6 DHCP: Allocating prefix 2001:608:5::/56 in binding for FE80::12FE:EDFF:FEE6:5F33, IAID 00000001
May 3 14:47:47: IPv6 DHCP: Sending REPLY to FE80::12FE:EDFF:FEE6:5F33 on Vlan62


... and things work :-) - I'm not posting the whole "ifstatus wan_6" now,
as it is 100+ lines long. The most important bits are these, though:

"ipv6-address": [
{
"address": "2001:608:0:62:12fe:edff:fee6:5f33",
"mask": 64,
"preferred": 604752,
"valid": 2591952
}
],
"ipv6-prefix": [
{
"address": "2001:608:5::",
"mask": 56,
"preferred": 1751,
"valid": 3551,
"class": "wan_6",
"assigned": {

}
}
],

"good!".


Next question :-)

***@OpenWrt:~# ifstatus lan_6
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"proto": "dhcpv6",
"device": "eth1",
"data": {

}
}

as per your definition, this is "not working", right?.

OTOH, "ip -6 addr" confirms that it indeed selected a subnet from the
delegated prefix (2001:608:5::/56), assigned it to the lan=eth1 (only
a single LAN interface here)

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:608:5:b5:12fe:edff:fee6:5f32/64 scope global dynamic
valid_lft 3448sec preferred_lft 1648sec
inet6 2001:608:0:62:12fe:edff:fee6:5f33/64 scope global dynamic
valid_lft 2591971sec preferred_lft 604771sec
inet6 fe80::12fe:edff:fee6:5f32/64 scope link
valid_lft forever preferred_lft forever

$ ip -6 route
2001:608:5:b5::/64 dev eth1 proto static metric 1024

So it looks good to me.


Though... "ip -6 route" actually brings up the next "huh, what?" question:

***@OpenWrt:~# ip -6 route
default from :: via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
default from 2001:608:0:62::/64 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
default from 2001:608:5::/56 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec
2001:608:5:b5::/64 dev eth1 proto static metric 1024
unreachable 2001:608:5::/56 dev lo proto static metric 1000000000 error -128
unreachable 2001:608:5::/56 dev lo proto static metric 2147483647 error -128
unreachable fd83:af19:9ef::/48 dev lo proto static metric 2147483647 error -128

I understand the defaults (eth0=wan, source dependent, could be multiple
routers, but there is only one, so all the same), and the unreachables.

I do not understand this one:

2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec

this network is connected to the *WAN* side of things (eth0), and announced
by RA from the Cisco to the WRT. The address from that /64 is visible on
both eth0 + eth1, which I find a bit surprising but "otherwise harmless",
but the route shouldn't point to eth1 - my belly says "this would make
the box unable to reach other devices on the :0:62:: LAN".

Incidentially, when I ping6 the GUA address of the router, it *does* work:

***@OpenWrt:~# ping6 2001:608:0:62::ffff
PING 2001:608:0:62::ffff (2001:608:0:62::ffff): 56 data bytes
64 bytes from 2001:608:0:62::ffff: seq=0 ttl=64 time=0.810 ms
64 bytes from 2001:608:0:62::ffff: seq=1 ttl=64 time=0.658 ms

"whut"?


Anyway. Short summary: with the change to hnet.sh, it seems to be working
and I get all the addresses and prefixes I expect to see. There is just
confusion in "what should the output of some commands look like".

thanks,

gert

[Steven Barth]

Hi Gert,

well thanks for testing.
answers are inline.

Post by Gert Doering
Hi,
thanks for your help so far. (Side question: if people feel this is getting
because I think other people might end up running into this, and google
might find the solutions, then :-) )

Should be fine.

Post by Gert Doering
What does "forceprefix 1" do?

Normal dhcpv6 handler also succeeds without PD for simple clinets.

Post by Gert Doering
If I do "proto dhcp" and no "forceprefix", the wan interface gets an
IPv6 address from the RAs received (plus default route).
Right now, I have neither an IPv6 default route nor an address, so it
very much looks like it's ignoring my RAs.

Strange as RA handling is done independently but OK.

Post by Gert Doering
[..]

Post by Steven Barth

Post by Gert Doering
- what's the recommended config on the upstream side to make it work?
Remove the "O"-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)

I'll try to confirm / fix a bug tomorrow or on monday.

Thanks for testing against ISC DHCP (other mail). I'm not sure what
is different here - maybe ISC is returning the prefix right away, while
IOS just tells the router "go away"?

Might be IOS weirdness of this specific version. We have tested against
other Cisco devices which works fine. Which version is it?

Post by Gert Doering

Post by Steven Barth
I could offer you
a workaround at the moment which is: Open /lib/netifd/proto/hnet.sh and
search for json_add_string proto dhcpv6
json_add_string reqaddress none
which should disable it asking for an IA_NA alltogether.

Done...
May 3 14:47:47: IPv6 DHCP: Received SOLICIT from FE80::12FE:EDFF:FEE6:5F33 on Vlan62
May 3 14:47:47: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 3 14:47:47: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 3 14:47:47: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 3 14:47:47: IPv6 DHCP: Sending ADVERTISE to FE80::12FE:EDFF:FEE6:5F33 on Vlan62
May 3 14:47:47: IPv6 DHCP: Received REQUEST from FE80::12FE:EDFF:FEE6:5F33 on Vlan62
May 3 14:47:47: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 3 14:47:47: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 3 14:47:47: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 3 14:47:47: IPv6 DHCP: Creating binding for FE80::12FE:EDFF:FEE6:5F33 in pool NetmasterTEST
May 3 14:47:47: IPv6 DHCP: Allocating IA_PD 00000001 in binding for FE80::12FE:EDFF:FEE6:5F33
May 3 14:47:47: IPv6 DHCP: Allocating prefix 2001:608:5::/56 in binding for FE80::12FE:EDFF:FEE6:5F33, IAID 00000001
May 3 14:47:47: IPv6 DHCP: Sending REPLY to FE80::12FE:EDFF:FEE6:5F33 on Vlan62
... and things work :-) - I'm not posting the whole "ifstatus wan_6" now,

OK, hopefully there is an IPv6 default route in there somewhere.

Post by Gert Doering
Next question :-)
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"proto": "dhcpv6",
"device": "eth1",
"data": {
}
}
as per your definition, this is "not working", right?.

Not necessarily. The _6 interfaces are only showing information acquired
from DHCPv6-servers/RAs so this only matters if its an uplink. "ifstatus
lan" without _6 shows the data from homenet / hnetd such as IP address,
firewall zone.

Post by Gert Doering
OTOH, "ip -6 addr" confirms that it indeed selected a subnet from the
delegated prefix (2001:608:5::/56), assigned it to the lan=eth1 (only
a single LAN interface here)
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:608:5:b5:12fe:edff:fee6:5f32/64 scope global dynamic
valid_lft 3448sec preferred_lft 1648sec
inet6 2001:608:0:62:12fe:edff:fee6:5f33/64 scope global dynamic
valid_lft 2591971sec preferred_lft 604771sec
inet6 fe80::12fe:edff:fee6:5f32/64 scope link
valid_lft forever preferred_lft forever
$ ip -6 route
2001:608:5:b5::/64 dev eth1 proto static metric 1024
So it looks good to me.
default from :: via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
default from 2001:608:0:62::/64 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
default from 2001:608:5::/56 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec
2001:608:5:b5::/64 dev eth1 proto static metric 1024
unreachable 2001:608:5::/56 dev lo proto static metric 1000000000 error -128
unreachable 2001:608:5::/56 dev lo proto static metric 2147483647 error -128
unreachable fd83:af19:9ef::/48 dev lo proto static metric 2147483647 error -128
I understand the defaults (eth0=wan, source dependent, could be multiple
routers, but there is only one, so all the same), and the unreachables.
2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec

I wonder where that comes from. Could you check if its in ifstatus lan?
Don't know where this comes from though. Doesn't really make sense. Are
there spurious RAs on eth1 with that address?

Post by Gert Doering
this network is connected to the *WAN* side of things (eth0), and announced
by RA from the Cisco to the WRT. The address from that /64 is visible on
both eth0 + eth1, which I find a bit surprising but "otherwise harmless",
but the route shouldn't point to eth1 - my belly says "this would make
the box unable to reach other devices on the :0:62:: LAN".

Yeah wonder why it happens. Is it in ifstatus lan or iftstaus lan_6 or
do you ahve kernel RA handling enabled?

Post by Gert Doering
PING 2001:608:0:62::ffff (2001:608:0:62::ffff): 56 data bytes
64 bytes from 2001:608:0:62::ffff: seq=0 ttl=64 time=0.810 ms
64 bytes from 2001:608:0:62::ffff: seq=1 ttl=64 time=0.658 ms
"whut"?
Anyway. Short summary: with the change to hnet.sh, it seems to be working
and I get all the addresses and prefixes I expect to see. There is just
confusion in "what should the output of some commands look like".

OK I'll export this workaround as option in interface-config as well.

Post by Gert Doering
thanks,
gert

Cheers,

Steven

[Gert Doering]

Hi,

Post by Steven Barth

Post by Gert Doering
If I do "proto dhcp" and no "forceprefix", the wan interface gets an
IPv6 address from the RAs received (plus default route).
Right now, I have neither an IPv6 default route nor an address, so it
very much looks like it's ignoring my RAs.

Strange as RA handling is done independently but OK.

Mmmh. "Something is funny in that box" - the address from RA and the
default route appeared as soon as the DHCPv6-PD issue was resolved.

[..]

Post by Steven Barth

Post by Gert Doering
Thanks for testing against ISC DHCP (other mail). I'm not sure what
is different here - maybe ISC is returning the prefix right away, while
IOS just tells the router "go away"?

Might be IOS weirdness of this specific version. We have tested against
other Cisco devices which works fine. Which version is it?

This is a 6500 with 12.2(33)SXI3 - which can't do IA_NA at all. More
recent versions (12.4T something) can do IA_NA for static assignments,
but as far as I could find, no IOS can do IA_NA from pools, the "traditional"
stateful DHCP thing.

I will add a box with some 12.4T release in the mix tomorrow, upstreaming
the second router. We'll see what happens there...

Post by Steven Barth

Post by Gert Doering
# ifup lan_6
[ not showing any activity ]
as per your definition, this is "not working", right?.

Not necessarily. The _6 interfaces are only showing information acquired
from DHCPv6-servers/RAs so this only matters if its an uplink. "ifstatus
lan" without _6 shows the data from homenet / hnetd such as IP address,
firewall zone.

OK, understood. So the "downstream" activity (assigning a LAN prefix,
HNCP neighbours, ...) will be in the syslog, or "ip -6 addr".

[..]

Post by Steven Barth

Post by Gert Doering
2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec

[..]

Post by Steven Barth
I wonder where that comes from. Could you check if its in ifstatus lan?
Don't know where this comes from though. Doesn't really make sense. Are
there spurious RAs on eth1 with that address?

Summarizing the discussion we had in parallel on IRC: this might have been
an artefact of me not renaming the "lan" and "wan" interfaces, so possibly
other bits of OpenWRT fiddled in parallel to hnetd. One indication is that
the route has a lifetime, which hnetd never sets, so it came "from elsewhere".

I've now changed lan/wan interface names & config to:

config interface 'hlan'
option ifname 'eth1'
option proto 'hnet'

config interface 'hwan'
option ifname 'eth0'
option proto 'hnet'

and everything that refers to interface/proto is gone (so no more "wan6"
either) and rebooted - and now the result is "what I would naively expect":

***@GreenISPRouter:~# ip -6 addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:608:0:62:12fe:edff:fee6:5f33/64 scope global dynamic
valid_lft 2591987sec preferred_lft 604787sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:608:5:5b:12fe:edff:fee6:5f32/64 scope global dynamic
valid_lft 3462sec preferred_lft 1662sec

***@GreenISPRouter:~# ip -6 route
default from :: via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
default from 2001:608:0:62::/64 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
default from 2001:608:5::/56 via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
2001:608:0:62::/64 dev eth0 proto static metric 256
2001:608:5:b1::/64 dev eth1 proto static metric 1024
unreachable 2001:608:5::/56 dev lo proto static metric 1000000000 error -128
unreachable 2001:608:5::/56 dev lo proto static metric 2147483647 error -128
unreachable fd83:af19:9ef::/48 dev lo proto static metric 2147483647 error -128


... though there still is weirdness in my box, just for the record :-)

- "ifdown hlan" makes hnetd go crazy (logging 50+ messages/second, not
recovering until you do "network restart")

- "/etc/init.d/network restart" restarts, but after that, some of the
routes are gone - in one case, 2001:608:0:62::/64, in the other case,
the 2001:608:5:b1::/64 one. This (again, FTR) is due to hnetd not
noticing that "network restart" has removed the routes, so if you do
that, you need to also do "hnetd restart". (Noted :)).


Anyway, thanks for helping me gettings this off the ground. More questions
(and answers for the archive) to come :-)

gert